From pkyzivat@cisco.com Sun May 1 12:07:02 2011 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 3CB34E06B2 for ; Sun, 1 May 2011 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bSTYl9YXkBor for ; Sun, 1 May 2011 12:07:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 90D62E06A5 for ; Sun, 1 May 2011 12:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3702; q=dns/txt; s=iport; t=1304276821; x=1305486421; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hMP0AWxOQUz5TU+UQffsfkJ4nNjcTXcjGLD+BMHml08=; b=kD96pRQFZzs7Cjq9vAlp8iZpF56mHm7vFyWm4E6/zUwJARUw2hZMr+kG CfBzlxHcSTD0aQyH1yQdhq1w6cKCg3WKx81Y6ytZhalmUHQmF8D/9so/A Zm/EkG2JROpWwaodQXfnPtrQ+skZ7xq1gq4lDzMqoaU/VCcu8DGiTiLXO c=; X-IronPort-AV: E=Sophos;i="4.64,298,1301875200"; d="scan'208";a="439741731" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 01 May 2011 19:07:01 +0000 Received: from [10.86.253.168] ([10.86.253.168]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p41J6xx5020236; Sun, 1 May 2011 19:07:00 GMT Message-ID: <4DBDAF53.8080903@cisco.com> Date: Sun, 01 May 2011 15:06:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 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, 01 May 2011 19:07:02 -0000 (As individual) I started to reply to this some time ago, and never got around to sending it. Comments inline. Thanks, Paul On 4/22/2011 1:41 PM, Stephan Wenger wrote: > Hi Paul, group, > Some of the issues you raised are based on my input, so I think it's only > fair if I answer them. > Please see inline. > Stephan > > > On 4.22.2011 06:37 , "Paul Kyzivat" wrote: > >> [...] >> >> Why is REQMT-4 SHOULD while REQMT-5 is MUST? >> It seems that REQMT-7/REQMT-8 is a similar pairing, but in that case >> both are MUST strength. > > It's an IPR concern that led to the SHOULD. I prefer the WG has the > freedom to leave out specification text addressing this requirement if IPR > surfaces, which (in this case) seems likely to me. Sorry for not being > more specific on this public mailing list. If there are IPR issues I would prefer to lay them on the table rather than have them be an unspoken subtext driving such decisions. If you have IPR concerns, is it about IPR that has been disclosed, or about stuff you know of that hasn't been disclosed, or about stuff you don't know about but suspect might exist? > As a general comment, IIRC the previous revision of the draft contained > only MUST requirements. I personally prefer "soft" requirement language, > so to be able to address concerns of whatever nature (including, but by no > means limited to IPR) without having to abandon one of our own > requirements. I find the use of SHOULD be generally cause confusion. Its especially a problem in protocol specs, because many implementers treat it as "not required". Its slightly different in requirements, since at the end of the day we still get to judge if we like the resulting mechanism. But the distinction then becomes one of "must-have" vs. "nice-to-have". And deciding which is among what we need to be deciding now. It really leaps out at you when you have some MUSTs and some SHOULDs - it begs for an explanation of how the choice was made. >> REQMT-6: The solution MUST include a mechanism to support a means >> of describing dynamic changes in the streams offered by >> the sender; and dynamic changes in the streams requested >> by the receiver. >> >> IMO "a mechanism to support a means" is excessive. How about >> >> REQMT-6: The solution MUST include a mechanism to support >> describing dynamic changes in the streams offered by >> the sender; and dynamic changes in the streams requested >> by the receiver. > > Sounds OK to me. > Allyn and I had a discussion about this requirement. I was worried that > it would not be within the charter. Allyn proved me wrong. However, it > is my understanding that implementing this "solution" requires technology > that goes beyond the exchange of properties and capabilities during > session setup. We are not talking about a bunch of SDP codepoints here. > This is real-time conference control for media. Is this really what we > want to do in this WG? It's conceptually a different problem than just > announcing "this session comes from the right camera". Do we have an idea > what we want to use here? Mediactl? > >> >> I don't understand exactly what point REQMT-10 is trying to make that is >> different from REQMT-9. I think maybe REQMT-10 needs a few more words. > > Agreed. 10 seems to be a generalization of 9. > >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > From pkyzivat@cisco.com Sun May 1 16:59:31 2011 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 EB559E0670 for ; Sun, 1 May 2011 16:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dw2YHAxUCDiK for ; Sun, 1 May 2011 16:59:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 96BFEE062A for ; Sun, 1 May 2011 16:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=260; q=dns/txt; s=iport; t=1304294371; x=1305503971; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=prwDfjeE+lBvL+1v2Dl/TvHLBRnif/M3cX03OFnIiGI=; b=AL1UtTvBF8m132fl0V/OXrHvvwisYus9MMc9yOxruLVdZIBvY9QXwza3 vYuzXBrpPAhF9Vf7oI3gKZSNdebF7d2GYg1tEPyfDw5m1+6WUNn7GqXw+ 8q0s7dyVO6/5Q8zOqv96wnKRDBlJDDh34n10yTqWDCDJO0qATA0ATMQWd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvzvU2tJV2Z/2dsb2JhbACmHXeka4EdmzKGAASOeYQZiiU X-IronPort-AV: E=Sophos;i="4.64,299,1301875200"; d="scan'208";a="439788259" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 01 May 2011 23:59:14 +0000 Received: from [10.86.253.168] ([10.86.253.168]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p41NxDQC006522 for ; Sun, 1 May 2011 23:59:13 GMT Message-ID: <4DBDF3D1.6030006@cisco.com> Date: Sun, 01 May 2011 19:59:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] CLUE Minutes for IETF-80 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, 01 May 2011 23:59:32 -0000 Draft minutes for the CLUE session at IETF-80 in Prague can be found at http://www.ietf.org/proceedings/80/minutes/clue.html If you attended the meeting, please review the minutes and respond back if you have corrections to propose. Thanks, Paul From ron.even.tlv@gmail.com Thu May 5 00:34:12 2011 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 84319E068C for ; Thu, 5 May 2011 00:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, 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 14ZULp6W-ZoP for ; Thu, 5 May 2011 00:34:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB81E0651 for ; Thu, 5 May 2011 00:34:07 -0700 (PDT) Received: by wwa36 with SMTP id 36so1407965wwa.13 for ; Thu, 05 May 2011 00:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=d4iYsqC3S17E3mt50fauCxh2/qi9OxUNDtCZlswF4FE=; b=jcAAEW/69NqdB79cnwKbG2UwFEuMLnO9CYRfAjR8HXBsYkDW5mocVuFUpQ9fRwDAnK 3ZYmQRrOLVI7ZLHQKHt9W2Yub90KioLvGzM0MiwsaxTCWE0qXSW8cAV6+J7xGArTxdhE mN9wOpueHm6gBFVmmdVcf6NosDhjx9Wcy7JMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=EUDXGeyUv7/43XO5RtRP+y+OiTZQ3aVDo+2OS18vqKOoezmhDcYbt2OXxqzttDbXXm IajTJpTyBT63C00J1sfJ+MYqgEwu+GPYkXqa1tKvdhYHJORZkYfAnRY7OFm8RTfuU8gC rU5NJNCY2Zz1IYIL/Uk4XZAfWqeAP1jgbSr6Q= Received: by 10.217.4.66 with SMTP id t44mr5855231wes.104.1304580846892; Thu, 05 May 2011 00:34:06 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-32-67.red.bezeqint.net [79.177.32.67]) by mx.google.com with ESMTPS id ed10sm1166802wbb.15.2011.05.05.00.33.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 00:34:04 -0700 (PDT) From: "Roni Even" To: "'Peter Musgrave'" , "'Stephan Wenger'" References: In-Reply-To: Date: Thu, 5 May 2011 10:32:18 +0300 Message-ID: <4dc252ec.cac3e30a.2d35.707c@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0424_01CC0B0F.C0EACC90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwB3xzVSFzVr6pkThib9YpvFCcfWwJFw5SA Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 07:34:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0424_01CC0B0F.C0EACC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephan, I agree with Peter, this is about a mechanism and not about the data itself. So I am not sure about the concern for IPR on being able to describe sender capabilities. Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Saturday, April 23, 2011 8:52 PM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 Hi Stephan On 2011-04-22, at 1:41 PM, Stephan Wenger wrote: It's an IPR concern that led to the SHOULD. I prefer the WG has the freedom to leave out specification text addressing this requirement if IPR surfaces, which (in this case) seems likely to me. Sorry for not being more specific on this public mailing list. REQMT-4: The solution SHOULD support a mechanism by which a sending endpoint or MCU can describe aspects of its characteristics and attributes. Do I understand this to mean that you are concerned about IPR regarding the mechanism of describing the aspects and characteristics? Or do you mean that there might be IPR associated with the characteristics/attributes themselves? If the later, then I think a MUST would be ok, since the requirement is for a mechanism. I have the opposite bias - I prefer MUST for requirements - otherwise why call them requirements? A section which describes additional goals (as opposed to requirements) could be a place for SHOULD clauses. Peter ------=_NextPart_000_0424_01CC0B0F.C0EACC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephan,

I agree with Peter, this is about a mechanism and not about the data = itself.  So I am not sure about the concern for IPR on being able = to describe sender capabilities.

 

Roni Even

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Peter Musgrave
Sent: Saturday, April 23, 2011 8:52 = PM
To: Stephan Wenger
Cc: CLUE
Subject: = Re: [clue] FW: New Version Notification for = draft-romanow-clue-telepresence-requirements-02

 

Hi Stephan

 

On = 2011-04-22, at 1:41 PM, Stephan Wenger wrote:



It's an = IPR concern that led to the SHOULD.  I prefer the WG has = the
freedom to leave out specification text = addressing this requirement if IPR
surfaces, which (in this case) seems likely to = me.  Sorry for not being
more specific on this public mailing = list.

 

REQMT-4: &nbs=
p; The solution SHOULD support a mechanism by which a =
sending
   =
           endpoint or =
MCU can describe aspects of its
   =
           =
characteristics and attributes.

 

<= div>

Do I = understand this to mean that you are concerned about IPR regarding the = mechanism of describing the aspects and = characteristics? 

 

<= div>

Or do you = mean that there might be IPR associated with the = characteristics/attributes themselves?

 

<= div>

If the = later, then I think a MUST would be ok, since the requirement is for a = mechanism.

 

<= div>

I have = the opposite bias - I prefer MUST for requirements - otherwise why call = them requirements?

 

<= div>

A section = which describes additional goals (as opposed to requirements) could be a = place for SHOULD clauses.

 

<= div>

Peter

<= /div> ------=_NextPart_000_0424_01CC0B0F.C0EACC90-- From ron.even.tlv@gmail.com Thu May 5 01:33:56 2011 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 D0CE3E06C0 for ; Thu, 5 May 2011 01:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghqNFRvcxAWO for ; Thu, 5 May 2011 01:33:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA33E0693 for ; Thu, 5 May 2011 01:33:54 -0700 (PDT) Received: by wyb29 with SMTP id 29so1634918wyb.31 for ; Thu, 05 May 2011 01:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=OgM3yi6pVT8q9EQel9G8p8WCxM+3IDDUKOI5jphLRvY=; b=gLGdyCpz4gDuWQ50eEFYK/Tzx9A+djnW/fz7HmYpFn6hCPHEPG8ShqpUHMIY+FB2oQ yT5J6frNAnKZL//QpeV3jcUOiN2X7EK2laV6Ak1o+FW5KdJmtTns7ETYvvEfRYoYu22G nzvUSwg5uETKEJmxTDdAZ3rTAI59kyLq8Sx1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=XmmaUJKOCIqZuWZmcu0239EFAWBoeTzi0+vQ9oxl1gycaLu/o6ToVtCsHicQ2OUIY9 46XvmXMx/MHm+FEbMRtLck5YeWkcr0dOu0jYjFZcPKj+hLnrjaoR+b2/pI25JFcBEdVT GfIzIrzntlrOpZLuvG/fxYFk9HaY5YCaDnD5g= Received: by 10.216.82.68 with SMTP id n46mr2153373wee.57.1304584433832; Thu, 05 May 2011 01:33:53 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-32-67.red.bezeqint.net [79.177.32.67]) by mx.google.com with ESMTPS id j49sm954909wer.38.2011.05.05.01.33.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 01:33:52 -0700 (PDT) From: "Roni Even" To: "'CLUE'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> Date: Thu, 5 May 2011 11:32:20 +0300 Message-ID: <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwAwU2PrUqxJliiTnmBiJQnx57OfQAABRcwAo1VW9A= Content-Language: en-us Subject: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 08:33:56 -0000 Hi, I read the draft and the requirements and also looked at the email = thread. The one thing that bothered me was the terms used. Requirement 1 and 2 talk about describing spatial arrangement. Requirement 3 talk about spatial matching of audio and video - I am not = sure that we need to have this as a MUST requirement. I understand lip = synch will be required and is not mentioned or it can be that I do not = understand what spatial matching means here. Requirement 4 talk about characteristics and attribute. I saw = characteristics mentioned in section 4 "Characteristics include number, = placement, capture/render angle, resolution of cameras and screens, = spatial location and mixing parameters of microphones." And noticed that = Allyn in the email thread had " Since characteristics of media streams = during a telepresence conference may change, such as bandwidth, = resolution". I think that we need to specify what we mean by endpoint = characteristics and stream characteristics and are these the terms we = should use in all the requirements. Requirement 5 uses specified information about itself (see the comment = on requirement 4). Is this the received endpoint receive = characteristics? Requirement 6 based on the above comment should probably discuss dynamic = changes in stream characteristics. Requirement 7 should talk about the streams characteristics and not the = description of the streams. I think that if we go to a common language in all requirements it will = be easier to see the redundancy between the requirements. I was wondering about requirement 14 - I take it that it means that it = must be possible to open all media channels after one offer answer = exchange. I am not sure if we should have such a strong statement = currently. I think it is an important objective but based on my current = experience with dual stream support (H.239 like) and the current media = capability negotiation I think it is very challenging when considering = backward computability ("support for "legacy" systems). I am also missing a requirement for "legacy" system support like the = solution MUST enable a system that does not support the mechanism to = select the best set of streams to render (audio + video). Thanks Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Allyn Romanow (allyn) > Sent: Friday, April 22, 2011 10:48 AM > To: CLUE > Subject: [clue] FW: New Version Notification for draft-romanow-clue- > telepresence-requirements-02 >=20 > Folks, > I revised my requirement document based on the numerous helpful > comments made during the WG meeting in Prague. An appendix outlines = the > main changes. >=20 > I=E2=80=99m delighted that Stephan Wenger has significantly = contributed to the > draft and agreed to be a co-author - much appreciation, Stephan. >=20 > Looking forward to discussion of the draft- >=20 > Best regards, > Allyn >=20 > ------- >=20 > A new version of I-D, draft-romanow-clue-telepresence-requirements- > 02.txt has been successfully submitted by Allyn Romanow and posted to > the IETF repository. >=20 > Filename: draft-romanow-clue-telepresence-requirements > Revision: 02 > Title: Requirements for Telepresence Multi-Streams > Creation_date: 2011-04-22 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This memo discusses the requirements for a specification that enables > telepresence interoperability, by describing the relationship between > multiple RTP streams. In addition, the problem statement and > definitions are also covered herein. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Thu May 5 05:52:19 2011 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 831B8E0721 for ; Thu, 5 May 2011 05:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5OsFxDhHKkVs for ; Thu, 5 May 2011 05:52:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 72BF0E071A for ; Thu, 5 May 2011 05:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2131; q=dns/txt; s=iport; t=1304599938; x=1305809538; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6o3dX90e30hWwYKXm9/IeKldRoMeccEZQ4QiSMK/S5w=; b=A340wI2VRQdosUSNl4Wh81fKIS44wxGmCVoZzjAKJ1v9l+WZfhU9bPfe M28TbWKsjYxK1QtMK8Q9OFed0hr5Fs+iNQqNVxAckYO93HDfqmoZR2J+T eLq/y8fFA/wiXF1LXzXOc6aCqfEgCNmSXjy7qh9khsmLymnrw/8yjcQ5v Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4BAA2dwk2rRDoG/2dsb2JhbACYEUCNZHenTp42hgcEj0qEI4pI X-IronPort-AV: E=Sophos;i="4.64,319,1301875200"; d="scan'208";a="442249155" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 12:52:17 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p45CqGmh009455 for ; Thu, 5 May 2011 12:52:16 GMT Message-ID: <4DC29D81.7040908@cisco.com> Date: Thu, 05 May 2011 08:52:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <4dc252ec.cac3e30a.2d35.707c@mx.google.com> In-Reply-To: <4dc252ec.cac3e30a.2d35.707c@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 12:52:19 -0000 (as co-chair) If people have concerns about IPR, I would like to see them aired. And if anyone is concerned about IPR they are aware of, then they are *obligated* to file an IPR disclosure. But lets not "self censor" without explaining that is what is happening. Thanks, Paul On 5/5/2011 3:32 AM, Roni Even wrote: > Stephan, > > I agree with Peter, this is about a mechanism and not about the data > itself. So I am not sure about the concern for IPR on being able to > describe sender capabilities. > > Roni Even > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Peter Musgrave > *Sent:* Saturday, April 23, 2011 8:52 PM > *To:* Stephan Wenger > *Cc:* CLUE > *Subject:* Re: [clue] FW: New Version Notification for > draft-romanow-clue-telepresence-requirements-02 > > Hi Stephan > > On 2011-04-22, at 1:41 PM, Stephan Wenger wrote: > > > > It's an IPR concern that led to the SHOULD. I prefer the WG has the > freedom to leave out specification text addressing this requirement if IPR > surfaces, which (in this case) seems likely to me. Sorry for not being > more specific on this public mailing list. > > REQMT-4: The solution SHOULD support a mechanism by which a sending > > endpoint or MCU can describe aspects of its > > characteristics and attributes. > > Do I understand this to mean that you are concerned about IPR regarding > the mechanism of describing the aspects and characteristics? > > Or do you mean that there might be IPR associated with the > characteristics/attributes themselves? > > If the later, then I think a MUST would be ok, since the requirement is > for a mechanism. > > I have the opposite bias - I prefer MUST for requirements - otherwise > why call them requirements? > > A section which describes additional goals (as opposed to requirements) > could be a place for SHOULD clauses. > > Peter > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From hmmr@cisco.com Thu May 5 06:45:53 2011 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 D11E7E0782 for ; Thu, 5 May 2011 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.677 X-Spam-Level: X-Spam-Status: No, score=-10.677 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 yM3tCuNmuXg2 for ; Thu, 5 May 2011 06:45:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE67E0593 for ; Thu, 5 May 2011 06:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=5806; q=dns/txt; s=iport; t=1304603150; x=1305812750; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=um+EyHtzUW9Ko15/kmsblF/R6hnhiXht+SnZeL9AAw8=; b=EV8fyikfEsMIYB4GfWURxu/4d4XVRADETGBpKZ+uk5/QyOpY62uZrrOK WNuT25cfVev1G7CC5bWoFXTMzV6o+PeIy91L6JZIpMEv57gxW5NoXpeZS ql7Gb095I2GKX3kCX73jW/+/zDYFfwM6WZjyzmxQImPI+ZaCVza0r0hbj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicBAMWowk2tJV2a/2dsb2JhbACEUJNBjTNyd6ccjQGRMoEqg1yBAQSGOI0+ikE X-IronPort-AV: E=Sophos;i="4.64,319,1301875200"; d="scan'208";a="309059036" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 13:45:49 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p45DjnIU017863; Thu, 5 May 2011 13:45:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 08:45:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 5 May 2011 08:45:47 -0500 Message-ID: In-Reply-To: <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] My commentson draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwAwU2PrUqxJliiTnmBiJQnx57OfQAABRcwAo1VW9AADPzbIA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> From: "Mike Hammer (hmmr)" To: "Roni Even" , "CLUE" X-OriginalArrivalTime: 05 May 2011 13:45:49.0151 (UTC) FILETIME=[BE062EF0:01CC0B2A] Subject: Re: [clue] My commentson draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 13:45:53 -0000 Um9uaSwNCg0KVGhpbmsgb2YgaXQgYXMgZXllIHN5bmMuDQoNCk5vIHZlbnRyaWxvcXVpc20gaGVy ZS4NCg0KTWlrZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBSb25pIEV2ZW4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMDUsIDIwMTEgNDozMiBBTQ0KVG86ICdD TFVFJw0KU3ViamVjdDogW2NsdWVdIE15IGNvbW1lbnRzb24gZHJhZnQtcm9tYW5vdy1jbHVlLXRl bGVwcmVzZW5jZS1yZXF1aXJlbWVudHMtMDINCg0KSGksDQpJIHJlYWQgdGhlIGRyYWZ0IGFuZCB0 aGUgcmVxdWlyZW1lbnRzIGFuZCBhbHNvIGxvb2tlZCBhdCB0aGUgZW1haWwgdGhyZWFkLg0KDQpU aGUgb25lIHRoaW5nIHRoYXQgYm90aGVyZWQgbWUgd2FzIHRoZSB0ZXJtcyB1c2VkLg0KUmVxdWly ZW1lbnQgMSBhbmQgMiB0YWxrIGFib3V0IGRlc2NyaWJpbmcgc3BhdGlhbCBhcnJhbmdlbWVudC4N Cg0KUmVxdWlyZW1lbnQgMyB0YWxrIGFib3V0IHNwYXRpYWwgbWF0Y2hpbmcgb2YgYXVkaW8gYW5k IHZpZGVvIC0gSSBhbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgdG8gaGF2ZSB0aGlzIGFzIGEgTVVT VCByZXF1aXJlbWVudC4gSSB1bmRlcnN0YW5kIGxpcCBzeW5jaCB3aWxsIGJlIHJlcXVpcmVkIGFu ZCBpcyBub3QgbWVudGlvbmVkIG9yIGl0IGNhbiBiZSB0aGF0IEkgZG8gbm90IHVuZGVyc3RhbmQg d2hhdCBzcGF0aWFsIG1hdGNoaW5nIG1lYW5zIGhlcmUuDQoNClJlcXVpcmVtZW50IDQgdGFsayBh Ym91dCBjaGFyYWN0ZXJpc3RpY3MgYW5kIGF0dHJpYnV0ZS4gSSBzYXcgY2hhcmFjdGVyaXN0aWNz IG1lbnRpb25lZCBpbiBzZWN0aW9uIDQgIkNoYXJhY3RlcmlzdGljcyBpbmNsdWRlIG51bWJlciwg cGxhY2VtZW50LCBjYXB0dXJlL3JlbmRlciBhbmdsZSwgcmVzb2x1dGlvbiBvZiBjYW1lcmFzIGFu ZCBzY3JlZW5zLCAgc3BhdGlhbCBsb2NhdGlvbiBhbmQgbWl4aW5nIHBhcmFtZXRlcnMgb2YgbWlj cm9waG9uZXMuIiBBbmQgbm90aWNlZCB0aGF0IEFsbHluIGluIHRoZSBlbWFpbCB0aHJlYWQgaGFk ICIgU2luY2UgY2hhcmFjdGVyaXN0aWNzIG9mIG1lZGlhIHN0cmVhbXMgZHVyaW5nIGEgdGVsZXBy ZXNlbmNlIGNvbmZlcmVuY2UgbWF5IGNoYW5nZSwgc3VjaCBhcyBiYW5kd2lkdGgsIHJlc29sdXRp b24iLiBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBzcGVjaWZ5IHdoYXQgd2UgbWVhbiBieSBlbmRw b2ludCBjaGFyYWN0ZXJpc3RpY3MgYW5kIHN0cmVhbSBjaGFyYWN0ZXJpc3RpY3MgYW5kIGFyZSB0 aGVzZSB0aGUgdGVybXMgd2Ugc2hvdWxkIHVzZSBpbiBhbGwgdGhlIHJlcXVpcmVtZW50cy4NCg0K UmVxdWlyZW1lbnQgNSB1c2VzIHNwZWNpZmllZCBpbmZvcm1hdGlvbiBhYm91dCBpdHNlbGYgKHNl ZSB0aGUgY29tbWVudCBvbiByZXF1aXJlbWVudCA0KS4gSXMgdGhpcyB0aGUgcmVjZWl2ZWQgZW5k cG9pbnQgcmVjZWl2ZSBjaGFyYWN0ZXJpc3RpY3M/DQoNClJlcXVpcmVtZW50IDYgYmFzZWQgb24g dGhlIGFib3ZlIGNvbW1lbnQgc2hvdWxkIHByb2JhYmx5IGRpc2N1c3MgZHluYW1pYyBjaGFuZ2Vz IGluIHN0cmVhbSBjaGFyYWN0ZXJpc3RpY3MuDQoNClJlcXVpcmVtZW50IDcgc2hvdWxkIHRhbGsg YWJvdXQgdGhlIHN0cmVhbXMgY2hhcmFjdGVyaXN0aWNzIGFuZCBub3QgdGhlIGRlc2NyaXB0aW9u IG9mIHRoZSBzdHJlYW1zLg0KDQpJIHRoaW5rIHRoYXQgaWYgd2UgZ28gdG8gYSBjb21tb24gbGFu Z3VhZ2UgaW4gYWxsIHJlcXVpcmVtZW50cyBpdCB3aWxsIGJlIGVhc2llciB0byBzZWUgdGhlIHJl ZHVuZGFuY3kgYmV0d2VlbiB0aGUgcmVxdWlyZW1lbnRzLg0KDQoNCkkgd2FzIHdvbmRlcmluZyBh Ym91dCByZXF1aXJlbWVudCAxNCAtIEkgdGFrZSBpdCB0aGF0IGl0IG1lYW5zIHRoYXQgaXQgbXVz dCBiZSBwb3NzaWJsZSB0byBvcGVuIGFsbCBtZWRpYSBjaGFubmVscyBhZnRlciBvbmUgb2ZmZXIg YW5zd2VyIGV4Y2hhbmdlLiBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBoYXZlIHN1Y2ggYSBz dHJvbmcgc3RhdGVtZW50IGN1cnJlbnRseS4gSSB0aGluayBpdCBpcyBhbiBpbXBvcnRhbnQgb2Jq ZWN0aXZlIGJ1dCBiYXNlZCBvbiBteSBjdXJyZW50IGV4cGVyaWVuY2Ugd2l0aCBkdWFsIHN0cmVh bSBzdXBwb3J0IChILjIzOSBsaWtlKSBhbmQgdGhlIGN1cnJlbnQgbWVkaWEgY2FwYWJpbGl0eSBu ZWdvdGlhdGlvbiBJIHRoaW5rIGl0IGlzIHZlcnkgY2hhbGxlbmdpbmcgd2hlbiBjb25zaWRlcmlu ZyAgIGJhY2t3YXJkIGNvbXB1dGFiaWxpdHkgKCJzdXBwb3J0IGZvciAibGVnYWN5IiBzeXN0ZW1z KS4NCg0KSSBhbSBhbHNvIG1pc3NpbmcgYSByZXF1aXJlbWVudCBmb3IgImxlZ2FjeSIgc3lzdGVt IHN1cHBvcnQgbGlrZSB0aGUgc29sdXRpb24gTVVTVCBlbmFibGUgYSBzeXN0ZW0gdGhhdCBkb2Vz IG5vdCBzdXBwb3J0IHRoZSBtZWNoYW5pc20gdG8gc2VsZWN0IHRoZSBiZXN0IHNldCBvZiBzdHJl YW1zIHRvIHJlbmRlciAoYXVkaW8gKyB2aWRlbykuDQoNCg0KVGhhbmtzDQpSb25pIEV2ZW4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBBbGx5biBS b21hbm93IChhbGx5bikNCj4gU2VudDogRnJpZGF5LCBBcHJpbCAyMiwgMjAxMSAxMDo0OCBBTQ0K PiBUbzogQ0xVRQ0KPiBTdWJqZWN0OiBbY2x1ZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcm9tYW5vdy1jbHVlLQ0KPiB0ZWxlcHJlc2VuY2UtcmVxdWlyZW1lbnRzLTAy DQo+IA0KPiBGb2xrcywNCj4gSSByZXZpc2VkIG15IHJlcXVpcmVtZW50IGRvY3VtZW50IGJhc2Vk IG9uIHRoZSBudW1lcm91cyBoZWxwZnVsDQo+IGNvbW1lbnRzIG1hZGUgZHVyaW5nIHRoZSBXRyBt ZWV0aW5nIGluIFByYWd1ZS4gQW4gYXBwZW5kaXggb3V0bGluZXMgdGhlDQo+IG1haW4gY2hhbmdl cy4NCj4gDQo+IEnigJltIGRlbGlnaHRlZCB0aGF0IFN0ZXBoYW4gV2VuZ2VyIGhhcyBzaWduaWZp Y2FudGx5IGNvbnRyaWJ1dGVkIHRvIHRoZQ0KPiBkcmFmdCBhbmQgYWdyZWVkIHRvIGJlIGEgY28t YXV0aG9yIC0gbXVjaCBhcHByZWNpYXRpb24sIFN0ZXBoYW4uDQo+IA0KPiBMb29raW5nIGZvcndh cmQgdG8gZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQtDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEFs bHluDQo+IA0KPiAtLS0tLS0tDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9t YW5vdy1jbHVlLXRlbGVwcmVzZW5jZS1yZXF1aXJlbWVudHMtDQo+IDAyLnR4dCBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsbHluIFJvbWFub3cgYW5kIHBvc3RlZCB0bw0KPiB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC1yb21hbm93LWNsdWUt dGVsZXByZXNlbmNlLXJlcXVpcmVtZW50cw0KPiBSZXZpc2lvbjoJIDAyDQo+IFRpdGxlOgkJIFJl cXVpcmVtZW50cyBmb3IgVGVsZXByZXNlbmNlIE11bHRpLVN0cmVhbXMNCj4gQ3JlYXRpb25fZGF0 ZToJIDIwMTEtMDQtMjINCj4gV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KPiBOdW1i ZXJfb2ZfcGFnZXM6IDEwDQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBtZW1vIGRpc2N1c3NlcyB0 aGUgcmVxdWlyZW1lbnRzIGZvciBhIHNwZWNpZmljYXRpb24gdGhhdCBlbmFibGVzDQo+IHRlbGVw cmVzZW5jZSBpbnRlcm9wZXJhYmlsaXR5LCBieSBkZXNjcmliaW5nIHRoZSByZWxhdGlvbnNoaXAg YmV0d2Vlbg0KPiBtdWx0aXBsZSBSVFAgc3RyZWFtcy4gIEluIGFkZGl0aW9uLCB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgYW5kDQo+IGRlZmluaXRpb25zIGFyZSBhbHNvIGNvdmVyZWQgaGVyZWluLg0K PiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdC4NCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlz dA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2x1ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From stewe@stewe.org Thu May 5 08:41:05 2011 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 1AD36E06FA for ; Thu, 5 May 2011 08:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 stf02Eid9LgE for ; Thu, 5 May 2011 08:41:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9AE0689 for ; Thu, 5 May 2011 08:41:01 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15676-1743317 for multiple; Thu, 05 May 2011 17:41:00 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 05 May 2011 08:29:53 -0700 From: Stephan Wenger To: Roni Even , 'Peter Musgrave' Message-ID: Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 In-Reply-To: <4dc252ec.cac3e30a.2d35.707c@mx.google.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3387429658_22193789" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: 'CLUE' Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 15:41:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3387429658_22193789 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Right. I should have read this more carefully. For this one, MUST is fine with me. (This was one of the requirements where Allyn and me worked on in a rather uncoordinated fashion, late at night.) Stephan From: Roni Even Date: Thu, 5 May 2011 10:32:18 +0300 To: 'Peter Musgrave' , Stephan Wenger Cc: 'CLUE' Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 Stephan, I agree with Peter, this is about a mechanism and not about the data itself. So I am not sure about the concern for IPR on being able to describe sender capabilities. Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Saturday, April 23, 2011 8:52 PM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 Hi Stephan On 2011-04-22, at 1:41 PM, Stephan Wenger wrote: It's an IPR concern that led to the SHOULD. I prefer the WG has the freedom to leave out specification text addressing this requirement if IPR surfaces, which (in this case) seems likely to me. Sorry for not being more specific on this public mailing list. REQMT-4: The solution SHOULD support a mechanism by which a sending endpoint or MCU can describe aspects of its characteristics and attributes. Do I understand this to mean that you are concerned about IPR regarding the mechanism of describing the aspects and characteristics? Or do you mean that there might be IPR associated with the characteristics/attributes themselves? If the later, then I think a MUST would be ok, since the requirement is for a mechanism. I have the opposite bias - I prefer MUST for requirements - otherwise why call them requirements? A section which describes additional goals (as opposed to requirements) could be a place for SHOULD clauses. Peter --B_3387429658_22193789 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Right.  I should have r= ead this more carefully.  For this one, MUST is fine with me.
(This was one of the requirements where Allyn and me worked on in a rather = uncoordinated fashion, late at night.)
Stephan
 

From: Roni Even <ron.even.tlv@gmail.com>
Date: Thu, 5 May 2011 10:32:18 +0300
<= span style=3D"font-weight:bold">To: 'Peter Musgrave' <peter.musgrave@magorcorp.com>, Steph= an Wenger <stewe@stewe.org>
Cc: 'CLUE' <clue@ietf.org>
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-teleprese= nce-requirements-02

Stephan,

I a= gree with Peter, this is about a mechanism and not about the data itself. &n= bsp;So I am not sure about the concern for IPR on being able to describe sen= der capabilities.

<= o:p> 

Roni Even

 

 

From: clue-boun= ces@ietf.org [mailto:clue-bounces= @ietf.org] On Behalf Of Peter Musgrave
Sent: Saturday, = April 23, 2011 8:52 PM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue= -telepresence-requirements-02

 

Hi Stephan

<= div>

 

On 2011-04-22, at 1:41 PM, Stephan Wenger wrote:



It's an IPR concern that led to the SHOULD.  I prefer the WG ha= s the
freedom to leave out specifi= cation text addressing this requirement if IPR
surfaces, which (in this case) seems likely to me.  Sorry f= or not being
more specific on this = public mailing list.

 

REQMT-4:   The solution SHOULD support a mechanism by wh=
ich a sending
         &n=
bsp;    endpoint or MCU can describe aspects of its
&nb=
sp;             =
characteristics and attributes.=

 

= Do I understand this to mean that you are concerned ab= out IPR regarding the mechanism of describing the aspects and characteristic= s? <= /span>

 

Or do you mean that there might be IPR associated with the cha= racteristics/attributes themselves?

 

If the later, then I think a MUST w= ould be ok, since the requirement is for a mechanism.

 

I have the opposi= te bias - I prefer MUST for requirements - otherwise why call them requireme= nts?

 

A section which describes additional goals (as opposed to requirem= ents) could be a place for SHOULD clauses.

=  

=

Peter

--B_3387429658_22193789-- From stewe@stewe.org Thu May 5 08:55:26 2011 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 90874E06A6 for ; Thu, 5 May 2011 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 BqNeGtkojlTv for ; Thu, 5 May 2011 08:55:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id DDADBE0689 for ; Thu, 5 May 2011 08:55:22 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15682-1743317 for multiple; Thu, 05 May 2011 17:55:21 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 05 May 2011 08:55:14 -0700 From: Stephan Wenger To: Paul Kyzivat , Message-ID: Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 In-Reply-To: <4DC29D81.7040908@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 15:55:26 -0000 Hi Paul, On 5.5.2011 05:52 , "Paul Kyzivat" wrote: >[...] >And if anyone is concerned about IPR they are aware of, then they are >*obligated* to file an IPR disclosure. > >But lets not "self censor" without explaining that is what is happening. Sorry, but that cannot be left standing as is. The requirement for IPR disclosure for me extends to those patent claims that I am reasonably and personally aware of AND that are assertable by my employer or sponsor. Sections 6.1.1 and 6.1.2 of RFC 3979. Rest assured that I will disclose any of such IPR, perhaps in more detail than I'm obliged to do so. I have a history in doing exactly that. However, if the (suspected) patent claim is not owned by my employer or sponsor, I'm only "encouraged" to send mail at ipr@ietf and/or make a third party disclosure. Section 6.1.3 of RFC3979. There is a reason for this choice of (weak) language in RFC3979. Making third party disclosures involves certain risks in some legislations, especially for people like myself who do patent work for a living (and standardization as a hobby :-). Therefore, I regret to state that, except in most unusual situations, I will not talk openly about someone else' IPR in any other but the vaguest terms. Specifically, I will not name patent numbers, nor owners. That said, I do have to keep my employer's competitive position in mind. I want to avoid stepping on someone else's patent claims because we implement CLUE, and I want to avoid being driven out of the market because we don't (obviously hypothetically speaking in both instances). Therefore, I need to warn about someone else's IPR, or "kill" technologies I don't like for this reason based on fake technical arguments. The latter is common in standardization, but I think the former is more honest and less damaging and, ultimately more efficient. I promise not to throw FUD around, but then again, the definition of FUD is vague and context sensitive (depends on business model, own IPR position etc. etc.). In consequence, I expect to continue with vague warnings in the hopes that participants do their own research. Regards, Stephan On 5.5.2011 05:52 , "Paul Kyzivat" wrote: >(as co-chair) > >If people have concerns about IPR, I would like to see them aired. >And if anyone is concerned about IPR they are aware of, then they are >*obligated* to file an IPR disclosure. > >But lets not "self censor" without explaining that is what is happening. > > Thanks, > Paul > >On 5/5/2011 3:32 AM, Roni Even wrote: >> Stephan, >> >> I agree with Peter, this is about a mechanism and not about the data >> itself. So I am not sure about the concern for IPR on being able to >> describe sender capabilities. >> >> Roni Even >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Peter Musgrave >> *Sent:* Saturday, April 23, 2011 8:52 PM >> *To:* Stephan Wenger >> *Cc:* CLUE >> *Subject:* Re: [clue] FW: New Version Notification for >> draft-romanow-clue-telepresence-requirements-02 >> >> Hi Stephan >> >> On 2011-04-22, at 1:41 PM, Stephan Wenger wrote: >> >> >> >> It's an IPR concern that led to the SHOULD. I prefer the WG has the >> freedom to leave out specification text addressing this requirement if >>IPR >> surfaces, which (in this case) seems likely to me. Sorry for not being >> more specific on this public mailing list. >> >> REQMT-4: The solution SHOULD support a mechanism by which a sending >> >> endpoint or MCU can describe aspects of its >> >> characteristics and attributes. >> >> Do I understand this to mean that you are concerned about IPR regarding >> the mechanism of describing the aspects and characteristics? >> >> Or do you mean that there might be IPR associated with the >> characteristics/attributes themselves? >> >> If the later, then I think a MUST would be ok, since the requirement is >> for a mechanism. >> >> I have the opposite bias - I prefer MUST for requirements - otherwise >> why call them requirements? >> >> A section which describes additional goals (as opposed to requirements) >> could be a place for SHOULD clauses. >> >> Peter >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Thu May 5 09:42:53 2011 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 52633E0798 for ; Thu, 5 May 2011 09:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i89mytdTD08 for ; Thu, 5 May 2011 09:42:52 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF433E0790 for ; Thu, 5 May 2011 09:42:51 -0700 (PDT) Received: by wyb29 with SMTP id 29so2017728wyb.31 for ; Thu, 05 May 2011 09:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=c/fo2o5fq9vNIZTN506HxdKpl4T2KoUyU0YbC02bUFM=; b=Dg6TWAMu82bXB7OgrwjihpIILhm2uHzstpzk32Elje5ChATgoNIbwRDETfXb7YQMu5 25WsyNHo78pO/izo4rVxJSM4O5Lcmr6qM6d27qtVFb47Q6y3o56rczBjbReEDnHBSBKF BxgullJ11od2AZ7tyuRKSpTbCKX95/vP34ZgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=UQ5kgornOZxcEKfG4f3qhrW554HEZSYrkAO9GFS2SF2iFEyDf6cI/mhIl5F2bLaaWI ryS0CcHcXk9JBVrTFGwFDQOH1hH/1MNm/otOskgmx6MHhp5YRZJO+2Da1leGhvNLM+In unXLIHPPy4nNqb7qCCLFHLU6yN5HCU6j1scfU= Received: by 10.216.64.139 with SMTP id c11mr6560183wed.46.1304613770499; Thu, 05 May 2011 09:42:50 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-32-24.red.bezeqint.net [79.183.32.24]) by mx.google.com with ESMTPS id d6sm1189998wer.2.2011.05.05.09.42.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 09:42:48 -0700 (PDT) From: "Roni Even" To: "'Mike Hammer \(hmmr\)'" , "'CLUE'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> In-Reply-To: Date: Thu, 5 May 2011 19:41:12 +0300 Message-ID: <4dc2d388.06f0d80a.1ada.ffff84b1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwAwU2PrUqxJliiTnmBiJQnx57OfQAABRcwAo1VW9AADPzbIAAGGZ5Q Content-Language: en-us X-Mailman-Approved-At: Thu, 05 May 2011 12:36:11 -0700 Subject: Re: [clue] My commentson draft-romanow-clue-telepresence-requirements-02 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, 05 May 2011 16:42:53 -0000 Hi, I am not sure since we were talking about a single audio stream and = multiple video streams or is this for a different use case. Roni > -----Original Message----- > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > Sent: Thursday, May 05, 2011 4:46 PM > To: Roni Even; CLUE > Subject: RE: [clue] My commentson draft-romanow-clue-telepresence- > requirements-02 >=20 > Roni, >=20 > Think of it as eye sync. >=20 > No ventriloquism here. >=20 > Mike >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni Even > Sent: Thursday, May 05, 2011 4:32 AM > To: 'CLUE' > Subject: [clue] My commentson draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi, > I read the draft and the requirements and also looked at the email > thread. >=20 > The one thing that bothered me was the terms used. > Requirement 1 and 2 talk about describing spatial arrangement. >=20 > Requirement 3 talk about spatial matching of audio and video - I am = not > sure that we need to have this as a MUST requirement. I understand lip > synch will be required and is not mentioned or it can be that I do not > understand what spatial matching means here. >=20 > Requirement 4 talk about characteristics and attribute. I saw > characteristics mentioned in section 4 "Characteristics include = number, > placement, capture/render angle, resolution of cameras and screens, > spatial location and mixing parameters of microphones." And noticed > that Allyn in the email thread had " Since characteristics of media > streams during a telepresence conference may change, such as = bandwidth, > resolution". I think that we need to specify what we mean by endpoint > characteristics and stream characteristics and are these the terms we > should use in all the requirements. >=20 > Requirement 5 uses specified information about itself (see the comment > on requirement 4). Is this the received endpoint receive > characteristics? >=20 > Requirement 6 based on the above comment should probably discuss > dynamic changes in stream characteristics. >=20 > Requirement 7 should talk about the streams characteristics and not = the > description of the streams. >=20 > I think that if we go to a common language in all requirements it will > be easier to see the redundancy between the requirements. >=20 >=20 > I was wondering about requirement 14 - I take it that it means that it > must be possible to open all media channels after one offer answer > exchange. I am not sure if we should have such a strong statement > currently. I think it is an important objective but based on my = current > experience with dual stream support (H.239 like) and the current media > capability negotiation I think it is very challenging when considering > backward computability ("support for "legacy" systems). >=20 > I am also missing a requirement for "legacy" system support like the > solution MUST enable a system that does not support the mechanism to > select the best set of streams to render (audio + video). >=20 >=20 > Thanks > Roni Even >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Allyn Romanow (allyn) > > Sent: Friday, April 22, 2011 10:48 AM > > To: CLUE > > Subject: [clue] FW: New Version Notification for draft-romanow-clue- > > telepresence-requirements-02 > > > > Folks, > > I revised my requirement document based on the numerous helpful > > comments made during the WG meeting in Prague. An appendix outlines > the > > main changes. > > > > I=E2=80=99m delighted that Stephan Wenger has significantly = contributed to > the > > draft and agreed to be a co-author - much appreciation, Stephan. > > > > Looking forward to discussion of the draft- > > > > Best regards, > > Allyn > > > > ------- > > > > A new version of I-D, draft-romanow-clue-telepresence-requirements- > > 02.txt has been successfully submitted by Allyn Romanow and posted = to > > the IETF repository. > > > > Filename: draft-romanow-clue-telepresence-requirements > > Revision: 02 > > Title: Requirements for Telepresence Multi-Streams > > Creation_date: 2011-04-22 > > WG ID: Independent Submission > > Number_of_pages: 10 > > > > Abstract: > > This memo discusses the requirements for a specification that = enables > > telepresence interoperability, by describing the relationship = between > > multiple RTP streams. In addition, the problem statement and > > definitions are also covered herein. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri May 6 14:04:40 2011 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 179A3E084D for ; Fri, 6 May 2011 14:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkkdZTa0iWcd for ; Fri, 6 May 2011 14:04:39 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 07D9AE084C for ; Fri, 6 May 2011 14:04:36 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Fri, 6 May 2011 14:04:36 -0700 From: "Duckworth, Mark" To: CLUE Date: Fri, 6 May 2011 14:05:33 -0700 Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwAwU2PrUqxJliiTnmBiJQnx57OfQAABRcwAo1VW9AATZsl0A== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> In-Reply-To: <4dc260f0.47f3d80a.6529.6ad9@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 06 May 2011 21:04:40 -0000 SGkgUm9uaSwNCg0KUkVRTVQtMyBpcyBhYm91dCBtYWtpbmcgdGhlIGF1ZGlvIHNvdW5kIGxpa2Ug aXQgaXMgY29taW5nIGZyb20gdGhlIHNhbWUgcGxhY2UgYXMgdGhlIGltYWdlIG9mIHRoZSBwZXJz b24gd2hvIGlzIHNwZWFraW5nLiAgVGhpcyBpcyByZWxldmFudCBmb3IgY2FzZXMgdGhhdCB1c2Ug bXVsdGkgY2hhbm5lbCBhdWRpbywgZm9yIGV4YW1wbGUgY29tbW9uIGNhc2VzIGFyZSBzdGVyZW8g YW5kIGxlZnQvY2VudGVyL3JpZ2h0IGNoYW5uZWxzLiAgSSB0aGluayBNVVNUIGlzIGFwcHJvcHJp YXRlLg0KDQpTeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhdWRpbyBhbmQgdmlkZW8gd2FzIGEgcmVx dWlyZW1lbnQgaW4gYW4gZWFybGllciBkcmFmdCwgYnV0IEkgdGhpbmsgbWF5YmUgdGhlIGludGVu dCB3YXMgZm9yIHNwYXRpYWwgbWF0Y2hpbmcgcmF0aGVyIHRoYW4gbGlwIHN5bmMuICBJdCBwcm9i YWJseSB3b3VsZG4ndCBodXJ0IHRvIGFkZCBhbm90aGVyIHJlcXVpcmVtZW50IGFib3V0IGxpcCBz eW5jLg0KDQpBYm91dCBjaGFyYWN0ZXJpc3RpY3MgLSBpbiBhbiBlYXJsaWVyIGVtYWlsLCBJIGFz a2VkIGFib3V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gUkVRTVQtNCBhbmQgUkVRTVQtNywgYW5k IEFsbHluIHNhaWQgc2hlIHRob3VnaHQgdGhleSB3ZXJlIHJlZHVuZGFudCBhbmQgb25lIGNvdWxk IGJlIHJlbW92ZWQuICBJIGFncmVlLCBhbmQgbXkgcG9pbnQgaXMgd2Ugc2hvdWxkIHRhbGsgYWJv dXQgY2hhcmFjdGVyaXN0aWNzIG9mIHN0cmVhbXMgYW5kIG5vdCBjaGFyYWN0ZXJpc3RpY3Mgb2Yg ZW5kcG9pbnRzLiAgSWYgd2UgdGhpbmsgYW4gZW5kcG9pbnQgY2hhcmFjdGVyaXN0aWMgaXMgaW1w b3J0YW50LCB0aGVuIGl0IHByb2JhYmx5IHJlbGF0ZXMgdG8gdGhlIHN0cmVhbXMgc29tZWhvdyBh bmQgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiB0ZXJtcyBvZiB0aGUgc3RyZWFtcyByYXRoZXIgdGhh biB0aGUgZW5kcG9pbnQuDQoNCkZvciBSRVFNVC01LCBJIGludGVycHJldCBpdCB0byBtZWFuIGNo YXJhY3RlcmlzdGljcyBhYm91dCB0aGUgc3RyZWFtcyB0aGUgcmVjZWl2ZXIgY2FuIChvciB3YW50 cyB0bykgcmVjZWl2ZS4gIEFnYWluLCBJIHRoaW5rIHdlIHNob3VsZCB0YWxrIGFib3V0IHN0cmVh bSBjaGFyYWN0ZXJpc3RpY3MgYW5kIG5vdCBlbmRwb2ludCBjaGFyYWN0ZXJpc3RpY3MuICBUaGlz IG1pZ2h0IGJlIHJlYWxpemVkIGJ5IHRoZSByZWNlaXZlciBhc2tpbmcgdGhlIHNlbmRlciB0byBz ZW5kIHN0cmVhbXMgd2l0aCBjZXJ0YWluIGNoYXJhY3RlcmlzdGljcy4NCg0KWW91IG1pZ2h0IGJl IHJpZ2h0IGFib3V0IFJFUU1ULTE0IGJlaW5nIHRvbyBzdHJvbmcsIEkgd291bGRuJ3QgbWluZCBy ZWxheGluZyBpdC4NCg0KUmVnYXJkcywNCk1hcmsgRHVja3dvcnRoDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1 ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUm9uaSBFdmVuDQo+IFNlbnQ6IFRo dXJzZGF5LCBNYXkgMDUsIDIwMTEgNDozMiBBTQ0KPiBUbzogJ0NMVUUnDQo+IFN1YmplY3Q6IFtj bHVlXSBNeSBjb21tZW50cyBvbiBkcmFmdC1yb21hbm93LWNsdWUtdGVsZXByZXNlbmNlLQ0KPiBy ZXF1aXJlbWVudHMtMDINCj4gDQo+IEhpLA0KPiBJIHJlYWQgdGhlIGRyYWZ0IGFuZCB0aGUgcmVx dWlyZW1lbnRzIGFuZCBhbHNvIGxvb2tlZCBhdCB0aGUgZW1haWwNCj4gdGhyZWFkLg0KPiANCj4g VGhlIG9uZSB0aGluZyB0aGF0IGJvdGhlcmVkIG1lIHdhcyB0aGUgdGVybXMgdXNlZC4NCj4gUmVx dWlyZW1lbnQgMSBhbmQgMiB0YWxrIGFib3V0IGRlc2NyaWJpbmcgc3BhdGlhbCBhcnJhbmdlbWVu dC4NCj4gDQo+IFJlcXVpcmVtZW50IDMgdGFsayBhYm91dCBzcGF0aWFsIG1hdGNoaW5nIG9mIGF1 ZGlvIGFuZCB2aWRlbyAtIEkgYW0gbm90DQo+IHN1cmUgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgdGhp cyBhcyBhIE1VU1QgcmVxdWlyZW1lbnQuIEkgdW5kZXJzdGFuZCBsaXANCj4gc3luY2ggd2lsbCBi ZSByZXF1aXJlZCBhbmQgaXMgbm90IG1lbnRpb25lZCBvciBpdCBjYW4gYmUgdGhhdCBJIGRvIG5v dA0KPiB1bmRlcnN0YW5kIHdoYXQgc3BhdGlhbCBtYXRjaGluZyBtZWFucyBoZXJlLg0KPiANCj4g UmVxdWlyZW1lbnQgNCB0YWxrIGFib3V0IGNoYXJhY3RlcmlzdGljcyBhbmQgYXR0cmlidXRlLiBJ IHNhdw0KPiBjaGFyYWN0ZXJpc3RpY3MgbWVudGlvbmVkIGluIHNlY3Rpb24gNCAiQ2hhcmFjdGVy aXN0aWNzIGluY2x1ZGUgbnVtYmVyLA0KPiBwbGFjZW1lbnQsIGNhcHR1cmUvcmVuZGVyIGFuZ2xl LCByZXNvbHV0aW9uIG9mIGNhbWVyYXMgYW5kIHNjcmVlbnMsDQo+IHNwYXRpYWwgbG9jYXRpb24g YW5kIG1peGluZyBwYXJhbWV0ZXJzIG9mIG1pY3JvcGhvbmVzLiIgQW5kIG5vdGljZWQNCj4gdGhh dCBBbGx5biBpbiB0aGUgZW1haWwgdGhyZWFkIGhhZCAiIFNpbmNlIGNoYXJhY3RlcmlzdGljcyBv ZiBtZWRpYQ0KPiBzdHJlYW1zIGR1cmluZyBhIHRlbGVwcmVzZW5jZSBjb25mZXJlbmNlIG1heSBj aGFuZ2UsIHN1Y2ggYXMgYmFuZHdpZHRoLA0KPiByZXNvbHV0aW9uIi4gSSB0aGluayB0aGF0IHdl IG5lZWQgdG8gc3BlY2lmeSB3aGF0IHdlIG1lYW4gYnkgZW5kcG9pbnQNCj4gY2hhcmFjdGVyaXN0 aWNzIGFuZCBzdHJlYW0gY2hhcmFjdGVyaXN0aWNzIGFuZCBhcmUgdGhlc2UgdGhlIHRlcm1zIHdl DQo+IHNob3VsZCB1c2UgaW4gYWxsIHRoZSByZXF1aXJlbWVudHMuDQo+IA0KPiBSZXF1aXJlbWVu dCA1IHVzZXMgc3BlY2lmaWVkIGluZm9ybWF0aW9uIGFib3V0IGl0c2VsZiAoc2VlIHRoZSBjb21t ZW50DQo+IG9uIHJlcXVpcmVtZW50IDQpLiBJcyB0aGlzIHRoZSByZWNlaXZlZCBlbmRwb2ludCBy ZWNlaXZlDQo+IGNoYXJhY3RlcmlzdGljcz8NCj4gDQo+IFJlcXVpcmVtZW50IDYgYmFzZWQgb24g dGhlIGFib3ZlIGNvbW1lbnQgc2hvdWxkIHByb2JhYmx5IGRpc2N1c3MNCj4gZHluYW1pYyBjaGFu Z2VzIGluIHN0cmVhbSBjaGFyYWN0ZXJpc3RpY3MuDQo+IA0KPiBSZXF1aXJlbWVudCA3IHNob3Vs ZCB0YWxrIGFib3V0IHRoZSBzdHJlYW1zIGNoYXJhY3RlcmlzdGljcyBhbmQgbm90IHRoZQ0KPiBk ZXNjcmlwdGlvbiBvZiB0aGUgc3RyZWFtcy4NCj4gDQo+IEkgdGhpbmsgdGhhdCBpZiB3ZSBnbyB0 byBhIGNvbW1vbiBsYW5ndWFnZSBpbiBhbGwgcmVxdWlyZW1lbnRzIGl0IHdpbGwNCj4gYmUgZWFz aWVyIHRvIHNlZSB0aGUgcmVkdW5kYW5jeSBiZXR3ZWVuIHRoZSByZXF1aXJlbWVudHMuDQo+IA0K PiANCj4gSSB3YXMgd29uZGVyaW5nIGFib3V0IHJlcXVpcmVtZW50IDE0IC0gSSB0YWtlIGl0IHRo YXQgaXQgbWVhbnMgdGhhdCBpdA0KPiBtdXN0IGJlIHBvc3NpYmxlIHRvIG9wZW4gYWxsIG1lZGlh IGNoYW5uZWxzIGFmdGVyIG9uZSBvZmZlciBhbnN3ZXINCj4gZXhjaGFuZ2UuIEkgYW0gbm90IHN1 cmUgaWYgd2Ugc2hvdWxkIGhhdmUgc3VjaCBhIHN0cm9uZyBzdGF0ZW1lbnQNCj4gY3VycmVudGx5 LiBJIHRoaW5rIGl0IGlzIGFuIGltcG9ydGFudCBvYmplY3RpdmUgYnV0IGJhc2VkIG9uIG15IGN1 cnJlbnQNCj4gZXhwZXJpZW5jZSB3aXRoIGR1YWwgc3RyZWFtIHN1cHBvcnQgKEguMjM5IGxpa2Up IGFuZCB0aGUgY3VycmVudCBtZWRpYQ0KPiBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIEkgdGhpbmsg aXQgaXMgdmVyeSBjaGFsbGVuZ2luZyB3aGVuIGNvbnNpZGVyaW5nDQo+IGJhY2t3YXJkIGNvbXB1 dGFiaWxpdHkgKCJzdXBwb3J0IGZvciAibGVnYWN5IiBzeXN0ZW1zKS4NCj4gDQo+IEkgYW0gYWxz byBtaXNzaW5nIGEgcmVxdWlyZW1lbnQgZm9yICJsZWdhY3kiIHN5c3RlbSBzdXBwb3J0IGxpa2Ug dGhlDQo+IHNvbHV0aW9uIE1VU1QgZW5hYmxlIGEgc3lzdGVtIHRoYXQgZG9lcyBub3Qgc3VwcG9y dCB0aGUgbWVjaGFuaXNtIHRvDQo+IHNlbGVjdCB0aGUgYmVzdCBzZXQgb2Ygc3RyZWFtcyB0byBy ZW5kZXIgKGF1ZGlvICsgdmlkZW8pLg0KPiANCj4gDQo+IFRoYW5rcw0KPiBSb25pIEV2ZW4NCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBjbHVlLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0K PiA+IEFsbHluIFJvbWFub3cgKGFsbHluKQ0KPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjIsIDIw MTEgMTA6NDggQU0NCj4gPiBUbzogQ0xVRQ0KPiA+IFN1YmplY3Q6IFtjbHVlXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yb21hbm93LWNsdWUtDQo+ID4gdGVsZXByZXNl bmNlLXJlcXVpcmVtZW50cy0wMg0KPiA+DQo+ID4gRm9sa3MsDQo+ID4gSSByZXZpc2VkIG15IHJl cXVpcmVtZW50IGRvY3VtZW50IGJhc2VkIG9uIHRoZSBudW1lcm91cyBoZWxwZnVsDQo+ID4gY29t bWVudHMgbWFkZSBkdXJpbmcgdGhlIFdHIG1lZXRpbmcgaW4gUHJhZ3VlLiBBbiBhcHBlbmRpeCBv dXRsaW5lcw0KPiB0aGUNCj4gPiBtYWluIGNoYW5nZXMuDQo+ID4NCj4gPiBJ4oCZbSBkZWxpZ2h0 ZWQgdGhhdCBTdGVwaGFuIFdlbmdlciBoYXMgc2lnbmlmaWNhbnRseSBjb250cmlidXRlZCB0bw0K PiB0aGUNCj4gPiBkcmFmdCBhbmQgYWdyZWVkIHRvIGJlIGEgY28tYXV0aG9yIC0gbXVjaCBhcHBy ZWNpYXRpb24sIFN0ZXBoYW4uDQo+ID4NCj4gPiBMb29raW5nIGZvcndhcmQgdG8gZGlzY3Vzc2lv biBvZiB0aGUgZHJhZnQtDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gQWxseW4NCj4gPg0K PiA+IC0tLS0tLS0NCj4gPg0KPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yb21hbm93 LWNsdWUtdGVsZXByZXNlbmNlLXJlcXVpcmVtZW50cy0NCj4gPiAwMi50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGx5biBSb21hbm93IGFuZCBwb3N0ZWQgdG8NCj4gPiB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6CSBkcmFmdC1yb21hbm93LWNs dWUtdGVsZXByZXNlbmNlLXJlcXVpcmVtZW50cw0KPiA+IFJldmlzaW9uOgkgMDINCj4gPiBUaXRs ZToJCSBSZXF1aXJlbWVudHMgZm9yIFRlbGVwcmVzZW5jZSBNdWx0aS1TdHJlYW1zDQo+ID4gQ3Jl YXRpb25fZGF0ZToJIDIwMTEtMDQtMjINCj4gPiBXRyBJRDoJCSBJbmRlcGVuZGVudCBTdWJtaXNz aW9uDQo+ID4gTnVtYmVyX29mX3BhZ2VzOiAxMA0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gVGhp cyBtZW1vIGRpc2N1c3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBhIHNwZWNpZmljYXRpb24gdGhh dCBlbmFibGVzDQo+ID4gdGVsZXByZXNlbmNlIGludGVyb3BlcmFiaWxpdHksIGJ5IGRlc2NyaWJp bmcgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQo+ID4gbXVsdGlwbGUgUlRQIHN0cmVhbXMuICBJ biBhZGRpdGlvbiwgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KPiA+IGRlZmluaXRpb25zIGFy ZSBhbHNvIGNvdmVyZWQgaGVyZWluLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3Jl dGFyaWF0Lg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1ZSBtYWls aW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NsdWUNCg== From stewe@stewe.org Fri May 6 15:39:58 2011 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 BAB7EE0719 for ; Fri, 6 May 2011 15:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 ob58QT8SMtF2 for ; Fri, 6 May 2011 15:39:56 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3AE0705 for ; Fri, 6 May 2011 15:39:53 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 16160-1743317 for multiple; Sat, 07 May 2011 00:39:52 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 06 May 2011 15:39:32 -0700 From: Stephan Wenger To: "Duckworth, Mark" , CLUE Message-ID: Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 06 May 2011 22:39:58 -0000 Hi Mark, all, Please see inline. On 5.6.2011 14:05 , "Duckworth, Mark" wrote: >Hi Roni, > >REQMT-3 is about making the audio sound like it is coming from the same >place as the image of the person who is speaking. This is relevant for >cases that use multi channel audio, for example common cases are stereo >and left/center/right channels. I think MUST is appropriate. >Synchronization between audio and video was a requirement in an earlier >draft, but I think maybe the intent was for spatial matching rather than >lip sync. It probably wouldn't hurt to add another requirement about lip >sync. I think that lip-sync is something that is completely up to the implementation to enable. All the necessary protocol mechanisms are already available in RTP. You may even want to be have an option to disable lipsync from the user interface. There are many scenarios where lip-sync is helpful, but there are also others where it is not (where you want to render audio as quickly as you can, even at the cost of imperfect lipsync, for example on intercontinental teleconferences where the additive delay of video/lip-sync and lightspeed delay add up to a non-conversational experience) >[...] >For REQMT-5, I interpret it to mean characteristics about the streams the >receiver can (or wants to) receive. Again, I think we should talk about >stream characteristics and not endpoint characteristics. This might be >realized by the receiver asking the sender to send streams with certain >characteristics. Req 4 and 5 were meant as device characteristics. Stuff such as the spatial arrangement of microphones, cameras, screens, constraints the codecs may have, and so on. These are a superset of the stream characteristics that are sent in that they can include permutations of capabilities that are mutually exclusive, for example due to cycle restrictions. An example would be: in the 2003 TeleSuite system, for each camera field, we were able to either code either VGA or a variety of scaled down formats half-VGA, QVGA, and so on, that were be simulcast. > >You might be right about REQMT-14 being too strong, I wouldn't mind >relaxing it. The history of this requirement is that there was a requirement "solution is not to add delay". Allyn and I were dissecting what types of delay could be meant, and figured out that it can't be media path delay (as this is independent from the CLUE concepts), so it must be some other delay that matters. Call setup was the only one we came up with. I don't mind relaxing this, either, but do we really want to allow an additional round trip over offer-answer? If not, I don't see where significant adidtional delay can stem from... Stephan > >Regards, >Mark Duckworth > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Roni Even >> Sent: Thursday, May 05, 2011 4:32 AM >> To: 'CLUE' >> Subject: [clue] My comments on draft-romanow-clue-telepresence- >> requirements-02 >>=20 >> Hi, >> I read the draft and the requirements and also looked at the email >> thread. >>=20 >> The one thing that bothered me was the terms used. >> Requirement 1 and 2 talk about describing spatial arrangement. >>=20 >> Requirement 3 talk about spatial matching of audio and video - I am not >> sure that we need to have this as a MUST requirement. I understand lip >> synch will be required and is not mentioned or it can be that I do not >> understand what spatial matching means here. >>=20 >> Requirement 4 talk about characteristics and attribute. I saw >> characteristics mentioned in section 4 "Characteristics include number, >> placement, capture/render angle, resolution of cameras and screens, >> spatial location and mixing parameters of microphones." And noticed >> that Allyn in the email thread had " Since characteristics of media >> streams during a telepresence conference may change, such as bandwidth, >> resolution". I think that we need to specify what we mean by endpoint >> characteristics and stream characteristics and are these the terms we >> should use in all the requirements. >>=20 >> Requirement 5 uses specified information about itself (see the comment >> on requirement 4). Is this the received endpoint receive >> characteristics? >>=20 >> Requirement 6 based on the above comment should probably discuss >> dynamic changes in stream characteristics. >>=20 >> Requirement 7 should talk about the streams characteristics and not the >> description of the streams. >>=20 >> I think that if we go to a common language in all requirements it will >> be easier to see the redundancy between the requirements. >>=20 >>=20 >> I was wondering about requirement 14 - I take it that it means that it >> must be possible to open all media channels after one offer answer >> exchange. I am not sure if we should have such a strong statement >> currently. I think it is an important objective but based on my current >> experience with dual stream support (H.239 like) and the current media >> capability negotiation I think it is very challenging when considering >> backward computability ("support for "legacy" systems). >>=20 >> I am also missing a requirement for "legacy" system support like the >> solution MUST enable a system that does not support the mechanism to >> select the best set of streams to render (audio + video). >>=20 >>=20 >> Thanks >> Roni Even >>=20 >> > -----Original Message----- >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >> > Allyn Romanow (allyn) >> > Sent: Friday, April 22, 2011 10:48 AM >> > To: CLUE >> > Subject: [clue] FW: New Version Notification for draft-romanow-clue- >> > telepresence-requirements-02 >> > >> > Folks, >> > I revised my requirement document based on the numerous helpful >> > comments made during the WG meeting in Prague. An appendix outlines >> the >> > main changes. >> > >> > I=B9m delighted that Stephan Wenger has significantly contributed to >> the >> > draft and agreed to be a co-author - much appreciation, Stephan. >> > >> > Looking forward to discussion of the draft- >> > >> > Best regards, >> > Allyn >> > >> > ------- >> > >> > A new version of I-D, draft-romanow-clue-telepresence-requirements- >> > 02.txt has been successfully submitted by Allyn Romanow and posted to >> > the IETF repository. >> > >> > Filename: draft-romanow-clue-telepresence-requirements >> > Revision: 02 >> > Title: Requirements for Telepresence Multi-Streams >> > Creation_date: 2011-04-22 >> > WG ID: Independent Submission >> > Number_of_pages: 10 >> > >> > Abstract: >> > This memo discusses the requirements for a specification that enables >> > telepresence interoperability, by describing the relationship between >> > multiple RTP streams. In addition, the problem statement and >> > definitions are also covered herein. >> > >> > >> > >> > The IETF Secretariat. >> > >> > >> > _______________________________________________ >> > clue mailing list >> > clue@ietf.org >> > https://www.ietf.org/mailman/listinfo/clue >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Sat May 7 01:17:41 2011 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 83A62E073D for ; Sat, 7 May 2011 01:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.097 X-Spam-Level: X-Spam-Status: No, score=-104.097 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 YnPvM3U9-lJm for ; Sat, 7 May 2011 01:17:40 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD8E0679 for ; Sat, 7 May 2011 01:17:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKT0041RGDE0J@szxga03-in.huawei.com> for clue@ietf.org; Sat, 07 May 2011 16:17:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKT00M0EGDE0Y@szxga03-in.huawei.com> for clue@ietf.org; Sat, 07 May 2011 16:17:38 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-32-24.red.bezeqint.net [79.183.32.24]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKT0041EGD5Y2@szxml11-in.huawei.com>; Sat, 07 May 2011 16:17:38 +0800 (CST) Date: Sat, 07 May 2011 11:15:58 +0300 From: Roni Even In-reply-to: To: 'Stephan Wenger' , "'Duckworth, Mark'" , 'CLUE' Message-id: <054d01cc0c8f$03147230$093d5690$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwMPo/7+Y9jsN67Sjeuo/MxGH/JeAAT0AkA References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 08:17:41 -0000 Hi, My comments were trying to highlight the point that we need to specify = what we mean by characteristics in the requirements probably in section 1 or = 4 of the draft. Like I said I noticed that the draft sometime means streams = characteristics and sometime endpoint characteristics. On endpoint characteristic, I am = not sure if it talks about the systems itself (number of cameras, screens, = ..) or also about the whole room when discussing spatial relation between = the audio and the video. Thanks Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Stephan Wenger > Sent: Saturday, May 07, 2011 1:40 AM > To: Duckworth, Mark; CLUE > Subject: Re: [clue] My comments on draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi Mark, all, > Please see inline. >=20 > On 5.6.2011 14:05 , "Duckworth, Mark" > wrote: >=20 > >Hi Roni, > > > >REQMT-3 is about making the audio sound like it is coming from the > same > >place as the image of the person who is speaking. This is relevant > for > >cases that use multi channel audio, for example common cases are > stereo > >and left/center/right channels. I think MUST is appropriate. > >Synchronization between audio and video was a requirement in an > earlier > >draft, but I think maybe the intent was for spatial matching rather > than > >lip sync. It probably wouldn't hurt to add another requirement about > lip > >sync. >=20 > I think that lip-sync is something that is completely up to the > implementation to enable. All the necessary protocol mechanisms are > already available in RTP. You may even want to be have an option to > disable lipsync from the user interface. There are many scenarios > where > lip-sync is helpful, but there are also others where it is not (where > you > want to render audio as quickly as you can, even at the cost of > imperfect > lipsync, for example on intercontinental teleconferences where the > additive delay of video/lip-sync and lightspeed delay add up to a > non-conversational experience) >=20 > >[...] > >For REQMT-5, I interpret it to mean characteristics about the streams > the > >receiver can (or wants to) receive. Again, I think we should talk > about > >stream characteristics and not endpoint characteristics. This might > be > >realized by the receiver asking the sender to send streams with > certain > >characteristics. >=20 > Req 4 and 5 were meant as device characteristics. Stuff such as the > spatial arrangement of microphones, cameras, screens, constraints the > codecs may have, and so on. These are a superset of the stream > characteristics that are sent in that they can include permutations of > capabilities that are mutually exclusive, for example due to cycle > restrictions. An example would be: in the 2003 TeleSuite system, for > each > camera field, we were able to either code either VGA or a variety of > scaled down formats half-VGA, QVGA, and so on, that were be simulcast. >=20 > > > >You might be right about REQMT-14 being too strong, I wouldn't mind > >relaxing it. >=20 > The history of this requirement is that there was a requirement > "solution > is not to add delay". Allyn and I were dissecting what types of delay > could be meant, and figured out that it can't be media path delay (as > this > is independent from the CLUE concepts), so it must be some other delay > that matters. Call setup was the only one we came up with. I don't > mind > relaxing this, either, but do we really want to allow an additional > round > trip over offer-answer? If not, I don't see where significant > adidtional > delay can stem from... >=20 >=20 > Stephan >=20 > > > >Regards, > >Mark Duckworth > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf > Of > >> Roni Even > >> Sent: Thursday, May 05, 2011 4:32 AM > >> To: 'CLUE' > >> Subject: [clue] My comments on draft-romanow-clue-telepresence- > >> requirements-02 > >> > >> Hi, > >> I read the draft and the requirements and also looked at the email > >> thread. > >> > >> The one thing that bothered me was the terms used. > >> Requirement 1 and 2 talk about describing spatial arrangement. > >> > >> Requirement 3 talk about spatial matching of audio and video - I am > not > >> sure that we need to have this as a MUST requirement. I understand > lip > >> synch will be required and is not mentioned or it can be that I do > not > >> understand what spatial matching means here. > >> > >> Requirement 4 talk about characteristics and attribute. I saw > >> characteristics mentioned in section 4 "Characteristics include > number, > >> placement, capture/render angle, resolution of cameras and screens, > >> spatial location and mixing parameters of microphones." And noticed > >> that Allyn in the email thread had " Since characteristics of media > >> streams during a telepresence conference may change, such as > bandwidth, > >> resolution". I think that we need to specify what we mean by > endpoint > >> characteristics and stream characteristics and are these the terms > we > >> should use in all the requirements. > >> > >> Requirement 5 uses specified information about itself (see the > comment > >> on requirement 4). Is this the received endpoint receive > >> characteristics? > >> > >> Requirement 6 based on the above comment should probably discuss > >> dynamic changes in stream characteristics. > >> > >> Requirement 7 should talk about the streams characteristics and not > the > >> description of the streams. > >> > >> I think that if we go to a common language in all requirements it > will > >> be easier to see the redundancy between the requirements. > >> > >> > >> I was wondering about requirement 14 - I take it that it means that > it > >> must be possible to open all media channels after one offer answer > >> exchange. I am not sure if we should have such a strong statement > >> currently. I think it is an important objective but based on my > current > >> experience with dual stream support (H.239 like) and the current > media > >> capability negotiation I think it is very challenging when > considering > >> backward computability ("support for "legacy" systems). > >> > >> I am also missing a requirement for "legacy" system support like = the > >> solution MUST enable a system that does not support the mechanism = to > >> select the best set of streams to render (audio + video). > >> > >> > >> Thanks > >> Roni Even > >> > >> > -----Original Message----- > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> Of > >> > Allyn Romanow (allyn) > >> > Sent: Friday, April 22, 2011 10:48 AM > >> > To: CLUE > >> > Subject: [clue] FW: New Version Notification for draft-romanow- > clue- > >> > telepresence-requirements-02 > >> > > >> > Folks, > >> > I revised my requirement document based on the numerous helpful > >> > comments made during the WG meeting in Prague. An appendix > outlines > >> the > >> > main changes. > >> > > >> > I=B9m delighted that Stephan Wenger has significantly contributed = to > >> the > >> > draft and agreed to be a co-author - much appreciation, Stephan. > >> > > >> > Looking forward to discussion of the draft- > >> > > >> > Best regards, > >> > Allyn > >> > > >> > ------- > >> > > >> > A new version of I-D, draft-romanow-clue-telepresence- > requirements- > >> > 02.txt has been successfully submitted by Allyn Romanow and = posted > to > >> > the IETF repository. > >> > > >> > Filename: draft-romanow-clue-telepresence-requirements > >> > Revision: 02 > >> > Title: Requirements for Telepresence Multi-Streams > >> > Creation_date: 2011-04-22 > >> > WG ID: Independent Submission > >> > Number_of_pages: 10 > >> > > >> > Abstract: > >> > This memo discusses the requirements for a specification that > enables > >> > telepresence interoperability, by describing the relationship > between > >> > multiple RTP streams. In addition, the problem statement and > >> > definitions are also covered herein. > >> > > >> > > >> > > >> > 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 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Sat May 7 01:24:47 2011 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 6507BE0679 for ; Sat, 7 May 2011 01:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.281 X-Spam-Level: X-Spam-Status: No, score=-105.281 tagged_above=-999 required=5 tests=[AWL=1.318, 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 Z0OsqoGAhiQd for ; Sat, 7 May 2011 01:24:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD82E065A for ; Sat, 7 May 2011 01:24:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKT00L6YGP8HD@szxga04-in.huawei.com> for clue@ietf.org; Sat, 07 May 2011 16:24:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKT00E40GP8YH@szxga04-in.huawei.com> for clue@ietf.org; Sat, 07 May 2011 16:24:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-32-24.red.bezeqint.net [79.183.32.24]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKT003Z4GOXNC@szxml12-in.huawei.com>; Sat, 07 May 2011 16:24:44 +0800 (CST) Date: Sat, 07 May 2011 11:23:01 +0300 From: Roni Even In-reply-to: To: 'Stephan Wenger' , "'Duckworth, Mark'" , 'CLUE' Message-id: <054e01cc0c90$019c5bb0$04d51310$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwMPo/7+Y9jsN67Sjeuo/MxGH/JeAAUIxtg References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 - about REQ 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: Sat, 07 May 2011 08:24:47 -0000 Inline, > > > > >You might be right about REQMT-14 being too strong, I wouldn't mind > >relaxing it. > > The history of this requirement is that there was a requirement > "solution > is not to add delay". Allyn and I were dissecting what types of delay > could be meant, and figured out that it can't be media path delay (as > this > is independent from the CLUE concepts), so it must be some other delay > that matters. Call setup was the only one we came up with. I don't > mind > relaxing this, either, but do we really want to allow an additional > round > trip over offer-answer? If not, I don't see where significant > adidtional > delay can stem from... ' I agree that the issue was call setup delay, but this requirement in my view calls for one offer answer exchange and I think that we can relax it to a SHOULD since we are not sure if this is feasible or of we may agree to add some of the media channel in a second offer answer and I do not want the requirement to prevent it. I agree that it will be best if we can have one offer/answer exchange. Roni > From allyn@cisco.com Mon May 9 19:53:20 2011 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 15AEFE09C9 for ; Mon, 9 May 2011 19:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrSFoTN495UV for ; Mon, 9 May 2011 19:53:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5FEE0849 for ; Mon, 9 May 2011 19:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=8982; q=dns/txt; s=iport; t=1304995998; x=1306205598; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LUyhWfGNl0GXRPBxIpMtKW0B0kFXzMQkg412YPzoID0=; b=SZAnrXrIookr5FiPtPD6gqbTe5KILFB8jsiTQaklaj/zgsbD0V2Ukizc GQ0wJ8aR/sYH3QWUy9Z2VYEayTqcE0sZwVQd3mmwfrPvSXVNvflJdFdYf Vsa8fGJP0NGDnOX5wrp+Fvnf5w5FfUmbIlIyXTIQpTs5ljuiZgVu4VruZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAO6nyE2rRDoH/2dsb2JhbACXUo4xd4hxnjCeNoYMBIZAjVWKTQ X-IronPort-AV: E=Sophos;i="4.64,344,1301875200"; d="scan'208";a="444648959" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 02:53:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4A2rHd0013158; Tue, 10 May 2011 02:53:17 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 19:53:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 19:53:16 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC044C0B4E@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwMPoumFfvCX/CKQ0SrnGlyo1MyagCfmdsw References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> From: "Allyn Romanow (allyn)" To: "Stephan Wenger" , "Duckworth, Mark" , "CLUE" X-OriginalArrivalTime: 10 May 2011 02:53:17.0831 (UTC) FILETIME=[6A159970:01CC0EBD] Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 10 May 2011 02:53:20 -0000 Hi Stephan and Mark, I am trying to sort out whether we need both #4 and #7 or not.. i.e., = whether stream characteristics are adequate and reflect any thing of = interest in the endpoint characteristics, which, I believe, is Mark's = point. To me this sounds plausible, but I'm not entirely sure. Stephan, I have a question for you based on your comment below- Regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Stephan Wenger > Sent: Friday, May 06, 2011 3:40 PM > To: Duckworth, Mark; CLUE > Subject: Re: [clue] My comments on draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi Mark, all, > Please see inline. >=20 > On 5.6.2011 14:05 , "Duckworth, Mark" > wrote: >=20 > >Hi Roni, > > > >REQMT-3 is about making the audio sound like it is coming from the > same > >place as the image of the person who is speaking. This is relevant > for > >cases that use multi channel audio, for example common cases are > stereo > >and left/center/right channels. I think MUST is appropriate. > >Synchronization between audio and video was a requirement in an > earlier > >draft, but I think maybe the intent was for spatial matching rather > than > >lip sync. It probably wouldn't hurt to add another requirement about > lip > >sync. >=20 > I think that lip-sync is something that is completely up to the > implementation to enable. All the necessary protocol mechanisms are > already available in RTP. You may even want to be have an option to > disable lipsync from the user interface. There are many scenarios > where > lip-sync is helpful, but there are also others where it is not (where > you > want to render audio as quickly as you can, even at the cost of > imperfect > lipsync, for example on intercontinental teleconferences where the > additive delay of video/lip-sync and lightspeed delay add up to a > non-conversational experience) >=20 > >[...] > >For REQMT-5, I interpret it to mean characteristics about the streams > the > >receiver can (or wants to) receive. Again, I think we should talk > about > >stream characteristics and not endpoint characteristics. This might > be > >realized by the receiver asking the sender to send streams with > certain > >characteristics. >=20 > Req 4 and 5 were meant as device characteristics. Stuff such as the > spatial arrangement of microphones, cameras, screens, constraints the > codecs may have, and so on. These are a superset of the stream > characteristics that are sent in that they can include permutations of > capabilities that are mutually exclusive, for example due to cycle > restrictions. An example would be: in the 2003 TeleSuite system, for > each > camera field, we were able to either code either VGA or a variety of > scaled down formats half-VGA, QVGA, and so on, that were be simulcast. >=20 > > AR- So, do you think that stream characteristics, as expressed in #7 and = capabilities as expressed in #12 cover it, and we take out #4? > >You might be right about REQMT-14 being too strong, I wouldn't mind > >relaxing it. >=20 > The history of this requirement is that there was a requirement > "solution > is not to add delay". Allyn and I were dissecting what types of delay > could be meant, and figured out that it can't be media path delay (as > this > is independent from the CLUE concepts), so it must be some other delay > that matters. Call setup was the only one we came up with. I don't > mind > relaxing this, either, but do we really want to allow an additional > round > trip over offer-answer? If not, I don't see where significant > adidtional > delay can stem from... >=20 >=20 > Stephan >=20 > > > >Regards, > >Mark Duckworth > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf > Of > >> Roni Even > >> Sent: Thursday, May 05, 2011 4:32 AM > >> To: 'CLUE' > >> Subject: [clue] My comments on draft-romanow-clue-telepresence- > >> requirements-02 > >> > >> Hi, > >> I read the draft and the requirements and also looked at the email > >> thread. > >> > >> The one thing that bothered me was the terms used. > >> Requirement 1 and 2 talk about describing spatial arrangement. > >> > >> Requirement 3 talk about spatial matching of audio and video - I am > not > >> sure that we need to have this as a MUST requirement. I understand > lip > >> synch will be required and is not mentioned or it can be that I do > not > >> understand what spatial matching means here. > >> > >> Requirement 4 talk about characteristics and attribute. I saw > >> characteristics mentioned in section 4 "Characteristics include > number, > >> placement, capture/render angle, resolution of cameras and screens, > >> spatial location and mixing parameters of microphones." And noticed > >> that Allyn in the email thread had " Since characteristics of media > >> streams during a telepresence conference may change, such as > bandwidth, > >> resolution". I think that we need to specify what we mean by > endpoint > >> characteristics and stream characteristics and are these the terms > we > >> should use in all the requirements. > >> > >> Requirement 5 uses specified information about itself (see the > comment > >> on requirement 4). Is this the received endpoint receive > >> characteristics? > >> > >> Requirement 6 based on the above comment should probably discuss > >> dynamic changes in stream characteristics. > >> > >> Requirement 7 should talk about the streams characteristics and not > the > >> description of the streams. > >> > >> I think that if we go to a common language in all requirements it > will > >> be easier to see the redundancy between the requirements. > >> > >> > >> I was wondering about requirement 14 - I take it that it means that > it > >> must be possible to open all media channels after one offer answer > >> exchange. I am not sure if we should have such a strong statement > >> currently. I think it is an important objective but based on my > current > >> experience with dual stream support (H.239 like) and the current > media > >> capability negotiation I think it is very challenging when > considering > >> backward computability ("support for "legacy" systems). > >> > >> I am also missing a requirement for "legacy" system support like = the > >> solution MUST enable a system that does not support the mechanism = to > >> select the best set of streams to render (audio + video). > >> > >> > >> Thanks > >> Roni Even > >> > >> > -----Original Message----- > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> Of > >> > Allyn Romanow (allyn) > >> > Sent: Friday, April 22, 2011 10:48 AM > >> > To: CLUE > >> > Subject: [clue] FW: New Version Notification for draft-romanow- > clue- > >> > telepresence-requirements-02 > >> > > >> > Folks, > >> > I revised my requirement document based on the numerous helpful > >> > comments made during the WG meeting in Prague. An appendix > outlines > >> the > >> > main changes. > >> > > >> > I=B9m delighted that Stephan Wenger has significantly contributed = to > >> the > >> > draft and agreed to be a co-author - much appreciation, Stephan. > >> > > >> > Looking forward to discussion of the draft- > >> > > >> > Best regards, > >> > Allyn > >> > > >> > ------- > >> > > >> > A new version of I-D, draft-romanow-clue-telepresence- > requirements- > >> > 02.txt has been successfully submitted by Allyn Romanow and = posted > to > >> > the IETF repository. > >> > > >> > Filename: draft-romanow-clue-telepresence-requirements > >> > Revision: 02 > >> > Title: Requirements for Telepresence Multi-Streams > >> > Creation_date: 2011-04-22 > >> > WG ID: Independent Submission > >> > Number_of_pages: 10 > >> > > >> > Abstract: > >> > This memo discusses the requirements for a specification that > enables > >> > telepresence interoperability, by describing the relationship > between > >> > multiple RTP streams. In addition, the problem statement and > >> > definitions are also covered herein. > >> > > >> > > >> > > >> > 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 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Tue May 10 14:28:58 2011 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 ED102E0819 for ; Tue, 10 May 2011 14:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LJ02jpos4X9 for ; Tue, 10 May 2011 14:28:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9812DE06DB for ; Tue, 10 May 2011 14:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11738; q=dns/txt; s=iport; t=1305062937; x=1306272537; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=N4TvyExoDm6lUz94LrQXNvGoCHm2n2sBB2wu21OqO4g=; b=YM+ZVPiiV0r3X4pz3Kk7BI4F+a/faeWeALn+xlho4hYDeuJjVLIJupfU /y43c4j9dxj2Px9oSuAhxMBj+10p/mJYFsWwjvWjksUkL4cHZ0If8qWuW P3VZLdRBmfXG0cf3HYEGoZvWrjhT39c+mYV8VZGIgAH3jA6ewcGEdmYSL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAEKtyU2rRDoI/2dsb2JhbACXXI4xd6kVni6GDwSGQo1cilE X-IronPort-AV: E=Sophos;i="4.64,347,1301875200"; d="scan'208";a="445271418" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 21:28:57 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4ALSvmh011140; Tue, 10 May 2011 21:28:57 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 14:28:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 14:28:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583790@xmb-sjc-221.amer.cisco.com> In-Reply-To: <054d01cc0c8f$03147230$093d5690$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwMPo/7+Y9jsN67Sjeuo/MxGH/JeAAT0AkAAIiOxcA= References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> <054d01cc0c8f$03147230$093d5690$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Stephan Wenger" , "Duckworth, Mark" , "CLUE" X-OriginalArrivalTime: 10 May 2011 21:28:57.0155 (UTC) FILETIME=[4507D930:01CC0F59] Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 10 May 2011 21:28:59 -0000 Hi- The discussion has been quite good - arguments on both sides sound = convincing. :) Here's my take on several point, we can discuss during the virtual = meeting this week- Reqmt 3 - spatial matching means as Mark described an association of = audio with video, without being lip sync. Will try to make the wording = more clear. There is disagreement about whether or not we need lip sync as a = requirement. I side with Stephan at the moment, feeling it shouldn't be = a requirement.=20 Reqmt 4 and 7 - As you all point out, 4 is about endpoint = characteristics and 7 is about the characteristics of streams.. so they = are different. The question is whether we feel the need to describe = endpoints - which may contain multiple devices - as well as describe = streams. There have been arguments on both sides. I tend to think we do = need both, but could be proved wrong. Perhaps this is something to = discuss at the meeting. Roni has suggested rewording 4, 5, and 7 to use the word = "characteristic" for clarity. I don't see any harm in this. There has been difference of opinion on the use of "SHOULD" and "MUST" = in the requirements. Whether there should be shoulds at all, whether = they should vary, or all be the same.=20 I'm of 2 minds - with Peter in thinking, what's the point of a = requirement that is not a MUST, while on the other hand wanting wiggle = room in case something turns out to be not a good idea. So, what are the = guidelines here? Look at each requirement individually and divine which = makes more sense?? There seems general agreement to change Reqmt 14 to a SHOULD. All the points that have been raised will be brought up during the = virtual meeting. Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni Even > Sent: Saturday, May 07, 2011 1:16 AM > To: 'Stephan Wenger'; 'Duckworth, Mark'; 'CLUE' > Subject: Re: [clue] My comments on draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi, > My comments were trying to highlight the point that we need to specify > what > we mean by characteristics in the requirements probably in section 1 = or > 4 of > the draft. >=20 > Like I said I noticed that the draft sometime means streams > characteristics > and sometime endpoint characteristics. On endpoint characteristic, I = am > not > sure if it talks about the systems itself (number of cameras, screens, > ..) > or also about the whole room when discussing spatial relation between > the > audio and the video. >=20 > Thanks > Roni Even >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Stephan Wenger > > Sent: Saturday, May 07, 2011 1:40 AM > > To: Duckworth, Mark; CLUE > > Subject: Re: [clue] My comments on draft-romanow-clue-telepresence- > > requirements-02 > > > > Hi Mark, all, > > Please see inline. > > > > On 5.6.2011 14:05 , "Duckworth, Mark" > > wrote: > > > > >Hi Roni, > > > > > >REQMT-3 is about making the audio sound like it is coming from the > > same > > >place as the image of the person who is speaking. This is relevant > > for > > >cases that use multi channel audio, for example common cases are > > stereo > > >and left/center/right channels. I think MUST is appropriate. > > >Synchronization between audio and video was a requirement in an > > earlier > > >draft, but I think maybe the intent was for spatial matching rather > > than > > >lip sync. It probably wouldn't hurt to add another requirement > about > > lip > > >sync. > > > > I think that lip-sync is something that is completely up to the > > implementation to enable. All the necessary protocol mechanisms are > > already available in RTP. You may even want to be have an option to > > disable lipsync from the user interface. There are many scenarios > > where > > lip-sync is helpful, but there are also others where it is not = (where > > you > > want to render audio as quickly as you can, even at the cost of > > imperfect > > lipsync, for example on intercontinental teleconferences where the > > additive delay of video/lip-sync and lightspeed delay add up to a > > non-conversational experience) > > > > >[...] > > >For REQMT-5, I interpret it to mean characteristics about the > streams > > the > > >receiver can (or wants to) receive. Again, I think we should talk > > about > > >stream characteristics and not endpoint characteristics. This = might > > be > > >realized by the receiver asking the sender to send streams with > > certain > > >characteristics. > > > > Req 4 and 5 were meant as device characteristics. Stuff such as the > > spatial arrangement of microphones, cameras, screens, constraints = the > > codecs may have, and so on. These are a superset of the stream > > characteristics that are sent in that they can include permutations > of > > capabilities that are mutually exclusive, for example due to cycle > > restrictions. An example would be: in the 2003 TeleSuite system, = for > > each > > camera field, we were able to either code either VGA or a variety of > > scaled down formats half-VGA, QVGA, and so on, that were be > simulcast. > > > > > > > >You might be right about REQMT-14 being too strong, I wouldn't mind > > >relaxing it. > > > > The history of this requirement is that there was a requirement > > "solution > > is not to add delay". Allyn and I were dissecting what types of > delay > > could be meant, and figured out that it can't be media path delay = (as > > this > > is independent from the CLUE concepts), so it must be some other > delay > > that matters. Call setup was the only one we came up with. I don't > > mind > > relaxing this, either, but do we really want to allow an additional > > round > > trip over offer-answer? If not, I don't see where significant > > adidtional > > delay can stem from... > > > > > > Stephan > > > > > > > >Regards, > > >Mark Duckworth > > > > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of > > >> Roni Even > > >> Sent: Thursday, May 05, 2011 4:32 AM > > >> To: 'CLUE' > > >> Subject: [clue] My comments on draft-romanow-clue-telepresence- > > >> requirements-02 > > >> > > >> Hi, > > >> I read the draft and the requirements and also looked at the = email > > >> thread. > > >> > > >> The one thing that bothered me was the terms used. > > >> Requirement 1 and 2 talk about describing spatial arrangement. > > >> > > >> Requirement 3 talk about spatial matching of audio and video - I > am > > not > > >> sure that we need to have this as a MUST requirement. I = understand > > lip > > >> synch will be required and is not mentioned or it can be that I = do > > not > > >> understand what spatial matching means here. > > >> > > >> Requirement 4 talk about characteristics and attribute. I saw > > >> characteristics mentioned in section 4 "Characteristics include > > number, > > >> placement, capture/render angle, resolution of cameras and > screens, > > >> spatial location and mixing parameters of microphones." And > noticed > > >> that Allyn in the email thread had " Since characteristics of > media > > >> streams during a telepresence conference may change, such as > > bandwidth, > > >> resolution". I think that we need to specify what we mean by > > endpoint > > >> characteristics and stream characteristics and are these the = terms > > we > > >> should use in all the requirements. > > >> > > >> Requirement 5 uses specified information about itself (see the > > comment > > >> on requirement 4). Is this the received endpoint receive > > >> characteristics? > > >> > > >> Requirement 6 based on the above comment should probably discuss > > >> dynamic changes in stream characteristics. > > >> > > >> Requirement 7 should talk about the streams characteristics and > not > > the > > >> description of the streams. > > >> > > >> I think that if we go to a common language in all requirements it > > will > > >> be easier to see the redundancy between the requirements. > > >> > > >> > > >> I was wondering about requirement 14 - I take it that it means > that > > it > > >> must be possible to open all media channels after one offer = answer > > >> exchange. I am not sure if we should have such a strong statement > > >> currently. I think it is an important objective but based on my > > current > > >> experience with dual stream support (H.239 like) and the current > > media > > >> capability negotiation I think it is very challenging when > > considering > > >> backward computability ("support for "legacy" systems). > > >> > > >> I am also missing a requirement for "legacy" system support like > the > > >> solution MUST enable a system that does not support the mechanism > to > > >> select the best set of streams to render (audio + video). > > >> > > >> > > >> Thanks > > >> Roni Even > > >> > > >> > -----Original Message----- > > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >> Of > > >> > Allyn Romanow (allyn) > > >> > Sent: Friday, April 22, 2011 10:48 AM > > >> > To: CLUE > > >> > Subject: [clue] FW: New Version Notification for draft-romanow- > > clue- > > >> > telepresence-requirements-02 > > >> > > > >> > Folks, > > >> > I revised my requirement document based on the numerous helpful > > >> > comments made during the WG meeting in Prague. An appendix > > outlines > > >> the > > >> > main changes. > > >> > > > >> > I=B9m delighted that Stephan Wenger has significantly = contributed > to > > >> the > > >> > draft and agreed to be a co-author - much appreciation, = Stephan. > > >> > > > >> > Looking forward to discussion of the draft- > > >> > > > >> > Best regards, > > >> > Allyn > > >> > > > >> > ------- > > >> > > > >> > A new version of I-D, draft-romanow-clue-telepresence- > > requirements- > > >> > 02.txt has been successfully submitted by Allyn Romanow and > posted > > to > > >> > the IETF repository. > > >> > > > >> > Filename: draft-romanow-clue-telepresence-requirements > > >> > Revision: 02 > > >> > Title: Requirements for Telepresence Multi-Streams > > >> > Creation_date: 2011-04-22 > > >> > WG ID: Independent Submission > > >> > Number_of_pages: 10 > > >> > > > >> > Abstract: > > >> > This memo discusses the requirements for a specification that > > enables > > >> > telepresence interoperability, by describing the relationship > > between > > >> > multiple RTP streams. In addition, the problem statement and > > >> > definitions are also covered herein. > > >> > > > >> > > > >> > > > >> > 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 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From magnus.westerlund@ericsson.com Wed May 11 06:42:09 2011 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 95988E06AF for ; Wed, 11 May 2011 06:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 rOqix6lTyTky for ; Wed, 11 May 2011 06:42:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C6C77E06C8 for ; Wed, 11 May 2011 06:42:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-28-4dca922cb755 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.09.11171.C229ACD4; Wed, 11 May 2011 15:42:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 11 May 2011 15:42:04 +0200 Message-ID: <4DCA922C.4000901@ericsson.com> Date: Wed, 11 May 2011 15:42:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: [clue] draft-romanow-clue-telepresence-requirements-02: RTP Media plane requirements 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, 11 May 2011 13:42:09 -0000 Hi, I have reviewed the new version of the requirements and I do wonder if this document needs to have some requirements more directly related to the media plane, i.e. RTP transport of media. To achieve interoperability it is quite clear from my perspective that RTP related questions like: - How one performs multiplexing over RTP - If and how Simulcast is to be supported - If relayed centralized models are to be supported there will be questions around stream control. Sure, REQMT-8: The solution MUST include a mechanism by which the receiver (endpoint or MCU) can specify to the sender (endpoint or MCU) what streams it wants to receive. can be interpreted to be applicable to parts of the last question. But in general we have so far not discussed much on what the issues are on the actual RTP media plane. Are such requirements something that we would like to develop? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From john.elwell@siemens-enterprise.com Wed May 11 07:01:59 2011 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 77698E0704 for ; Wed, 11 May 2011 07:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFoC2Il+OZdw for ; Wed, 11 May 2011 07:01:59 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 96684E06F6 for ; Wed, 11 May 2011 07:01:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1305122517!4695884!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 25074 invoked from network); 11 May 2011 14:01:57 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-216.messagelabs.com with SMTP; 11 May 2011 14:01:57 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6255A1EB83ED; Wed, 11 May 2011 16:01:57 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 11 May 2011 16:01:57 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , Roni Even , Stephan Wenger , "Duckworth, Mark" , CLUE Date: Wed, 11 May 2011 16:01:56 +0200 Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwMPo/7+Y9jsN67Sjeuo/MxGH/JeAAT0AkAAIiOxcAATNRVkA== Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com> <054d01cc0c8f$03147230$093d5690$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583790@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583790@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 11 May 2011 14:01:59 -0000 > There has been difference of opinion on the use of "SHOULD"=20 > and "MUST" in the requirements. Whether there should be=20 > shoulds at all, whether they should vary, or all be the same.=20 > I'm of 2 minds - with Peter in thinking, what's the point of=20 > a requirement that is not a MUST, while on the other hand=20 > wanting wiggle room in case something turns out to be not a=20 > good idea. So, what are the guidelines here? Look at each=20 > requirement individually and divine which makes more sense?? >=20 > There seems general agreement to change Reqmt 14 to a SHOULD. [JRE] During recent work on RFC 5947 https://datatracker.ietf.org/doc/rfc5947/ we decided to split things into requirements, using MUST, and desirables, u= sing SHOULD. The latter was use for things that we couldn't really quantify= . Since then I have heard opinions voiced that RFC 2119 language in this sort= of document is inappropriate, in which case one could use "must" and "shou= ld" instead. John From stephane.cazeaux@orange-ftgroup.com Wed May 11 07:08:47 2011 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 B12AEE073A for ; Wed, 11 May 2011 07:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 QjZLjGrwpELB for ; Wed, 11 May 2011 07:08:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 04B94E0706 for ; Wed, 11 May 2011 07:08:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 857E9858011 for ; Wed, 11 May 2011 16:15:33 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7FAED85800C for ; Wed, 11 May 2011 16:15:33 +0200 (CEST) Received: from ftrdhub1.rd.francetelecom.fr ([10.193.109.193]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 16:08:44 +0200 Received: from FTRDCH01.rd.francetelecom.fr (10.194.32.11) by ftrdhub1.rd.francetelecom.fr (10.193.109.193) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 May 2011 16:08:43 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Wed, 11 May 2011 16:08:43 +0200 From: To: Thread-Topic: Comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIg== Date: Wed, 11 May 2011 14:08:42 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2011 14:08:44.0620 (UTC) FILETIME=[F05898C0:01CC0FE4] Subject: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 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, 11 May 2011 14:08:47 -0000 Hi, Below some comments after review of this new draft, and of the earlier disc= ussions. ++ The definition of the middlebox is confusing. In certain cases, a middle bo= x could be initiator/terminator (of media and signaling), for instance when= a multipoint telepresence session is initiated by a MCU, and the MCU sends= media to the endpoints (kind of "waiting room") until all participants hav= e joined. We could think that in such cases, the MCU acts an endpoint, but = this not very satisfying since endpoint as defined in the document seems to= be a physical entity rather than a function or a role.=20 The document shall be more explicit on the list of stream/endpoint characte= ristics that the solution shall be able to signal. =A0This would help to fu= rther work on all requirements dealing with these characteristics, and in p= articularly for the discussion on requirements 4 and 7. =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=20 Is there a rationale of having removed a part of the REQMT-11 (previously t= he REQMT-09 in version 01)? Talking here of the requirement that allowed a = remote to make the placement for the local. The lip sync should be added as a requirement to the solution. Actually, I = don't see why it should not be part of the solution. ++ Some requirements that could be added We could add a requirement for the solution to support a means of describin= g the role of streams (e.g. whether a media stream corresponds to a speaker= image or to presentation slides). The REQMT-9 deals with interoperability of endpoints having different capab= ilities (e.g. resolution, CPU, ..), but there is no requirement for a means= of supporting this interoperability. This is especially true for multipoin= t sessions with endpoints having different capabilities (e.g. not the same = resolution capability). We could add a requirement for the solution to supp= ort a means of describing multiple simultaneous identical streams with diff= erent resolutions (e.g. high and low resolution). Note that without such re= quirement, the solution would implicitly to have a media transcoding on the= MCU to adapt a stream to the capability of each endpoint. As already mentioned by Roni, a requirement on interoperability with legacy= endpoints should be added.=20 We could add a requirement to support a mechanism allowing correlation betw= een several endpoints, to allow spatial arrangement (as required in REQMT-1= to 3) among several endpoints. Note that it does not intend to replace the= solution of multi-stream endpoints, but to add a solution to make multi-st= ream with several endpoints as an alternative. ++ About wording . We can see "endpoints" and "telepresence endpoints" in the document (especi= ally between REQMT-9 and REQMT-10). We should always use the same term, els= e we could think that "endpoint" could designate "legacy endpoint" (in cont= rast to the explicit term "telepresence endpoint"). IMHO I prefer "telepres= ence endpoint" wording, more explicit. The document deals sometime with "audio" and "video", and sometime with the= generic word "media". Unless explicitly needed, we should always use the g= eneric term. Regards, St=E9phane Cazeaux Orange Labs=20 From magnus.westerlund@ericsson.com Wed May 11 07:22:07 2011 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 11679E073A for ; Wed, 11 May 2011 07:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.369 X-Spam-Level: X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 KxpY4nc-vseq for ; Wed, 11 May 2011 07:22:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F1636E0726 for ; Wed, 11 May 2011 07:22:05 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-fe-4dca9b8c15bc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C6.78.28525.C8B9ACD4; Wed, 11 May 2011 16:22:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 11 May 2011 16:22:04 +0200 Message-ID: <4DCA9B8C.9050300@ericsson.com> Date: Wed, 11 May 2011 16:22:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: [clue] draft-romanow-clue-telepresence-requirements-02: Media stream capabilities vs Endpoint/MCU information exchange 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, 11 May 2011 14:22:07 -0000 Hi, I know that you already discussed requirement 4 and 7. The interpretation some colleagues and I have is that there is some important difference between requirement 4 and 7. First of all we do see that REQMT-4 and REQMT-5 are linked and appears to relate to Endpoint and MCU information exchange. REQMT-7 and REQMT-12 are also linked and relates to capabilities around media streams. Thus REQMT-4 and REQMT-7 appears to covered different things and are not truly redundant. However, note that I say appear. Because REQMT-4 is incredibly vague in its formulation. So vague that I am uncertain what it really means. I think it should be substantially clarified what type of attributes and characteristic is considered. Otherwise one can't determine if any proposed solution is reasonable for the function or not. Are this static information, or information that are dynamic. How big is it, and what impact does it have on the system? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From erlendur.karlsson@ericsson.com Wed May 11 09:36:36 2011 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 66FE4E072B for ; Wed, 11 May 2011 09:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 PFpBg9XwuKCH for ; Wed, 11 May 2011 09:36:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40DE0679 for ; Wed, 11 May 2011 09:36:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-83-4dcabb124de3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FE.22.11171.21BBACD4; Wed, 11 May 2011 18:36:34 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.19]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 11 May 2011 18:36:34 +0200 From: Erlendur Karlsson To: "Allyn Romanow (allyn)" Date: Wed, 11 May 2011 18:36:32 +0200 Thread-Topic: draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1,2 and 3 Thread-Index: AcwP+ZZPHbJ9ZsRxTtOfaSizjWVsCA== Message-ID: <41F80411E3CC644A844E6BED6E472FD91AEA73C97B@ESESSCMS0363.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 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, 11 May 2011 16:36:36 -0000 Hi, I and some of my colleages have looked over the Spatial Capture Description= Requirements (1,2 and 3) and we have some comments and suggestions on thos= e. These requirements mandate means of describing spatial arrangements of vide= o images and audio signals, but there is no mention of what particular func= tionality they should enable or support. Due to this any spatial arrangemen= t description will automatically fulfill the requirements, irrespective of = what functionality it will support. To make these requirements meaningful w= e feel that they need to be complemented with some description of the funct= ionality they are intended to support.=20 One issue we have regards spatial audio capture and rendering. We feel that= it is important to support the capture of several spatial audio sources in= the same space (media stream and position in space) and that there is supp= ort for sending those spatial positions to the rendering instances. In the = case where these spatial audio sources are associated with a video capture,= it is also important to support the positioning of the audio sources in th= e x-y plain of the associated video window as this will make it possible to= properly align the the rendered audio scene with the rendered video scene. Another issue regards video capture of the same object from multiple captur= e angles and rendering of such video images on multiview screens. It is imp= ortant for an endpoint with multiview screens to be able to obtain or evalu= ate the capture angles of the different video captures of the same object, = so that it can display the different video images at the appropriate viewin= g angles. =20 Below we have some suggestions on how requirements 1, 2 amd 3 could be comp= lemented with relevant functionality support descriptions. REQMT-1: The solution MUST support a means of describing the spatial arrangement of source video images sent in video streams in such a way that: - a client with a rendering layout that matches the particul= ar=20 capture layout is able to render the video images in a spa= tially correct manner. - it is possible to make a spatially correct composite video= image=20 of several of the video images. - a client with multiview screens is able to obtain or evalu= ate the capture=20 angles of video images that capture the same visual object= from=20 different angles. REQMT-2: The solution MUST support a means of describing the spatial arrangement of source audio sounds sent in audio streams in such a way that:=20 - a client with an audio rendering layout that matches the=20 particular audio capture layout is able to render the audi= o=20 in a spatially correct manner. - it supports the spatial capture of several audio sources i= n the same space=20 with a spatial position for each source. REQMT-3: The solution MUST support a mechanism to allow spatial matching of audio and video streams from the same endpoints such that: - rendering clients are able to correctly position audio sou= rces=20 associated with a video image in the image plane of the re= ndered=20 video window. - spatial audio sources associated with a video image can be= positioned=20 in the x-y plane of the associated video window. Kind regards, Erlendur Karlsson From stewe@stewe.org Wed May 11 09:50:19 2011 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 A33EBE0858 for ; Wed, 11 May 2011 09:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897] 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 Ix-AGQ-vATTw for ; Wed, 11 May 2011 09:50:19 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id CF365E0844 for ; Wed, 11 May 2011 09:50:16 -0700 (PDT) Received: from [192.168.13.185] (unverified [94.90.92.242]) by stewe.org (SurgeMail 3.9e) with ESMTP id 237-1743317 for multiple; Wed, 11 May 2011 18:50:15 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 11 May 2011 18:50:06 -0700 From: Stephan Wenger To: "Elwell, John" , "Allyn Romanow (allyn)" , Roni Even , "Duckworth, Mark" , CLUE Message-ID: Thread-Topic: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 94.90.92.242 X-Authenticated-User: stewe@stewe.org Subject: Re: [clue] My comments on draft-romanow-clue-telepresence-requirements-02 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, 11 May 2011 16:50:19 -0000 On 5.11.2011 07:01 , "Elwell, John" wrote: >> There has been difference of opinion on the use of "SHOULD" >> and "MUST" in the requirements. Whether there should be >> shoulds at all, whether they should vary, or all be the same. >> I'm of 2 minds - with Peter in thinking, what's the point of >> a requirement that is not a MUST, while on the other hand >> wanting wiggle room in case something turns out to be not a >> good idea. So, what are the guidelines here? Look at each >> requirement individually and divine which makes more sense?? >> >> There seems general agreement to change Reqmt 14 to a SHOULD. >[JRE] During recent work on RFC 5947 >https://datatracker.ietf.org/doc/rfc5947/ >we decided to split things into requirements, using MUST, and desirables, >using SHOULD. The latter was use for things that we couldn't really >quantify. >Since then I have heard opinions voiced that RFC 2119 language in this >sort of document is inappropriate, in which case one could use "must" and >"should" instead. Please note that the capitalization of keywords is neither required by 2119, nor does 2119 suggest that non-capitalized "must" or "should" ought to be interpreted any different than capitalized MUST or SHOULD. (I have learned that monitoring whitebeard-traffic on ietf@ietf.) Stephan > >John From erlendur.karlsson@ericsson.com Wed May 11 10:03:43 2011 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 B3609E0827 for ; Wed, 11 May 2011 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 n226vnUcKsBW for ; Wed, 11 May 2011 10:03:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EE077E0819 for ; Wed, 11 May 2011 10:03:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-fe-4dcac16dae0b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FE.54.11171.D61CACD4; Wed, 11 May 2011 19:03:42 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.19]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 11 May 2011 19:03:41 +0200 From: Erlendur Karlsson To: "Allyn Romanow (allyn)" Date: Wed, 11 May 2011 19:03:40 +0200 Thread-Topic: draft-romanow-clue-telepresence-requirements-02: Central Audio Rendering Thread-Index: AcwP/WCdTF0sYnYaRUie2sh8YZ4AOw== Message-ID: <41F80411E3CC644A844E6BED6E472FD91AEA73C98A@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_41F80411E3CC644A844E6BED6E472FD91AEA73C98AESESSCMS0363e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: [clue] draft-romanow-clue-telepresence-requirements-02: Central Audio Rendering 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, 11 May 2011 17:03:43 -0000 --_000_41F80411E3CC644A844E6BED6E472FD91AEA73C98AESESSCMS0363e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Requirement 11 describes some of the aspects required for local media rende= ring. I and some of my colleagues at Ericsson feel that it is important to also s= upport central audio rendering for simple endpoints with limited bandwidths= and processing power. This central audio mixing should be limited to stand= ard loudspeaker configurations such as mono, stereo, and binaural, but coul= d also be extended to some other standard configurations such as LCR and 5.= 0 surround configurations. We would, therefore, like to add a requirement for central audio rendering.= Something in line with: REQMT-15: The solution MUST support a model and information exchange between an endpoint and the MCU that will enable the endpoint= to * request a central rendering of its audio signals for a s= et of standard loudspeaker configurations * obtain the rendered audio signals from the MCU Kind regards, Erlendur Karlsson --_000_41F80411E3CC644A844E6BED6E472FD91AEA73C98AESESSCMS0363e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Requirement 11 describes some of the aspects required for local media = rendering.
 
I and some of my colleagues at Ericsson feel that it is important to a= lso support central audio rendering for simple endpoints with limited bandw= idths and processing power. This central audio mixing should be limited to = standard loudspeaker configurations such as mono, stereo, and binaural, but could also be extended to some othe= r standard configurations such as LCR and 5.0 surround configurations. = ; 
 
We would, therefore, like to add a requirement for central audio rende= ring. Something in line with:
 
   REQMT-15:  The= solution MUST support a model and information exchange
            &nb= sp; between an endpoint and the MCU that will enable the endpoint to
 
     &n= bsp;        *    request = a central rendering of its audio signals for a set
            &nb= sp;      of standard loudspeaker configurations
     &n= bsp;        *    obtain t= he rendered audio signals from the MCU
 <= /div>
 
Kind regards,
 
Erlendur Karlsson
 
 
 
 
 
 --_000_41F80411E3CC644A844E6BED6E472FD91AEA73C98AESESSCMS0363e_-- From mary.ietf.barnes@gmail.com Wed May 11 10:27:03 2011 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 9C88DE0844 for ; Wed, 11 May 2011 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIeJkyP6LvEq for ; Wed, 11 May 2011 10:27:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61BEFE073C for ; Wed, 11 May 2011 10:27:02 -0700 (PDT) Received: by vxg33 with SMTP id 33so625447vxg.31 for ; Wed, 11 May 2011 10:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=y8W+GzXNH9qnC9Y/uAOe4/5UI/p/GQrQ2pklhY08tGQ=; b=HKVt+CrPdoNUBGJIX7tL3tnsviMV4jgpNQ8GSoL0aizABU8sojD4x2zlMOavA3qa6T ntqtF/e3nQpjJCwHSvvIrSgBMKyGPwK9++UZgqs34/XarXVxqbWadwEMsE+H5tQPB1FQ aLdFtigK4p/5UAxLTdrdTMh1am+ksI/PUXf58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Ou1F/LUTipjLrP0XY+9I2nMH+hlIlvVnOJI65aQp/cjMUkEQ3eohOWdzQhlBtH0K9k 5QK67tuj4/+1RiuSb97XhVTx5BJctEBYsR4zjx+OMp3uc870FIqJfJ3QRbeEquapZCP5 YIhtPWLmgF+DHTF9dSA22ar9heDP60d9gpclA= MIME-Version: 1.0 Received: by 10.52.0.236 with SMTP id 12mr1679461vdh.223.1305134821844; Wed, 11 May 2011 10:27:01 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Wed, 11 May 2011 10:27:01 -0700 (PDT) Date: Wed, 11 May 2011 12:27:01 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3043470270a5fc04a3036178 Subject: [clue] Reminder: Meeting invitation: CLUE Interim - May 12th 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, 11 May 2011 17:27:03 -0000 --20cf3043470270a5fc04a3036178 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, A reminder of the meeting tomorrow. As far as agenda, the only item on the agenda is discussion of the Requirements document. We've had excellent discussion on the mailing list and can hopefully discuss and close off many of the issues tomorrow. All the information related to the meeting is/will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary. On Wed, Apr 20, 2011 at 1:34 PM, Mary Barnes wrote: > Hi all, > > Below, please find the details for joining the CLUE WG virtual interim > meeting. We will have a detailed agenda out about a week before the > meeting. Per my other email, the focus will be completing the use cases and > reviewing the updated requriements document, which should be submitted soon. > > > Regards, > Mary. > CLUE WG co-chair > > ---------- Forwarded message ---------- > From: IETF Secretariat > Date: Wed, Apr 20, 2011 at 1:06 PM > Subject: Meeting invitation: CLUE > To: mary.ietf.barnes@gmail.com > > > > Hello , > > IETF Secretariat invites you to attend this online meeting. > > Topic: CLUE > Date: Thursday, May 12, 2011 > Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 969 701 031 > Meeting Password: (This meeting does not require a password.) > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&RT=MiM0 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: (This meeting > does not require a password.) > 4. Click "Join". > > To view in other time zones or languages, please click the link: > > https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&ORT=MiM0 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: > https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=152624022&tollFree=0 > > Access code:969 701 031 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > > https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&ICS=MI&LD=1&RD=2&ST=1&SHA2=T5lcZ2jRKRus52o8tbim6clC9o6bq8UKSKVm-SyhJlY=&RT=MiM0 > > 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://workgreen.webex.com/workgreen/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14087926300x969701031# > > 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. > > --20cf3043470270a5fc04a3036178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

A reminder of the meeting tomorrow. =A0As far = as agenda, the only item on the agenda is discussion of the Requirements do= cument. We've had excellent discussion on the mailing list and can hope= fully discuss and close off many of the issues tomorrow. =A0All the informa= tion related to the meeting is/will be available on the CLUE WG wiki:=A0http://trac.tools.iet= f.org/wg/clue/trac/wiki

Regards,
Mary.=A0

On Wed, Apr 20, 2011 at 1:34 PM, Mary Barnes <<= a href=3D"mailto:mary.ietf.barnes@gmail.com">mary.ietf.barnes@gmail.com= > wrote:
Hi all,
=A0
Below, please find the details for joining the C= LUE WG virtual interim meeting.=A0 We will have a detailed agenda out about= a week before the meeting.=A0 Per my other email, the focus will be comple= ting the use cases and reviewing the updated requriements document, which s= hould be submitted soon.
=A0
Regards,
Mary.
CLUE WG co-chair
=A0
---------- Forwarded message ----------
From:= IETF Secretariat <<= a href=3D"mailto:messenger@webex.com" target=3D"_blank">messenger@webex.com= >
Date: Wed, Apr 20, 2011 at 1:06 PM
Subject: Meeting invitation: CLUE
To: mary.ietf.barnes@gmail.com



Hel= lo ,

IETF Secretariat invites you to attend this online meeting.

Topic: CLUE
Date: Thursday, May 12, 2011
Time: 8:00 am, Pacific= Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 969 701 031 <= br>Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the= online meeting (Now from mobile devices!)
----------------------------= ---------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D152624022&a= mp;UID=3D1209871362&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password is= required, enter the meeting password: (This meeting does not require a pas= sword.)
4. Click "Join".

To view in other time zones = or languages, please click the link:
https://workgreen.webex.c= om/workgreen/j.php?ED=3D152624022&UID=3D1209871362&ORT=3DMiM0 <= br>
-------------------------------------------------------
To join the audio conference only
-------------------------------------= ------------------
To receive a call back, provide your phone number wh= en you join the meeting, or call the number below and enter the access code= .
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers= : https://wo= rkgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D1526= 24022&tollFree=3D0

Access code:969 701 031

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

You can c= ontact me at:
amo= rris@amsl.com
1-510-492-4081

To add this meeting to your calendar program (for example Microsoft Out= look), click this link:
https://workgreen.webex.com/workgreen/j.php= ?ED=3D152624022&UID=3D1209871362&ICS=3DMI&LD=3D1&RD=3D2&= ;ST=3D1&SHA2=3DT5lcZ2jRKRus52o8tbim6clC9o6bq8UKSKVm-SyhJlY=3D&RT=3D= MiM0

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 comput= er by going to https://workgreen.webex.com/workgreen/systemdia= gnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.we= bex.com

CCP:+14087926300x969701031#

IMPORTANT NOTICE: This WebEx servic= e includes a feature that allows audio and any documents and other material= s exchanged or viewed during the session to be recorded. By joining this se= ssion, 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 suc= h recordings may be subject to discovery in the event of litigation.


--20cf3043470270a5fc04a3036178-- From eckelcu@cisco.com Wed May 11 12:52:22 2011 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 C3308E066E for ; Wed, 11 May 2011 12:52:22 -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 wJ4+n0609THI for ; Wed, 11 May 2011 12:52:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1E553E073A for ; Wed, 11 May 2011 12:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13364; q=dns/txt; s=iport; t=1305143541; x=1306353141; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bALNIKfdcr4ETq/BO0wZGB6qc6X3PYj/PAAS0FaH7Tg=; b=HYC++0OCuQ8/YeKzag3pQJPHmckWdpiXOtpdX/tC80btztoXUvcJywZa k+y0RwrpxteaJXIRhvmpW77mc+UhMBymnCsYIY0QdK1xHzhpqp8HhRzAY 7m47zEQv0QQg+tBzARWCr9qUVoW0KafBZVegIwZnYS4mTzRYrixIK1a3d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQBAJzoyk2rRDoJ/2dsb2JhbACXUY4yd4hwoQ6eLoYQBIZDjV2KUQ X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208";a="445971574" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 11 May 2011 19:52:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4BJqCvN017623; Wed, 11 May 2011 19:52:12 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 12:52:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 12:52:11 -0700 Message-ID: In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583790@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] My comments ondraft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwMPo/7+Y9jsN67Sjeuo/MxGH/JeAAT0AkAAIiOxcAAWQfRkA== References: <44C6B6B2D0CF424AA90B6055548D7A61ABEF5BC8@CRPMBOXPRD01.polycom.com><054d01cc0c8f$03147230$093d5690$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583790@xmb-sjc-221.amer.cisco.com> From: "Charles Eckel (eckelcu)" To: "Allyn Romanow (allyn)" , "Roni Even" , "Stephan Wenger" , "Duckworth, Mark" , "CLUE" X-OriginalArrivalTime: 11 May 2011 19:52:12.0829 (UTC) FILETIME=[EBCBBCD0:01CC1014] Subject: Re: [clue] My comments ondraft-romanow-clue-telepresence-requirements-02 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, 11 May 2011 19:52:22 -0000 Regarding the must/should question, I think that if it is not a must, it = does not belong in the requirements section and is more appropriately = addressed in the other sections of the document. If we are not sure whether something is a real requirement or not, we = can have more discussion on it until we determine which way to go. In my opinion, Reqmt 14 is a goal worth keeping in mind, but it is not a = requirement. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Allyn Romanow (allyn) > Sent: Tuesday, May 10, 2011 2:29 PM > To: Roni Even; Stephan Wenger; Duckworth, Mark; CLUE > Subject: Re: [clue] My comments = ondraft-romanow-clue-telepresence-requirements-02 >=20 > Hi- >=20 > The discussion has been quite good - arguments on both sides sound = convincing. :) >=20 > Here's my take on several point, we can discuss during the virtual = meeting this week- >=20 > Reqmt 3 - spatial matching means as Mark described an association of = audio with video, without being > lip sync. Will try to make the wording more clear. >=20 > There is disagreement about whether or not we need lip sync as a = requirement. I side with Stephan at > the moment, feeling it shouldn't be a requirement. >=20 > Reqmt 4 and 7 - As you all point out, 4 is about endpoint = characteristics and 7 is about the > characteristics of streams.. so they are different. The question is = whether we feel the need to > describe endpoints - which may contain multiple devices - as well as = describe streams. There have > been arguments on both sides. I tend to think we do need both, but = could be proved wrong. Perhaps this > is something to discuss at the meeting. >=20 > Roni has suggested rewording 4, 5, and 7 to use the word = "characteristic" for clarity. I don't see > any harm in this. >=20 > There has been difference of opinion on the use of "SHOULD" and "MUST" = in the requirements. Whether > there should be shoulds at all, whether they should vary, or all be = the same. > I'm of 2 minds - with Peter in thinking, what's the point of a = requirement that is not a MUST, while > on the other hand wanting wiggle room in case something turns out to = be not a good idea. So, what are > the guidelines here? Look at each requirement individually and divine = which makes more sense?? >=20 > There seems general agreement to change Reqmt 14 to a SHOULD. >=20 > All the points that have been raised will be brought up during the = virtual meeting. >=20 > Allyn >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > > Roni Even > > Sent: Saturday, May 07, 2011 1:16 AM > > To: 'Stephan Wenger'; 'Duckworth, Mark'; 'CLUE' > > Subject: Re: [clue] My comments on draft-romanow-clue-telepresence- > > requirements-02 > > > > Hi, > > My comments were trying to highlight the point that we need to = specify > > what > > we mean by characteristics in the requirements probably in section 1 = or > > 4 of > > the draft. > > > > Like I said I noticed that the draft sometime means streams > > characteristics > > and sometime endpoint characteristics. On endpoint characteristic, I = am > > not > > sure if it talks about the systems itself (number of cameras, = screens, > > ..) > > or also about the whole room when discussing spatial relation = between > > the > > audio and the video. > > > > Thanks > > Roni Even > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf > > Of > > > Stephan Wenger > > > Sent: Saturday, May 07, 2011 1:40 AM > > > To: Duckworth, Mark; CLUE > > > Subject: Re: [clue] My comments on = draft-romanow-clue-telepresence- > > > requirements-02 > > > > > > Hi Mark, all, > > > Please see inline. > > > > > > On 5.6.2011 14:05 , "Duckworth, Mark" > > > wrote: > > > > > > >Hi Roni, > > > > > > > >REQMT-3 is about making the audio sound like it is coming from = the > > > same > > > >place as the image of the person who is speaking. This is = relevant > > > for > > > >cases that use multi channel audio, for example common cases are > > > stereo > > > >and left/center/right channels. I think MUST is appropriate. > > > >Synchronization between audio and video was a requirement in an > > > earlier > > > >draft, but I think maybe the intent was for spatial matching = rather > > > than > > > >lip sync. It probably wouldn't hurt to add another requirement > > about > > > lip > > > >sync. > > > > > > I think that lip-sync is something that is completely up to the > > > implementation to enable. All the necessary protocol mechanisms = are > > > already available in RTP. You may even want to be have an option = to > > > disable lipsync from the user interface. There are many scenarios > > > where > > > lip-sync is helpful, but there are also others where it is not = (where > > > you > > > want to render audio as quickly as you can, even at the cost of > > > imperfect > > > lipsync, for example on intercontinental teleconferences where the > > > additive delay of video/lip-sync and lightspeed delay add up to a > > > non-conversational experience) > > > > > > >[...] > > > >For REQMT-5, I interpret it to mean characteristics about the > > streams > > > the > > > >receiver can (or wants to) receive. Again, I think we should = talk > > > about > > > >stream characteristics and not endpoint characteristics. This = might > > > be > > > >realized by the receiver asking the sender to send streams with > > > certain > > > >characteristics. > > > > > > Req 4 and 5 were meant as device characteristics. Stuff such as = the > > > spatial arrangement of microphones, cameras, screens, constraints = the > > > codecs may have, and so on. These are a superset of the stream > > > characteristics that are sent in that they can include = permutations > > of > > > capabilities that are mutually exclusive, for example due to cycle > > > restrictions. An example would be: in the 2003 TeleSuite system, = for > > > each > > > camera field, we were able to either code either VGA or a variety = of > > > scaled down formats half-VGA, QVGA, and so on, that were be > > simulcast. > > > > > > > > > > >You might be right about REQMT-14 being too strong, I wouldn't = mind > > > >relaxing it. > > > > > > The history of this requirement is that there was a requirement > > > "solution > > > is not to add delay". Allyn and I were dissecting what types of > > delay > > > could be meant, and figured out that it can't be media path delay = (as > > > this > > > is independent from the CLUE concepts), so it must be some other > > delay > > > that matters. Call setup was the only one we came up with. I = don't > > > mind > > > relaxing this, either, but do we really want to allow an = additional > > > round > > > trip over offer-answer? If not, I don't see where significant > > > adidtional > > > delay can stem from... > > > > > > > > > Stephan > > > > > > > > > > >Regards, > > > >Mark Duckworth > > > > > > > >> -----Original Message----- > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > > Of > > > >> Roni Even > > > >> Sent: Thursday, May 05, 2011 4:32 AM > > > >> To: 'CLUE' > > > >> Subject: [clue] My comments on draft-romanow-clue-telepresence- > > > >> requirements-02 > > > >> > > > >> Hi, > > > >> I read the draft and the requirements and also looked at the = email > > > >> thread. > > > >> > > > >> The one thing that bothered me was the terms used. > > > >> Requirement 1 and 2 talk about describing spatial arrangement. > > > >> > > > >> Requirement 3 talk about spatial matching of audio and video - = I > > am > > > not > > > >> sure that we need to have this as a MUST requirement. I = understand > > > lip > > > >> synch will be required and is not mentioned or it can be that I = do > > > not > > > >> understand what spatial matching means here. > > > >> > > > >> Requirement 4 talk about characteristics and attribute. I saw > > > >> characteristics mentioned in section 4 "Characteristics include > > > number, > > > >> placement, capture/render angle, resolution of cameras and > > screens, > > > >> spatial location and mixing parameters of microphones." And > > noticed > > > >> that Allyn in the email thread had " Since characteristics of > > media > > > >> streams during a telepresence conference may change, such as > > > bandwidth, > > > >> resolution". I think that we need to specify what we mean by > > > endpoint > > > >> characteristics and stream characteristics and are these the = terms > > > we > > > >> should use in all the requirements. > > > >> > > > >> Requirement 5 uses specified information about itself (see the > > > comment > > > >> on requirement 4). Is this the received endpoint receive > > > >> characteristics? > > > >> > > > >> Requirement 6 based on the above comment should probably = discuss > > > >> dynamic changes in stream characteristics. > > > >> > > > >> Requirement 7 should talk about the streams characteristics and > > not > > > the > > > >> description of the streams. > > > >> > > > >> I think that if we go to a common language in all requirements = it > > > will > > > >> be easier to see the redundancy between the requirements. > > > >> > > > >> > > > >> I was wondering about requirement 14 - I take it that it means > > that > > > it > > > >> must be possible to open all media channels after one offer = answer > > > >> exchange. I am not sure if we should have such a strong = statement > > > >> currently. I think it is an important objective but based on my > > > current > > > >> experience with dual stream support (H.239 like) and the = current > > > media > > > >> capability negotiation I think it is very challenging when > > > considering > > > >> backward computability ("support for "legacy" systems). > > > >> > > > >> I am also missing a requirement for "legacy" system support = like > > the > > > >> solution MUST enable a system that does not support the = mechanism > > to > > > >> select the best set of streams to render (audio + video). > > > >> > > > >> > > > >> Thanks > > > >> Roni Even > > > >> > > > >> > -----Original Message----- > > > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf > > > >> Of > > > >> > Allyn Romanow (allyn) > > > >> > Sent: Friday, April 22, 2011 10:48 AM > > > >> > To: CLUE > > > >> > Subject: [clue] FW: New Version Notification for = draft-romanow- > > > clue- > > > >> > telepresence-requirements-02 > > > >> > > > > >> > Folks, > > > >> > I revised my requirement document based on the numerous = helpful > > > >> > comments made during the WG meeting in Prague. An appendix > > > outlines > > > >> the > > > >> > main changes. > > > >> > > > > >> > I=B9m delighted that Stephan Wenger has significantly = contributed > > to > > > >> the > > > >> > draft and agreed to be a co-author - much appreciation, = Stephan. > > > >> > > > > >> > Looking forward to discussion of the draft- > > > >> > > > > >> > Best regards, > > > >> > Allyn > > > >> > > > > >> > ------- > > > >> > > > > >> > A new version of I-D, draft-romanow-clue-telepresence- > > > requirements- > > > >> > 02.txt has been successfully submitted by Allyn Romanow and > > posted > > > to > > > >> > the IETF repository. > > > >> > > > > >> > Filename: draft-romanow-clue-telepresence-requirements > > > >> > Revision: 02 > > > >> > Title: Requirements for Telepresence Multi-Streams > > > >> > Creation_date: 2011-04-22 > > > >> > WG ID: Independent Submission > > > >> > Number_of_pages: 10 > > > >> > > > > >> > Abstract: > > > >> > This memo discusses the requirements for a specification that > > > enables > > > >> > telepresence interoperability, by describing the relationship > > > between > > > >> > multiple RTP streams. In addition, the problem statement and > > > >> > definitions are also covered herein. > > > >> > > > > >> > > > > >> > > > > >> > 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 eckelcu@cisco.com Wed May 11 12:57:17 2011 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 A82CCE08AA for ; Wed, 11 May 2011 12:57:17 -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 5xn8rSffg7Tc for ; Wed, 11 May 2011 12:57:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2499FE07BA for ; Wed, 11 May 2011 12:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3096; q=dns/txt; s=iport; t=1305143837; x=1306353437; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GpMhMRdC1kT8x5nuqdLpioS1+8LebH9Tw+0LYa8uGR4=; b=IfEaLfHeYWtep762rlJ8rmmHPka3Bs1R0iEJe7zaGSYWurwvs31J/6Uw 30PTOwY6/ozmqdVNQqZR/8f0tSXy3W4Fu0aEhoN3ilbpB1s5Gk/Nyxt8k vgtkd6UV2Ff27TyoF0g6gfPFV+AaWJNtlQQHRD0jP0OWMoBNZsBL1dtTm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAGnpyk2rRDoG/2dsb2JhbACEEEeSeo1Ha3eqCI0CkSwCgSiDYIEGBIZDjV2KUQ X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208";a="445974366" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 11 May 2011 19:57:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4BJv295004513; Wed, 11 May 2011 19:57:02 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 12:57:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 11 May 2011 12:57:01 -0700 Message-ID: In-Reply-To: <4DCA922C.4000901@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] draft-romanow-clue-telepresence-requirements-02: RTP Media plane requirements Thread-Index: AcwP4T+qPgUejyQBRsSx0LT2GfxOsAAM9tCQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> <4DCA922C.4000901@ericsson.com> From: "Charles Eckel (eckelcu)" To: "Magnus Westerlund" , "Allyn Romanow (allyn)" X-OriginalArrivalTime: 11 May 2011 19:57:02.0497 (UTC) FILETIME=[98739110:01CC1015] Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: RTP Media plane requirements 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, 11 May 2011 19:57:17 -0000 SGkgTWFnbnVzLA0KDQpJIGFncmVlIHRoZSBSVFAgcmVsYXRlZCBxdWVzdGlvbnMgYXJlIHZlcnkg aW1wb3J0YW50IGZvciBDTFVFLiBIb3dldmVyLCBJIGFtIHRoaW5raW5nIGl0IGlzIGJldHRlciB0 byBhZGRyZXNzIHRoZW0gd2l0aGluIHRoZSBzY29wZSBvZiBvbmUgb2YgbW9yZSBvdGhlciB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50cyByZWxhdGVkIHRvIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBmb3Ig Q0xVRSAoZS5nLiBhcmNoaXRlY3R1cmUgb3IgcHJvdG9jb2wgZG9jdW1lbnQpLCBub3QgdGhlIHJl cXVpcmVtZW50cyBkb2N1bWVudC4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNs dWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hZ251cyBXZXN0ZXJsdW5kDQo+IFNl bnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDExIDY6NDIgQU0NCj4gVG86IEFsbHluIFJvbWFub3cg KGFsbHluKQ0KPiBDYzogQ0xVRQ0KPiBTdWJqZWN0OiBbY2x1ZV0gZHJhZnQtcm9tYW5vdy1jbHVl LXRlbGVwcmVzZW5jZS1yZXF1aXJlbWVudHMtMDI6IFJUUCBNZWRpYSBwbGFuZSByZXF1aXJlbWVu dHMNCj4gDQo+IEhpLA0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoZSBuZXcgdmVyc2lvbiBvZiB0 aGUgcmVxdWlyZW1lbnRzIGFuZCBJIGRvIHdvbmRlciBpZg0KPiB0aGlzIGRvY3VtZW50IG5lZWRz IHRvIGhhdmUgc29tZSByZXF1aXJlbWVudHMgbW9yZSBkaXJlY3RseSByZWxhdGVkIHRvDQo+IHRo ZSBtZWRpYSBwbGFuZSwgaS5lLiBSVFAgdHJhbnNwb3J0IG9mIG1lZGlhLg0KPiANCj4gVG8gYWNo aWV2ZSBpbnRlcm9wZXJhYmlsaXR5IGl0IGlzIHF1aXRlIGNsZWFyIGZyb20gbXkgcGVyc3BlY3Rp dmUgdGhhdA0KPiBSVFAgcmVsYXRlZCBxdWVzdGlvbnMgbGlrZToNCj4gDQo+IC0gSG93IG9uZSBw ZXJmb3JtcyBtdWx0aXBsZXhpbmcgb3ZlciBSVFANCj4gLSBJZiBhbmQgaG93IFNpbXVsY2FzdCBp cyB0byBiZSBzdXBwb3J0ZWQNCj4gLSBJZiByZWxheWVkIGNlbnRyYWxpemVkIG1vZGVscyBhcmUg dG8gYmUgc3VwcG9ydGVkIHRoZXJlIHdpbGwgYmUNCj4gcXVlc3Rpb25zIGFyb3VuZCBzdHJlYW0g Y29udHJvbC4NCj4gDQo+IFN1cmUsDQo+ICAgIFJFUU1ULTg6ICAgVGhlIHNvbHV0aW9uIE1VU1Qg aW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGljaCB0aGUNCj4gICAgICAgICAgICAgICByZWNlaXZl ciAoZW5kcG9pbnQgb3IgTUNVKSBjYW4gc3BlY2lmeSB0byB0aGUgc2VuZGVyDQo+ICAgICAgICAg ICAgICAgKGVuZHBvaW50IG9yIE1DVSkgd2hhdCBzdHJlYW1zIGl0IHdhbnRzIHRvIHJlY2VpdmUu DQo+IGNhbiBiZSBpbnRlcnByZXRlZCB0byBiZSBhcHBsaWNhYmxlIHRvIHBhcnRzIG9mIHRoZSBs YXN0IHF1ZXN0aW9uLg0KPiANCj4gQnV0IGluIGdlbmVyYWwgd2UgaGF2ZSBzbyBmYXIgbm90IGRp c2N1c3NlZCBtdWNoIG9uIHdoYXQgdGhlIGlzc3VlcyBhcmUNCj4gb24gdGhlIGFjdHVhbCBSVFAg bWVkaWEgcGxhbmUuDQo+IA0KPiBBcmUgc3VjaCByZXF1aXJlbWVudHMgc29tZXRoaW5nIHRoYXQg d2Ugd291bGQgbGlrZSB0byBkZXZlbG9wPw0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2Vz dGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywg RXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFC ICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYg ICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From allyn@cisco.com Wed May 11 14:48:17 2011 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 01E0DE08AA for ; Wed, 11 May 2011 14:48:16 -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 tTfKqfqkpIOd for ; Wed, 11 May 2011 14:48:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB91E08A6 for ; Wed, 11 May 2011 14:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3104; q=dns/txt; s=iport; t=1305150496; x=1306360096; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GFhsnjUQrUWdWi8QoBhUNXrkILu0gRJCwwHBgkL/+Fo=; b=kKdIjNbWBaCxgDi6JzyXBQjaKMk+fYqtHPUa2DJbEDDhChEswMnON9H6 zt1/pvf3EDBP8puQMf1nviv4nUImRo/qKFRC8mxUbvAImay4nnbPLiyzj Bjw+hmXYclmxhPBYAys7roiQNeh9J0NMctWysFzGY9LUx1IS+c6QNsV5O I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAHkDy02rRDoJ/2dsb2JhbACEEEeSe41Ha3eqPo0CkTcCgSiDYIEGBIZDjV2KUQ Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 21:48:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4BLmFIk015750; Wed, 11 May 2011 21:48:15 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 14:48:15 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 11 May 2011 14:48:14 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583BBC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4DCA922C.4000901@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-clue-telepresence-requirements-02: RTP Media plane requirements Thread-Index: AcwP4T6u9JvSshsKR4+tymRlPnGLgAAQoiOA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0425BC8B@xmb-sjc-221.amer.cisco.com> <4DCA922C.4000901@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" X-OriginalArrivalTime: 11 May 2011 21:48:15.0940 (UTC) FILETIME=[22222840:01CC1025] Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: RTP Media plane requirements 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, 11 May 2011 21:48:17 -0000 SGkgTWFnbnVzLA0KWWVzLCBtb3N0IGRlZmluaXRlbHksIHdlIG5lZWQgdG8gZGV2ZWxvcCB0aGVz ZSBSVFAgcmVsYXRlZCByZXF1aXJlbWVudHMuLiANCg0KQnV0IGRvIHlvdSBzZWUgdGhlbSByZWxh dGVkIHRvIHRoaXMgcmVxdWlyZW1lbnRzIGRyYWZ0PyAgSSB0aGluayB0aGF0IHRoaXMgcmVxdWly ZW1lbnRzIGRyYWZ0IGlzIGp1c3QgZm9yIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBDTFVFIHNw ZWNpZmljYXRpb24uLiB3aGljaCBpcyBhYm91dCBleGNoYW5naW5nIGluZm9ybWF0aW9uLiANCg0K VGhlIGNoYXJ0ZXIgc2F5cyB0aGF0IGl0IGlzIGluIHNjb3BlIHRvIGNvbnNpZGVyIHRoZSBJbnRl cm9wIHJlcXVpcmVtZW50cyBmb3IgdGhlIFJUUCBtZWRpYSBwbGFuZSBhbmQgdGhlbiBicmluZyB0 aGVtIHRvIGFwcHJvcHJpYXRlIFdHcy4gSSBzZWUgaXQgYXMgYSBzZXBhcmF0ZSB3b3JrIGl0ZW0u DQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpCZXN0LA0KQWxseW4NCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hZ251cyBXZXN0ZXJsdW5kIFttYWlsdG86bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAx MSA2OjQyIEFNDQo+IFRvOiBBbGx5biBSb21hbm93IChhbGx5bikNCj4gQ2M6IENMVUUNCj4gU3Vi amVjdDogZHJhZnQtcm9tYW5vdy1jbHVlLXRlbGVwcmVzZW5jZS1yZXF1aXJlbWVudHMtMDI6IFJU UCBNZWRpYQ0KPiBwbGFuZSByZXF1aXJlbWVudHMNCj4gDQo+IEhpLA0KPiANCj4gSSBoYXZlIHJl dmlld2VkIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgcmVxdWlyZW1lbnRzIGFuZCBJIGRvIHdvbmRl ciBpZg0KPiB0aGlzIGRvY3VtZW50IG5lZWRzIHRvIGhhdmUgc29tZSByZXF1aXJlbWVudHMgbW9y ZSBkaXJlY3RseSByZWxhdGVkIHRvDQo+IHRoZSBtZWRpYSBwbGFuZSwgaS5lLiBSVFAgdHJhbnNw b3J0IG9mIG1lZGlhLg0KPiANCj4gVG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5IGl0IGlzIHF1 aXRlIGNsZWFyIGZyb20gbXkgcGVyc3BlY3RpdmUgdGhhdA0KPiBSVFAgcmVsYXRlZCBxdWVzdGlv bnMgbGlrZToNCj4gDQo+IC0gSG93IG9uZSBwZXJmb3JtcyBtdWx0aXBsZXhpbmcgb3ZlciBSVFAN Cj4gLSBJZiBhbmQgaG93IFNpbXVsY2FzdCBpcyB0byBiZSBzdXBwb3J0ZWQNCj4gLSBJZiByZWxh eWVkIGNlbnRyYWxpemVkIG1vZGVscyBhcmUgdG8gYmUgc3VwcG9ydGVkIHRoZXJlIHdpbGwgYmUN Cj4gcXVlc3Rpb25zIGFyb3VuZCBzdHJlYW0gY29udHJvbC4NCj4gDQo+IFN1cmUsDQo+ICAgIFJF UU1ULTg6ICAgVGhlIHNvbHV0aW9uIE1VU1QgaW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGljaCB0 aGUNCj4gICAgICAgICAgICAgICByZWNlaXZlciAoZW5kcG9pbnQgb3IgTUNVKSBjYW4gc3BlY2lm eSB0byB0aGUgc2VuZGVyDQo+ICAgICAgICAgICAgICAgKGVuZHBvaW50IG9yIE1DVSkgd2hhdCBz dHJlYW1zIGl0IHdhbnRzIHRvIHJlY2VpdmUuDQo+IGNhbiBiZSBpbnRlcnByZXRlZCB0byBiZSBh cHBsaWNhYmxlIHRvIHBhcnRzIG9mIHRoZSBsYXN0IHF1ZXN0aW9uLg0KPiANCj4gQnV0IGluIGdl bmVyYWwgd2UgaGF2ZSBzbyBmYXIgbm90IGRpc2N1c3NlZCBtdWNoIG9uIHdoYXQgdGhlIGlzc3Vl cyBhcmUNCj4gb24gdGhlIGFjdHVhbCBSVFAgbWVkaWEgcGxhbmUuDQo+IA0KPiBBcmUgc3VjaCBy ZXF1aXJlbWVudHMgc29tZXRoaW5nIHRoYXQgd2Ugd291bGQgbGlrZSB0byBkZXZlbG9wPw0KPiAN Cj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAx MCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDcz IDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From allyn@cisco.com Wed May 11 18:20:32 2011 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 3DE47E06FE for ; Wed, 11 May 2011 18:20:32 -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 GbLfL9-cZgk4 for ; Wed, 11 May 2011 18:20:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5677CE06F3 for ; Wed, 11 May 2011 18:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3511; q=dns/txt; s=iport; t=1305163231; x=1306372831; h=mime-version:subject:date:message-id:from:to:cc; bh=J/bp2b5Bc32ZXjZffMUf+tbsSuP7UuWGjpzLx/BjVIU=; b=cag9jHyzuw7oNxm6WdR4OgOdFG6DBXi4Ve76GLKxiH+OpP9PO4MKBfJD Sylwol32IpQT8TAvcGyNSBfASlT7wqk7cJZH5Fo0XntJ/95SZbKMCD0Wb F+X1WI27yM8Uv7fY/h+y2rYDKxGuuawW0jQpBHk5tJ5bUajAuwkXiexWM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALw0y02rRDoH/2dsb2JhbACCZKMMd6tAnj6GEQSGRI1filQ X-IronPort-AV: E=Sophos;i="4.64,355,1301875200"; d="scan'208,217";a="446150863" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 12 May 2011 01:20:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4C1KVeg018550; Thu, 12 May 2011 01:20:31 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 18:20:31 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1042.C897FDE2" Date: Wed, 11 May 2011 18:20:29 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8A== From: "Allyn Romanow (allyn)" To: , "Roni Even" X-OriginalArrivalTime: 12 May 2011 01:20:31.0030 (UTC) FILETIME=[C8D6AD60:01CC1042] Cc: CLUE Subject: [clue] legacy support in requirements 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, 12 May 2011 01:20:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1042.C897FDE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 You both asked to add a requirement for legacy support. However, the charter says =20 "Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required." =20 On the basis of this, I think it would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible for endpoints with varying capabilities to interoperate in a telepresence conference. =20 Regards, Allyn ------_=_NextPart_001_01CC1042.C897FDE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

You both asked to add a requirement for legacy = support. However, the charter says

 

“Interoperation with SIP and related = standards for audio and video is required. However, backwards compatibility with = existing
non-standards compliant telepresence systems is not = required.”

 

On the basis of this, I think it would not be a = good requirement to add. However, there is a requirement, 10, that addresses = making it possible for endpoints with varying capabilities to interoperate in a telepresence conference.

 

Regards,

Allyn

------_=_NextPart_001_01CC1042.C897FDE2-- From mark.gorzynski@hp.com Wed May 11 18:20:52 2011 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 46B13E06FE for ; Wed, 11 May 2011 18:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QHxkStyMKJEf for ; Wed, 11 May 2011 18:20:50 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 11143E06B9 for ; Wed, 11 May 2011 18:20:50 -0700 (PDT) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 899361C256 for ; Thu, 12 May 2011 01:20:49 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 01:18:17 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Thu, 12 May 2011 01:18:14 +0000 From: "Gorzynski, Mark E (The Right One)" To: "clue@ietf.org" Date: Thu, 12 May 2011 01:18:09 +0000 Thread-Topic: virtual space (multi-view) use case Thread-Index: AcwQQdt4Du/Zyg6GRuuSA4Zz7g1W6A== Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6AF8E92GVW1096EXBame_" MIME-Version: 1.0 Subject: [clue] virtual space (multi-view) use case 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, 12 May 2011 01:20:52 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF8E92GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, It occurs to me that one use case commonly represented in products on the m= arket today may not have been fully described. It has been referred to as = a "multi-view" use case since it deals with cameras at different viewpoints= aimed at the same area of an endpoint. However we use the term "virtual s= pace" for this use case since it has been called by this name in the litera= ture (see below). 1. Virtual Space Multipoint This use case describes a virtual space multipoint video meeting with good = eye contact and spatial layout of participants. The use case was proposed = very early in the development of video conferencing systems as described in= 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738 ). = The use case is illustrated in figure 2-5 of their report. Today, the use = case is implemented in multiple telepresence type video conferencing system= s on the market. The term "virtual space" was used in their report. The m= ain difference between the result obtained with modern systems and those fr= om 1983 are larger display sizes. Virtual space multipoint as defined here assumes endpoints with multiple ca= meras and displays. Usually there are the same number of cameras and displ= ays at a given endpoint. A camera is positioned above each display. A key= aspect of virtual space multipoint is the details of how the cameras are a= imed. The cameras are each aimed on the same area of view of the participa= nts at the site. Thus each camera takes a picture of the same set of peopl= e but from a different angle. Each endpoint sender in the virtual space mu= ltipoint meeting therefore offers a choice of video streams to remote recei= vers, each stream representing a different view point. For example a camer= a positioned above a display to a participant's left may take video picture= s of the participant's left ear while at the same time, a camera positioned= above a display to the participant's right may take video pictures of the = participant's right ear. Since a sending endpoint has a camera associated with each display, an asso= ciation is made between the receiving stream output on a particular display= and the corresponding sending stream from the camera associated with that = display. These associations are repeated for each display/camera pair in a= meeting. The result of this system is a horizontal arrangement of video i= mages from remote sites, one per display. The image from each display is p= aired with the camera output from the camera above that display resulting i= n excellent eye contact. Best Regards, Mark Gorzynski HP Visual Collaboration --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF8E92GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,<= /o:p>

 

It = occurs to me that one use case commonly represented in products on the mark= et today may not have been fully described.  It has been referred to a= s a “multi-view” use case since it deals with cameras at differ= ent viewpoints aimed at the same area of an endpoint.  However we use = the term “virtual space” for this use case since it has been ca= lled by this name in the literature (see below).

 

1. Virtual Space Multipoint

 

This use case de= scribes a virtual space multipoint video meeting with good eye contact and = spatial layout of participants.  The use case was proposed very early = in the development of video conferencing systems as described in 1983 by Al= lardyce and Randal (http= ://handle.dtic.mil/100.2/ADA127738  ).  The use case is illus= trated in figure 2-5 of their report.  Today, the use case is implemen= ted in multiple telepresence type video conferencing systems on the market.=   The term “virtual space” was used in their report. = The main difference between the result obtained with modern systems and th= ose from 1983 are larger display sizes.

=  

Virtual space multipoint as defin= ed here assumes endpoints with multiple cameras and displays.  Usually= there are the same number of cameras and displays at a given endpoint.&nbs= p; A camera is positioned above each display.  A key aspect of virtual= space multipoint is the details of how the cameras are aimed.  The ca= meras are each aimed on the same area of view of the participants at the si= te.  Thus each camera takes a picture of the same set of people but fr= om a different angle.  Each endpoint sender in the virtual space multi= point meeting therefore offers a choice of video streams to remote receiver= s, each stream representing a different view point.  For example a cam= era positioned above a display to a participant’s left may take video= pictures of the participant’s left ear while at the same time, a cam= era positioned above a display to the participant’s right may take vi= deo pictures of the participant’s right ear.

 

Since a sending endp= oint has a camera associated with each display, an association is made betw= een the receiving stream output on a particular display and the correspondi= ng sending stream from the camera associated with that display.  These= associations are repeated for each display/camera pair in a meeting. = The result of this system is a horizontal arrangement of video images from= remote sites, one per display.  The image from each display is paired= with the camera output from the camera above that display resulting in exc= ellent eye contact.

 

 

 = ;

Best Regards,

 

Mark Gorzynski

HP Vi= sual Collaboration

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF8E92GVW1096EXBame_-- From allyn@cisco.com Wed May 11 19:48:00 2011 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 37D7DE06DA for ; Wed, 11 May 2011 19:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEOycmoNfPTJ for ; Wed, 11 May 2011 19:47:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 391C0E069C for ; Wed, 11 May 2011 19:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6190; q=dns/txt; s=iport; t=1305168479; x=1306378079; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/knFI/q/s7dUQxRjlQlFvJjcK3AhZa7EAmM7vR04c9Q=; b=e29gmqKforySGF4LYBwCwefRL6JFC04s43MhKTP2gfxy7vG2+W0YWAbe qU2yXCD97RRtYvCOtM720l+BmWY5urs1Jgkuec7O91ep7pP5y7y3p8b4J RB0mJCPpmq8e92NmI3RXZT0gY2n90tUg7URThW/n5z9xf+6/6j6zJA1dO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAEtJy02rRDoI/2dsb2JhbACXPY4zd4hwokqePYYRBIZEjV+KVA X-IronPort-AV: E=Sophos;i="4.64,356,1301875200"; d="scan'208";a="695998321" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 12 May 2011 02:47:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4C2lwVS016599; Thu, 12 May 2011 02:47:58 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 19:47:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 19:47:55 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZg References: From: "Allyn Romanow (allyn)" To: , X-OriginalArrivalTime: 12 May 2011 02:47:58.0873 (UTC) FILETIME=[00CBF890:01CC104F] Subject: Re: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 02:48:00 -0000 Greetings, Thanks for your comments, please see inline > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > stephane.cazeaux@orange-ftgroup.com > Sent: Wednesday, May 11, 2011 7:09 AM > To: clue@ietf.org > Subject: [clue] Comments on draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi, >=20 > Below some comments after review of this new draft, and of the earlier > discussions. >=20 > ++ > The definition of the middlebox is confusing. In certain cases, a > middle box could be initiator/terminator (of media and signaling), for > instance when a multipoint telepresence session is initiated by a MCU, > and the MCU sends media to the endpoints (kind of "waiting room") = until > all participants have joined. We could think that in such cases, the > MCU acts an endpoint, but this not very satisfying since endpoint as > defined in the document seems to be a physical entity rather than a > function or a role. Could you suggest text that will address your concern? Would you be = satisfied if we take out the word middle box and just use MCU, which = presumably is a well-understood term? =20 >=20 > The document shall be more explicit on the list of stream/endpoint > characteristics that the solution shall be able to signal. =A0This = would > help to further work on all requirements dealing with these > characteristics, and in particularly for the discussion on = requirements > 4 and 7. I think it would be inappropriate to list stream/endpoint = characteristics in the requirements. I feel that more specification is = part of the solution and that it would constrain the solution to = describe which characteristics within the requirements. >=20 > Is there a rationale of having removed a part of the REQMT-11 > (previously the REQMT-09 in version 01)? Talking here of the > requirement that allowed a remote to make the placement for the local. REQMT-9: CLUE must support different models of where layout decisions = are made - local and remote. * Local does the placement + Remote tells local what streams it has (content type, anything else?? = What exactly? [to be filled in] + Local tells the remote which streams it wants * Remote does the placement + Local tells the remote what its displays are, what its receive = positions are, how many streams it can receive + Remote specifies the placement for the local=20 Changed to The solution MUST support a layout model in which the local telepresence = system does the layout * Remote tells local properties of available captured/coded media (such = as: max video resolutions, spatial placements of capture devices, = capabilities of codecs, inter-codec dependencies,...) * Local, based on its knowledge of rendering systems, tells the remote = which streams it wants After considering this in some detail, a number of people felt it was = better to have the local do the placement and no one supported having = remote do the placement, so it was removed. >=20 > The lip sync should be added as a requirement to the solution. > Actually, I don't see why it should not be part of the solution. It is good to know your opinion. As there are some people who favor = including it, and others who feel it is implementation specific and not = a requirement. This will have to be resolved. It will be discussed = during the interim meeting tomorrow. >=20 > ++ Some requirements that could be added > We could add a requirement for the solution to support a means of > describing the role of streams (e.g. whether a media stream = corresponds > to a speaker image or to presentation slides). Yes, this is information that it would be good to send - I think this is = covered in Reqmt 4.=20 >=20 > The REQMT-9 deals with interoperability of endpoints having different > capabilities (e.g. resolution, CPU, ..), but there is no requirement > for a means of supporting this interoperability. This is especially > true for multipoint sessions with endpoints having different > capabilities (e.g. not the same resolution capability). We could add a > requirement for the solution to support a means of describing multiple > simultaneous identical streams with different resolutions (e.g. high > and low resolution). Note that without such requirement, the solution > would implicitly to have a media transcoding on the MCU to adapt a > stream to the capability of each endpoint. >=20 > As already mentioned by Roni, a requirement on interoperability with > legacy endpoints should be added. This is contrary to the charter, as per my note to you and Roni. It can = be discussed during interim meeting >=20 > We could add a requirement to support a mechanism allowing correlation > between several endpoints, to allow spatial arrangement (as required = in > REQMT-1 to 3) among several endpoints. Note that it does not intend to > replace the solution of multi-stream endpoints, but to add a solution > to make multi-stream with several endpoints as an alternative. I'm sorry, I don't quite understand this suggestion.=20 >=20 > ++ About wording . > We can see "endpoints" and "telepresence endpoints" in the document > (especially between REQMT-9 and REQMT-10). We should always use the > same term, else we could think that "endpoint" could designate "legacy > endpoint" (in contrast to the explicit term "telepresence endpoint"). > IMHO I prefer "telepresence endpoint" wording, more explicit. Okay, I see your point. But I would suggest changing 9 to say = "endpoints" since this and the Layout definition are the only two places = where "telepresence endpoint" is used. Are you okay with this? >=20 > The document deals sometime with "audio" and "video", and sometime = with > the generic word "media". Unless explicitly needed, we should always > use the generic term. >=20 Okay Regards, Allyn >=20 > Regards, > St=E9phane Cazeaux > Orange Labs >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From bruno.chatras@orange-ftgroup.com Wed May 11 23:50:18 2011 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 99AE3E06F9 for ; Wed, 11 May 2011 23:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6PMRWTblRnVi for ; Wed, 11 May 2011 23:50:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 04F8EE06E3 for ; Wed, 11 May 2011 23:50:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86C5F8B8010; Thu, 12 May 2011 08:50:46 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D6E0A8B800B; Thu, 12 May 2011 08:50:45 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 08:49:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1070.CE213113" Date: Thu, 12 May 2011 08:49:56 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> From: To: , , X-OriginalArrivalTime: 12 May 2011 06:49:57.0792 (UTC) FILETIME=[CEBF3200:01CC1070] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 12 May 2011 06:50:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1070.CE213113 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >From previous discussions on the mailing list and at IETF#80 I = understood that =AB non-standards compliant =BB was referring to = solutions that make use of proprietary extensions (e.g. proprietary = extensions to SDP or RTCP) while "legacy support" was referring to = standard compliant solutions that do not understand the extensions that = CLUE will specify (or request other groups to specify). The charter does = not exclude the second case and Req# 10 is not specific enough. From = the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined = extensions) with different capabilities, not to devices that do not = understand clue extensions... BC =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Allyn Romanow (allyn) Envoy=E9 : jeudi 12 mai 2011 03:20 =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even Cc : CLUE Objet : [clue] legacy support in requirements =20 Hi,=20 You both asked to add a requirement for legacy support. However, the = charter says =20 "Interoperation with SIP and related standards for audio and video is = required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required." =20 On the basis of this, I think it would not be a good requirement to add. = However, there is a requirement, 10, that addresses making it possible = for endpoints with varying capabilities to interoperate in a = telepresence conference. =20 Regards, Allyn ------_=_NextPart_001_01CC1070.CE213113 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

From = previous discussions on the mailing list and at IETF#80 I understood that = =AB non-standards compliant =BB was referring to solutions that make use of = proprietary extensions (e.g. proprietary extensions to SDP or RTCP) while “legacy = support” was referring to standard compliant solutions that do not understand the extensions that CLUE will specify (or request other groups to specify). = The charter does not exclude the second case and Req# 10 is not specific = enough. =A0From the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined extensions) with = different capabilities, not to devices that do not understand clue = extensions...

BC

 

De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Allyn Romanow (allyn)
Envoy=E9 : jeudi 12 mai 2011 03:20
=C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
Cc : CLUE
Objet : [clue] legacy support in = requirements

 

Hi,

You both asked to add a = requirement for legacy support. However, the charter says

 

“Interoperation with SIP = and related standards for audio and video is required. However, backwards = compatibility with existing
non-standards compliant telepresence systems is not = required.”

 

On the basis of this, I think it = would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible for endpoints with varying capabilities to = interoperate in a telepresence conference.

 

Regards,

Allyn

------_=_NextPart_001_01CC1070.CE213113-- From Even.roni@huawei.com Thu May 12 00:37:41 2011 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 5C77DE066A for ; Thu, 12 May 2011 00:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FcntbqEzsnbn for ; Thu, 12 May 2011 00:37:39 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1A8E0669 for ; Thu, 12 May 2011 00:37:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200BPCNPX8E@szxga04-in.huawei.com> for clue@ietf.org; Thu, 12 May 2011 15:34:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200BVCNPWP8@szxga04-in.huawei.com> for clue@ietf.org; Thu, 12 May 2011 15:34:45 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-8-204.red.bezeqint.net [79.177.8.204]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL200GOWNPQKR@szxml11-in.huawei.com>; Thu, 12 May 2011 15:34:44 +0800 (CST) Date: Thu, 12 May 2011 10:33:19 +0300 From: Roni Even In-reply-to: <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> To: bruno.chatras@orange-ftgroup.com, allyn@cisco.com, stephane.cazeaux@orange-ftgroup.com Message-id: <00bb01cc1076$e2600270$a7200750$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KpBXCjAh8oJdMZfY1GV3dg)" Content-language: en-us Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQAAGnbKA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 12 May 2011 07:37:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_KpBXCjAh8oJdMZfY1GV3dg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, I have the same view.=20 It is important to address the issue where a system with CLUE extension = will try to interoperate with a system that is SIP compliant but do not = support the CLUE extensions. =20 Roni =20 From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Thursday, May 12, 2011 9:50 AM To: allyn@cisco.com; stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 Hi, >From previous discussions on the mailing list and at IETF#80 I = understood that =AB non-standards compliant =BB was referring to solutions that = make use of proprietary extensions (e.g. proprietary extensions to SDP or RTCP) = while =93legacy support=94 was referring to standard compliant solutions that = do not understand the extensions that CLUE will specify (or request other = groups to specify). The charter does not exclude the second case and Req# 10 is = not specific enough. From the current text, one could understand that = Req#10 applies to clue-compliant devices (i.e. devices that understand = clue-defined extensions) with different capabilities, not to devices that do not understand clue extensions... BC =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Allyn Romanow (allyn) Envoy=E9 : jeudi 12 mai 2011 03:20 =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even Cc : CLUE Objet : [clue] legacy support in requirements =20 Hi,=20 You both asked to add a requirement for legacy support. However, the = charter says =20 =93Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required.=94 =20 On the basis of this, I think it would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible = for endpoints with varying capabilities to interoperate in a telepresence conference. =20 Regards, Allyn --Boundary_(ID_KpBXCjAh8oJdMZfY1GV3dg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi,

I have the same view. =

It is important to address the issue where a = system with CLUE extension will try to interoperate with a system that = is SIP compliant but do not support the CLUE = extensions.

 

Roni

 

From:= = bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Thursday, May = 12, 2011 9:50 AM
To: allyn@cisco.com; = stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: = clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

Hi,

From previous = discussions on the mailing list and at IETF#80 I understood that = =AB non-standards compliant =BB was referring to solutions = that make use of proprietary extensions (e.g. proprietary extensions to = SDP or RTCP) while “legacy support” was referring to = standard compliant solutions that do not understand the extensions that = CLUE will specify (or request other groups to specify). The charter does = not exclude the second case and Req# 10 is not specific enough. =  From the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined = extensions) with different capabilities, not to devices that do not = understand clue extensions...

BC

 

De : = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Allyn Romanow (allyn)
Envoy=E9 : jeudi 12 mai 2011 = 03:20
=C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni = Even
Cc : CLUE
Objet : [clue] legacy = support in requirements

 

Hi,

You both asked = to add a requirement for legacy support. However, the charter = says

 

“Interoperation with SIP and related standards = for audio and video is required. However, backwards compatibility with = existing
non-standards compliant telepresence systems is not = required.”

 

On the basis = of this, I think it would not be a good requirement to add. However, = there is a requirement, 10, that addresses making it possible for = endpoints with varying capabilities to interoperate in a telepresence = conference.

 

Regards,

Allyn

= --Boundary_(ID_KpBXCjAh8oJdMZfY1GV3dg)-- From Even.roni@huawei.com Thu May 12 00:46:26 2011 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 CC978E068B for ; Thu, 12 May 2011 00:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 VsAeEcULz0-H for ; Thu, 12 May 2011 00:46:23 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A8055E0669 for ; Thu, 12 May 2011 00:46:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL2005N1O8EIT@szxga05-in.huawei.com> for clue@ietf.org; Thu, 12 May 2011 15:45:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200C99O8EG8@szxga05-in.huawei.com> for clue@ietf.org; Thu, 12 May 2011 15:45:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-8-204.red.bezeqint.net [79.177.8.204]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL200GD7O88KR@szxml11-in.huawei.com>; Thu, 12 May 2011 15:45:50 +0800 (CST) Date: Thu, 12 May 2011 10:44:27 +0300 From: Roni Even In-reply-to: To: 'Mary Barnes' , 'CLUE' Message-id: <00c601cc1078$6eba12f0$4c2e38d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_K4UYvQw+wRFhsmkK5a2u4Q)" Content-language: en-us Thread-index: AcwQAKiBEMuDWJdvQR6DKw9MHRQN7AAdsZ9A iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: Subject: Re: [clue] Reminder: Meeting invitation: CLUE Interim - May 12th 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, 12 May 2011 07:46:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_K4UYvQw+wRFhsmkK5a2u4Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Mary, I am not sure which document will include the terminology or will it be distribute among multiple documents. Currently there are some terms in the requirement document. I am looking at the comments from IETF80 and on the use case there was a question what is left and right for camera and display. So it may be good to clarify the issue of which document if any will include the terminology at the meeting. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, May 11, 2011 8:27 PM To: CLUE Subject: [clue] Reminder: Meeting invitation: CLUE Interim - May 12th Hi Folks, A reminder of the meeting tomorrow. As far as agenda, the only item on the agenda is discussion of the Requirements document. We've had excellent discussion on the mailing list and can hopefully discuss and close off many of the issues tomorrow. All the information related to the meeting is/will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary. On Wed, Apr 20, 2011 at 1:34 PM, Mary Barnes wrote: Hi all, Below, please find the details for joining the CLUE WG virtual interim meeting. We will have a detailed agenda out about a week before the meeting. Per my other email, the focus will be completing the use cases and reviewing the updated requriements document, which should be submitted soon. Regards, Mary. CLUE WG co-chair ---------- Forwarded message ---------- From: IETF Secretariat Date: Wed, Apr 20, 2011 at 1:06 PM Subject: Meeting invitation: CLUE To: mary.ietf.barnes@gmail.com Hello , IETF Secretariat invites you to attend this online meeting. Topic: CLUE Date: Thursday, May 12, 2011 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 969 701 031 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=152624022 &UID=1209871362&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=152624022 &UID=1209871362&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC &ED=152624022&tollFree=0 Access code:969 701 031 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=152624022 &UID=1209871362&ICS=MI&LD=1&RD=2&ST=1&SHA2=T5lcZ2jRKRus52o8tbim6clC9o6bq8UKS KVm-SyhJlY=&RT=MiM0 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://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x969701031# 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. --Boundary_(ID_K4UYvQw+wRFhsmkK5a2u4Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Mary,

I am not sure which document will include the terminology or will it be distribute among multiple documents. Currently there are some terms in the requirement document. I am looking at the comments from IETF80 and on the use case there was a question what is left and right for camera and display. So it may be good to clarify the issue of which document if any will include the terminology at the meeting.

 

Roni 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Wednesday, May 11, 2011 8:27 PM
To: CLUE
Subject: [clue] Reminder: Meeting invitation: CLUE Interim - May 12th

 

Hi Folks,

 

A reminder of the meeting tomorrow.  As far as agenda, the only item on the agenda is discussion of the Requirem ents doc t discussion on the mailing list and can hopefully discuss and close off many of the issues tomorrow.  All the information related to the meeting is/will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki

 

Regards,

Mary. 

On Wed, Apr 20, 2011 at 1:34 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi all,

 

Below, please find the details for joining the CLUE WG virtual interim meeting.  We will have a detailed agenda out about a week before the meeting.  Per my other email, the f ocus wil ases and reviewing the updated requriements document, which should be submitted soon.

 

Regards,

Mary.

CLUE WG co-chair

 

---------- Forwarded message ----------
From: IETF Secretariat <messenger@webex.com>
Date: Wed, Apr 20, 2011 at 1:06 PM
Subject: Meeting invitation: CLUE
To: mary.ietf.barnes@gmail.com



Hello ,

IETF Secretariat invites you to attend this online meeting.

Topic: CLUE
Date: Thursday, May 12, 2011
Time: 8:00 am, Pacific Daylight Time (San Francis co, GMT- : 969 701 031
Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&RT=MiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting does not require a password.)
4. Click "Join".

To view in other time zones or languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&ORT=MiM0

------------------- -------- ---
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=152624022&tollFree=0

Access code:969 701 031

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

You can contact me at:
amorris@amsl.com
1-510-492-4081

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=152624022&UID=1209871362&ICS=MI&LD=1&RD=2&ST=1&SHA2=T5lcZ2jRKRus52o8tbim6clC9o6bq8UKSKVm-SyhJlY=&RT=MiM0

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://workgreen.webex.com/workgreen/systemdiagnosis. php r>
Sign up for a fr e trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+14087926300x969701031#

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.

 

 

--Boundary_(ID_K4UYvQw+wRFhsmkK5a2u4Q)-- From john.elwell@siemens-enterprise.com Thu May 12 01:00:24 2011 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 216D3E06DD for ; Thu, 12 May 2011 01:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 Rznbk33T9Omd for ; Thu, 12 May 2011 01:00:23 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 3A431E06C2 for ; Thu, 12 May 2011 01:00:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1305187221!6754313!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 8461 invoked from network); 12 May 2011 08:00:21 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-182.messagelabs.com with SMTP; 12 May 2011 08:00:21 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B568E1EB83ED; Thu, 12 May 2011 10:00:21 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 12 May 2011 10:00:22 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , "stephane.cazeaux@orange-ftgroup.com" , "clue@ietf.org" Date: Thu, 12 May 2011 10:00:20 +0200 Thread-Topic: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 08:00:24 -0000 > > We could add a requirement for the solution to support a means of > > describing the role of streams (e.g. whether a media stream=20 > corresponds > > to a speaker image or to presentation slides). [JRE] I am concerned about adding requirements for which we appear to have = solutions already, unless those solutions are inappropriate or need to be e= xtended for use in a telepresence environment. In this particular case, we = already have the SDP a=3Dcontent attribute (RFC 4796), so it is unclear to = me what else we would need. >=20 > Yes, this is information that it would be good to send - I=20 > think this is covered in Reqmt 4.=20 [JRE] REQMT-4 is very vague (as I think has been mentioned before), so it p= robably needs to be tightened up. However, the role of streams is something= I think we already have a solution for, so does not need to be mentioned i= n a reworded REQMT-4. John From john.elwell@siemens-enterprise.com Thu May 12 01:01:39 2011 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 AB8DAE0738 for ; Thu, 12 May 2011 01:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 vir2W0IlpSTB for ; Thu, 12 May 2011 01:01:39 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id B5AC6E0724 for ; Thu, 12 May 2011 01:01:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1305187297!6587215!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 26947 invoked from network); 12 May 2011 08:01:37 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-182.messagelabs.com with SMTP; 12 May 2011 08:01:37 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B513723F03E8; Thu, 12 May 2011 10:01:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 12 May 2011 10:01:38 +0200 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "allyn@cisco.com" , "stephane.cazeaux@orange-ftgroup.com" , "Even.roni@huawei.com" Date: Thu, 12 May 2011 10:01:36 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQAALI+RA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 12 May 2011 08:01:39 -0000 +1 John=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of bruno.chatras@orange-ftgroup.com > Sent: 12 May 2011 07:50 > To: allyn@cisco.com; stephane.cazeaux@orange-ftgroup.com;=20 > Even.roni@huawei.com > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Hi, >=20 > From previous discussions on the mailing list and at IETF#80=20 > I understood that =AB non-standards compliant =BB was referring=20 > to solutions that make use of proprietary extensions (e.g.=20 > proprietary extensions to SDP or RTCP) while "legacy support"=20 > was referring to standard compliant solutions that do not=20 > understand the extensions that CLUE will specify (or request=20 > other groups to specify). The charter does not exclude the=20 > second case and Req# 10 is not specific enough. From the=20 > current text, one could understand that Req#10 applies to=20 > clue-compliant devices (i.e. devices that understand=20 > clue-defined extensions) with different capabilities, not to=20 > devices that do not understand clue extensions... >=20 > BC >=20 > =20 >=20 > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De=20 > la part de Allyn Romanow (allyn) > Envoy=E9 : jeudi 12 mai 2011 03:20 > =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > Cc : CLUE > Objet : [clue] legacy support in requirements >=20 > =20 >=20 > Hi,=20 >=20 > You both asked to add a requirement for legacy support.=20 > However, the charter says >=20 > =20 >=20 > "Interoperation with SIP and related standards for audio and=20 > video is required. However, backwards compatibility with existing > non-standards compliant telepresence systems is not required." >=20 > =20 >=20 > On the basis of this, I think it would not be a good=20 > requirement to add. However, there is a requirement, 10, that=20 > addresses making it possible for endpoints with varying=20 > capabilities to interoperate in a telepresence conference. >=20 > =20 >=20 > Regards, >=20 > Allyn >=20 > = From stephane.cazeaux@orange-ftgroup.com Thu May 12 01:40:18 2011 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 E034CE0734 for ; Thu, 12 May 2011 01:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 p-hWlcK7yqIO for ; Thu, 12 May 2011 01:40:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5413FE069A for ; Thu, 12 May 2011 01:40:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 29F1B858019; Thu, 12 May 2011 10:47:03 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 229B585800C; Thu, 12 May 2011 10:47:03 +0200 (CEST) Received: from ftrdhub1.rd.francetelecom.fr ([10.193.109.193]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 10:40:13 +0200 Received: from FTRDCH02.rd.francetelecom.fr (10.194.32.13) by ftrdhub1.rd.francetelecom.fr (10.193.109.193) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 12 May 2011 10:40:12 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Thu, 12 May 2011 10:40:11 +0200 From: To: , Thread-Topic: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABREH/A= Date: Thu, 12 May 2011 08:40:10 +0000 Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 May 2011 08:40:13.0200 (UTC) FILETIME=[35D65900:01CC1080] Subject: Re: [clue] Comments on draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 08:40:19 -0000 Hi, Some answers inline. Regards, Stephane. -----Message d'origine----- De=A0: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Envoy=E9=A0: jeudi 12 mai 2011 04:48 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE; clue@ietf.org Objet=A0: RE: [clue] Comments on draft-romanow-clue-telepresence-requiremen= ts-02 Greetings, Thanks for your comments, please see inline > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > stephane.cazeaux@orange-ftgroup.com > Sent: Wednesday, May 11, 2011 7:09 AM > To: clue@ietf.org > Subject: [clue] Comments on draft-romanow-clue-telepresence- > requirements-02 >=20 > Hi, >=20 > Below some comments after review of this new draft, and of the earlier > discussions. >=20 > ++ > The definition of the middlebox is confusing. In certain cases, a > middle box could be initiator/terminator (of media and signaling), for > instance when a multipoint telepresence session is initiated by a MCU, > and the MCU sends media to the endpoints (kind of "waiting room") until > all participants have joined. We could think that in such cases, the > MCU acts an endpoint, but this not very satisfying since endpoint as > defined in the document seems to be a physical entity rather than a > function or a role. Could you suggest text that will address your concern? Would you be satisfi= ed if we take out the word middle box and just use MCU, which presumably is= a well-understood term? [SC] I suggest removing the sentence "In contrast to an endpoint [...] nor = the final terminator".=20 >=20 > The document shall be more explicit on the list of stream/endpoint > characteristics that the solution shall be able to signal. =A0This would > help to further work on all requirements dealing with these > characteristics, and in particularly for the discussion on requirements > 4 and 7. I think it would be inappropriate to list stream/endpoint characteristics i= n the requirements. I feel that more specification is part of the solution = and that it would constrain the solution to describe which characteristics = within the requirements. [SC] My concern here is that without a list, we cannot figure out if all re= quirements are consistent, or if the later solution will fulfil all require= ments.=20 >=20 > Is there a rationale of having removed a part of the REQMT-11 > (previously the REQMT-09 in version 01)? Talking here of the > requirement that allowed a remote to make the placement for the local. REQMT-9: CLUE must support different models of where layout decisions are m= ade - local and remote. * Local does the placement + Remote tells local what streams it has (content type, anything else?? Wh= at exactly? [to be filled in] + Local tells the remote which streams it wants * Remote does the placement + Local tells the remote what its displays are, what its receive positions= are, how many streams it can receive + Remote specifies the placement for the local=20 Changed to The solution MUST support a layout model in which the local telepresence sy= stem does the layout * Remote tells local properties of available captured/coded media (such as:= max video resolutions, spatial placements of capture devices, capabilities= of codecs, inter-codec dependencies,...) * Local, based on its knowledge of rendering systems, tells the remote whic= h streams it wants After considering this in some detail, a number of people felt it was bette= r to have the local do the placement and no one supported having remote do = the placement, so it was removed. [SC] When the remote is a MCU, it makes sense that remote does the placemen= t, especially for multipoint sessions with segment switching and/or video m= ixing policies (e.g. in segment switching policy, the MCU does places on th= e same screen - the left one for instance - for all endpoints so that parti= cipants will all look in the same direction).=20 >=20 > The lip sync should be added as a requirement to the solution. > Actually, I don't see why it should not be part of the solution. It is good to know your opinion. As there are some people who favor includi= ng it, and others who feel it is implementation specific and not a requirem= ent. This will have to be resolved. It will be discussed during the interim= meeting tomorrow. >=20 > ++ Some requirements that could be added > We could add a requirement for the solution to support a means of > describing the role of streams (e.g. whether a media stream corresponds > to a speaker image or to presentation slides). Yes, this is information that it would be good to send - I think this is co= vered in Reqmt 4.=20 >=20 > The REQMT-9 deals with interoperability of endpoints having different > capabilities (e.g. resolution, CPU, ..), but there is no requirement > for a means of supporting this interoperability. This is especially > true for multipoint sessions with endpoints having different > capabilities (e.g. not the same resolution capability). We could add a > requirement for the solution to support a means of describing multiple > simultaneous identical streams with different resolutions (e.g. high > and low resolution). Note that without such requirement, the solution > would implicitly to have a media transcoding on the MCU to adapt a > stream to the capability of each endpoint. >=20 > As already mentioned by Roni, a requirement on interoperability with > legacy endpoints should be added. This is contrary to the charter, as per my note to you and Roni. It can be = discussed during interim meeting >=20 > We could add a requirement to support a mechanism allowing correlation > between several endpoints, to allow spatial arrangement (as required in > REQMT-1 to 3) among several endpoints. Note that it does not intend to > replace the solution of multi-stream endpoints, but to add a solution > to make multi-stream with several endpoints as an alternative. I'm sorry, I don't quite understand this suggestion.=20 [SC] My suggestion is to have a mean to setup kind of "virtual" endpoint ma= de of several endpoints. Note that this suggestion is obviously limited to = multipoint sessions with a MCU that will treat this correlation, and then c= onsider correlated endpoints as if they were devices of a same endpoint. Such configurations will be feasible, but with proprietary implementations = (e.g. static configuration in MCU to declare correlated endpoints). Having = a standard mean would be nice. >=20 > ++ About wording . > We can see "endpoints" and "telepresence endpoints" in the document > (especially between REQMT-9 and REQMT-10). We should always use the > same term, else we could think that "endpoint" could designate "legacy > endpoint" (in contrast to the explicit term "telepresence endpoint"). > IMHO I prefer "telepresence endpoint" wording, more explicit. Okay, I see your point. But I would suggest changing 9 to say "endpoints" s= ince this and the Layout definition are the only two places where "telepres= ence endpoint" is used. Are you okay with this? [SC] OK. >=20 > The document deals sometime with "audio" and "video", and sometime with > the generic word "media". Unless explicitly needed, we should always > use the generic term. >=20 Okay Regards, Allyn >=20 > Regards, > St=E9phane Cazeaux > Orange Labs >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From peter.musgrave@magorcorp.com Thu May 12 04:03:19 2011 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 2C632E0710 for ; Thu, 12 May 2011 04:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3S-MU0He+UD for ; Thu, 12 May 2011 04:03:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0718E069D for ; Thu, 12 May 2011 04:03:14 -0700 (PDT) Received: by iwn39 with SMTP id 39so1686871iwn.31 for ; Thu, 12 May 2011 04:03:14 -0700 (PDT) Received: by 10.43.58.147 with SMTP id wk19mr38666icb.400.1305198194272; Thu, 12 May 2011 04:03:14 -0700 (PDT) Received: from [192.168.1.103] ([204.237.32.134]) by mx.google.com with ESMTPS id o3sm476950ibd.10.2011.05.12.04.03.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 04:03:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-48-473471783 From: Peter Musgrave In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> Date: Thu, 12 May 2011 07:03:06 -0400 Message-Id: <4C60EB16-F097-417C-AA75-C0397D0052E7@magorcorp.com> References: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> To: "Gorzynski, Mark E (The Right One)" X-Mailer: Apple Mail (2.1084) Cc: "clue@ietf.org" Subject: Re: [clue] virtual space (multi-view) use case 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, 12 May 2011 11:03:19 -0000 --Apple-Mail-48-473471783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 (I work on a product which fits this use case).=20 Peter Musgrave On 2011-05-11, at 9:18 PM, Gorzynski, Mark E (The Right One) wrote: > Greetings, > =20 > It occurs to me that one use case commonly represented in products on = the market today may not have been fully described. It has been = referred to as a =93multi-view=94 use case since it deals with cameras = at different viewpoints aimed at the same area of an endpoint. However = we use the term =93virtual space=94 for this use case since it has been = called by this name in the literature (see below). > =20 > 1. Virtual Space Multipoint > =20 > This use case describes a virtual space multipoint video meeting with = good eye contact and spatial layout of participants. The use case was = proposed very early in the development of video conferencing systems as = described in 1983 by Allardyce and Randal = (http://handle.dtic.mil/100.2/ADA127738 ). The use case is illustrated = in figure 2-5 of their report. Today, the use case is implemented in = multiple telepresence type video conferencing systems on the market. = The term =93virtual space=94 was used in their report. The main = difference between the result obtained with modern systems and those = from 1983 are larger display sizes. > =20 > Virtual space multipoint as defined here assumes endpoints with = multiple cameras and displays. Usually there are the same number of = cameras and displays at a given endpoint. A camera is positioned above = each display. A key aspect of virtual space multipoint is the details = of how the cameras are aimed. The cameras are each aimed on the same = area of view of the participants at the site. Thus each camera takes a = picture of the same set of people but from a different angle. Each = endpoint sender in the virtual space multipoint meeting therefore offers = a choice of video streams to remote receivers, each stream representing = a different view point. For example a camera positioned above a display = to a participant=92s left may take video pictures of the participant=92s = left ear while at the same time, a camera positioned above a display to = the participant=92s right may take video pictures of the participant=92s = right ear. > =20 > Since a sending endpoint has a camera associated with each display, an = association is made between the receiving stream output on a particular = display and the corresponding sending stream from the camera associated = with that display. These associations are repeated for each = display/camera pair in a meeting. The result of this system is a = horizontal arrangement of video images from remote sites, one per = display. The image from each display is paired with the camera output = from the camera above that display resulting in excellent eye contact. > =20 > =20 > =20 > Best Regards, > =20 > Mark Gorzynski > HP Visual Collaboration > =20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail-48-473471783 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1

(I work on a product which = fits this use case). 

Peter = Musgrave

On 2011-05-11, at 9:18 PM, Gorzynski, = Mark E (The Right One) wrote:

 
 
 
  ).  The use case = is illustrated in figure 2-5 of their report.  Today, the use case = is implemented in multiple telepresence type video conferencing systems = on the market.  The term =93virtual space=94 was used in their = report.  The main difference between the result obtained with = modern systems and those from 1983 are larger display = sizes.
 
Virtual space = multipoint as defined here assumes endpoints with multiple cameras and = displays.  Usually there are the same number of cameras and = displays at a given endpoint.  A camera is positioned above each = display.  A key aspect of virtual space multipoint is the details = of how the cameras are aimed.  The cameras are each aimed on the = same area of view of the participants at the site.  Thus each = camera takes a picture of the same set of people but from a different = angle.  Each endpoint sender in the virtual space multipoint = meeting therefore offers a choice of video streams to remote receivers, = each stream representing a different view point.  For example a = camera positioned above a display to a participant=92s left may take = video pictures of the participant=92s left ear while at the same time, a = camera positioned above a display to the participant=92s right may take = video pictures of the participant=92s right ear.
Since a sending endpoint has a = camera associated with each display, an association is made between the = receiving stream output on a particular display and the corresponding = sending stream from the camera associated with that display.  These = associations are repeated for each display/camera pair in a = meeting.  The result of this system is a horizontal arrangement of = video images from remote sites, one per display.  The image from = each display is paired with the camera output from the camera above that = display resulting in excellent eye contact.
 
Best Regards,
Mark Gorzynski
HP Visual = Collaboration
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAACCqvgA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> From: To: , , , X-OriginalArrivalTime: 12 May 2011 11:55:22.0335 (UTC) FILETIME=[79068EF0:01CC109B] Subject: Re: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 11:55:28 -0000 Are we sure that the values currently defined in RFC4796 are sufficient = to cover all TP scenarios? If, not we may have to issue an RFC to create = new values as I noticed that the registration policy for new values is = 'Specification Required'. We may indeed conclude that some of the requirements are already = fulfilled and do not require further standardization work but I don't = see this as a problem. BC > -----Message d'origine----- > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de > Elwell, John > Envoy=E9=A0: jeudi 12 mai 2011 10:00 > =C0=A0: Allyn Romanow (allyn); CAZEAUX Stephane RD-BIZZ-CAE; = clue@ietf.org > Objet=A0: Re: [clue] Commentson draft-romanow-clue-telepresence- > requirements-02 >=20 > > > We could add a requirement for the solution to support a means of > > > describing the role of streams (e.g. whether a media stream > > corresponds > > > to a speaker image or to presentation slides). > [JRE] I am concerned about adding requirements for which we appear to > have solutions already, unless those solutions are inappropriate or > need to be extended for use in a telepresence environment. In this > particular case, we already have the SDP a=3Dcontent attribute (RFC = 4796), > so it is unclear to me what else we would need. >=20 > > > > Yes, this is information that it would be good to send - I > > think this is covered in Reqmt 4. > [JRE] REQMT-4 is very vague (as I think has been mentioned before), so > it probably needs to be tightened up. However, the role of streams is > something I think we already have a solution for, so does not need to > be mentioned in a reworded REQMT-4. >=20 > John > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john.elwell@siemens-enterprise.com Thu May 12 05:36:45 2011 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 C3C43E06BE for ; Thu, 12 May 2011 05:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 nmnuvGl4kf-V for ; Thu, 12 May 2011 05:36:41 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 63D3BE067A for ; Thu, 12 May 2011 05:36:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1305203794!36704606!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9362 invoked from network); 12 May 2011 12:36:34 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-21.messagelabs.com with SMTP; 12 May 2011 12:36:34 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C0D6D23F03E9; Thu, 12 May 2011 14:36:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 12 May 2011 14:36:39 +0200 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "allyn@cisco.com" , "stephane.cazeaux@orange-ftgroup.com" , "clue@ietf.org" Date: Thu, 12 May 2011 14:36:38 +0200 Thread-Topic: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAACCqvgAABZq+g Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102DA2BB1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102DA2BB1@ftrdmel0.rd.francetelecom.fr> 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 Subject: Re: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 12:36:45 -0000 Bruno, No, I am not sure the values already standardized are sufficient, but I am = trying to tease out whether the requirement is about RFC 4796 or something = else entirely. Also, if it is about RFC 4796, whether there is some telepre= sence-specific requirement that might give rise to the need for more standa= rdized values. Although the proposed requirement does little harm, there is= little point in overloading the list of requirements with irrelevances. John =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 12 May 2011 12:55 > To: Elwell, John; allyn@cisco.com;=20 > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > Subject: RE: [clue] Commentson=20 > draft-romanow-clue-telepresence-requirements-02 >=20 > Are we sure that the values currently defined in RFC4796 are=20 > sufficient to cover all TP scenarios? If, not we may have to=20 > issue an RFC to create new values as I noticed that the=20 > registration policy for new values is 'Specification Required'. >=20 > We may indeed conclude that some of the requirements are=20 > already fulfilled and do not require further standardization=20 > work but I don't see this as a problem. >=20 > BC >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 > De la part de > > Elwell, John > > Envoy=E9=A0: jeudi 12 mai 2011 10:00 > > =C0=A0: Allyn Romanow (allyn); CAZEAUX Stephane RD-BIZZ-CAE;=20 > clue@ietf.org > > Objet=A0: Re: [clue] Commentson draft-romanow-clue-telepresence- > > requirements-02 > >=20 > > > > We could add a requirement for the solution to support=20 > a means of > > > > describing the role of streams (e.g. whether a media stream > > > corresponds > > > > to a speaker image or to presentation slides). > > [JRE] I am concerned about adding requirements for which we=20 > appear to > > have solutions already, unless those solutions are inappropriate or > > need to be extended for use in a telepresence environment. In this > > particular case, we already have the SDP a=3Dcontent=20 > attribute (RFC 4796), > > so it is unclear to me what else we would need. > >=20 > > > > > > Yes, this is information that it would be good to send - I > > > think this is covered in Reqmt 4. > > [JRE] REQMT-4 is very vague (as I think has been mentioned=20 > before), so > > it probably needs to be tightened up. However, the role of=20 > streams is > > something I think we already have a solution for, so does=20 > not need to > > be mentioned in a reworded REQMT-4. > >=20 > > John > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From stewe@stewe.org Thu May 12 08:32:07 2011 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 E27F0E06AF for ; Thu, 12 May 2011 08:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ENi--S+FDsct for ; Thu, 12 May 2011 08:32:07 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id F25C2E0706 for ; Thu, 12 May 2011 08:32:05 -0700 (PDT) Received: from [192.168.13.185] (unverified [94.90.92.250]) by stewe.org (SurgeMail 3.9e) with ESMTP id 560-1743317 for ; Thu, 12 May 2011 17:32:03 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 12 May 2011 17:31:59 -0700 From: Stephan Wenger To: CLUE Message-ID: Thread-Topic: Definitions Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388066323_9743788" X-Originating-IP: 94.90.92.250 X-Authenticated-User: stewe@stewe.org Subject: [clue] Definitions 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, 12 May 2011 15:32:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388066323_9743788 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, We discussed and agreed (to the extent an interim meeting can agree) that 1. Where there is a definition commonly understood the industry or in IETF standardization (or, where no such definition is available, a definition commonly understood in industry), we follow the this definition. 2. All definitions will be moved to from any other CLUE document to a definitions document. Stephan to put together =AD00 draft in short order. Did I get this right? Comments? Stephan --B_3388066323_9743788 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,

We discussed and agreed (to the extent an interim meeting can agree) that

1. Where there is a definition commonly un= derstood the industry or in IETF standardization (or, where no such definiti= on is available, a definition commonly understood in industry), we follow th= e this definition.
2. All definitions will be moved to= from any other CLUE document to a definitions document.  Stephan to pu= t together –00 draft in short order.

=
Did I get this right?  Comments?
=

Stephan

--B_3388066323_9743788-- From mark.gorzynski@hp.com Thu May 12 08:52:31 2011 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 10F8FE06F6 for ; Thu, 12 May 2011 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MS3RHcFNXNuG for ; Thu, 12 May 2011 08:52:30 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id A6746E06A3 for ; Thu, 12 May 2011 08:52:28 -0700 (PDT) Received: from G5W0603.americas.hpqcorp.net (g5w0603.americas.hpqcorp.net [16.228.9.186]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id CB3E7C802 for ; Thu, 12 May 2011 15:52:27 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G5W0603.americas.hpqcorp.net (16.228.9.186) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 12 May 2011 15:51:51 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Thu, 12 May 2011 15:51:51 +0000 From: "Gorzynski, Mark E (The Right One)" To: CLUE Date: Thu, 12 May 2011 15:51:45 +0000 Thread-Topic: Definitions Thread-Index: AcwQug70QDOrFTAbQWmlhGmLQyK/BQAAhq8A Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6AF90E2@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6AF90E2GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions 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, 12 May 2011 15:52:31 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF90E2GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with 1. 2. is as I heard. My main concern is that one term is defined in one worki= ng document with one editor. Mark Gorzynski HP From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Thursday, May 12, 2011 5:32 PM To: CLUE Subject: [clue] Definitions Hi, We discussed and agreed (to the extent an interim meeting can agree) that 1. Where there is a definition commonly understood the industry or in IETF = standardization (or, where no such definition is available, a definition co= mmonly understood in industry), we follow the this definition. 2. All definitions will be moved to from any other CLUE document to a defin= itions document. Stephan to put together -00 draft in short order. Did I get this right? Comments? Stephan --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF90E2GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree wit= h 1.

 

2. is as I heard.  My main concern = is that one term is defined in one working document with one editor.  =

 <= /p>

Mark Gorzynski

HP

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] <= b>On Behalf Of Stephan Wenger
Sent: Thursday, May 12, 2011 5:= 32 PM
To: CLUE
Subject: [clue] Definitions

 

Hi,

 

We d= iscussed and agreed (to the extent an interim meeting can agree) that<= /o:p>

 

1. Where there is a definition commonly understood the ind= ustry or in IETF standardization (or, where no such definition is available= , a definition commonly understood in industry), we follow the this definit= ion.

2. All definitions will be moved to = from any other CLUE document to a definitions document.  Stephan to pu= t together –00 draft in short order.

 

Did I ge= t this right?  Comments?

 

 

Stephan=

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF90E2GVW1096EXBame_-- From eckelcu@cisco.com Thu May 12 09:06:59 2011 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 A16B3E0751 for ; Thu, 12 May 2011 09:06:59 -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 qkhPtACGU36R for ; Thu, 12 May 2011 09:06:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C080BE07A1 for ; Thu, 12 May 2011 09:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1865; q=dns/txt; s=iport; t=1305216415; x=1306426015; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pbad+lyQBhiU8Ffb4gPC7ngvmxL6uVIziGv/JXl3vvI=; b=jxJrbLdiSEvlUJXq0KzZWSZOdmTGhcLgVTO1ebWVf1PWu6w97v5Nryuc QBHe5tINxARBVJBoK/L0smEhmNLjHqSSxwJwGOrlw2ij6wfUWgl0Yv7CZ N9KoDjQ1rCqPSaSmFZl6NUWsPvfFyeP3TD92R8ZlXb2TZINPT7YmLy7T1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAM0EzE2rRDoI/2dsb2JhbACXQI44d6kyniSGFQSGSY1jilg X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208";a="355744631" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 May 2011 16:06:55 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4CG6tKD014177; Thu, 12 May 2011 16:06:55 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 09:06:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 09:06:53 -0700 Message-ID: In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6AF90E2@GVW1096EXB.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions Thread-Index: AcwQug70QDOrFTAbQWmlhGmLQyK/BQAAhq8AAABseXA= References: <4168915E16BA9E47972F4A4B4EE3228276B6AF90E2@GVW1096EXB.americas.hpqcorp.net> From: "Charles Eckel (eckelcu)" To: "Gorzynski, Mark E (The Right One)" , "CLUE" X-OriginalArrivalTime: 12 May 2011 16:06:55.0261 (UTC) FILETIME=[9D1C4CD0:01CC10BE] Subject: Re: [clue] Definitions 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, 12 May 2011 16:06:59 -0000 I agree with Mark. Starting with a definitions document is fine with me. Later, as suggested by Paul, we can move this into another document if that seems appropriate. If someone needs to define a new term for a new document that is not already defined in the document that contains the rest of our definitions, we would ideally add it to the document with the rest of the definitions. Alternatively, as long as it is not defined elsewhere and is specific to the new document, I would be okay with defining it is the new document. We can make the call on such cases if/as they arise. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gorzynski, Mark E (The Right > One) > Sent: Thursday, May 12, 2011 8:52 AM > To: CLUE > Subject: Re: [clue] Definitions >=20 > Agree with 1. >=20 >=20 >=20 > 2. is as I heard. My main concern is that one term is defined in one working document with one > editor. >=20 >=20 >=20 > Mark Gorzynski >=20 > HP >=20 >=20 >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger > Sent: Thursday, May 12, 2011 5:32 PM > To: CLUE > Subject: [clue] Definitions >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > We discussed and agreed (to the extent an interim meeting can agree) that >=20 >=20 >=20 > 1. Where there is a definition commonly understood the industry or in IETF standardization (or, where > no such definition is available, a definition commonly understood in industry), we follow the this > definition. >=20 > 2. All definitions will be moved to from any other CLUE document to a definitions document. Stephan > to put together -00 draft in short order. >=20 >=20 >=20 > Did I get this right? Comments? >=20 >=20 >=20 >=20 >=20 > Stephan >=20 >=20 From eckelcu@cisco.com Thu May 12 09:12:21 2011 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 CA189E068E for ; Thu, 12 May 2011 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 sok3xmMiTPrE for ; Thu, 12 May 2011 09:12:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 19E32E0659 for ; Thu, 12 May 2011 09:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1641; q=dns/txt; s=iport; t=1305216738; x=1306426338; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7+l+1qer+PLBRq1+BnrIOzGe0Ee0xbRuki69MwYmhJw=; b=fs22v6yiHpf/5Dw2WRRgpWDEAmckWd1gKB41hbZb7CprdPjQnGKrHHtp glHE2rpSaLq1epuOn2XI2HJarwaZMagCKBcr4tzkz3zgjZG36pwoG0KIy SG5QqKVxfvbe9s8LAMIct/gKuoCLWVmi7mBe+OOxY/+zNSugowakYVmm+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAO8FzE2rRDoG/2dsb2JhbACXQI44d6kjniOGFQSGSY1jilg X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208";a="696373620" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 12 May 2011 16:12:17 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4CGCHHD012557; Thu, 12 May 2011 16:12:17 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 09:12:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 09:12:15 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAAEWfn0A== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Allyn Romanow (allyn)" , , X-OriginalArrivalTime: 12 May 2011 16:12:17.0257 (UTC) FILETIME=[5D08FD90:01CC10BF] Subject: Re: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 16:12:21 -0000 Please see inline. > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, May 12, 2011 1:00 AM > To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > Subject: Re: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 >=20 > > > We could add a requirement for the solution to support a means of > > > describing the role of streams (e.g. whether a media stream > > corresponds > > > to a speaker image or to presentation slides). > [JRE] I am concerned about adding requirements for which we appear to have solutions already, unless > those solutions are inappropriate or need to be extended for use in a telepresence environment. In > this particular case, we already have the SDP a=3Dcontent attribute = (RFC 4796), so it is unclear to me > what else we would need. That is true, and I think that is an important thing to keep in mind for the solution. The requirement seems valid to me, and hopefully we ultimately meet the requirement by using RFC 4796. Cheers, Charles > > > > Yes, this is information that it would be good to send - I > > think this is covered in Reqmt 4. > [JRE] REQMT-4 is very vague (as I think has been mentioned before), so it probably needs to be > tightened up. However, the role of streams is something I think we already have a solution for, so > does not need to be mentioned in a reworded REQMT-4. >=20 > John > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john.elwell@siemens-enterprise.com Thu May 12 09:16:10 2011 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 325F3E068E for ; Thu, 12 May 2011 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 h7EhuDlDmAHh for ; Thu, 12 May 2011 09:16:08 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 658BDE0659 for ; Thu, 12 May 2011 09:16:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1305216960!24908847!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 24282 invoked from network); 12 May 2011 16:16:00 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-3.tower-27.messagelabs.com with SMTP; 12 May 2011 16:16:00 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id BF1E31EB83ED; Thu, 12 May 2011 18:16:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 12 May 2011 18:16:06 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Allyn Romanow (allyn)" , "stephane.cazeaux@orange-ftgroup.com" , "clue@ietf.org" Date: Thu, 12 May 2011 18:16:04 +0200 Thread-Topic: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAAEWfn0AAAK7Lw Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Commentson draft-romanow-clue-telepresence-requirements-02 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, 12 May 2011 16:16:10 -0000 =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 12 May 2011 17:12 > To: Elwell, John; Allyn Romanow (allyn);=20 > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > Subject: RE: [clue] Commentson=20 > draft-romanow-clue-telepresence-requirements-02 >=20 > Please see inline. >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Elwell, John > > Sent: Thursday, May 12, 2011 1:00 AM > > To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; > clue@ietf.org > > Subject: Re: [clue] Commentson > draft-romanow-clue-telepresence-requirements-02 > >=20 > > > > We could add a requirement for the solution to support=20 > a means of > > > > describing the role of streams (e.g. whether a media stream > > > corresponds > > > > to a speaker image or to presentation slides). > > [JRE] I am concerned about adding requirements for which we=20 > appear to > have solutions already, unless > > those solutions are inappropriate or need to be extended=20 > for use in a > telepresence environment. In > > this particular case, we already have the SDP a=3Dcontent=20 > attribute (RFC > 4796), so it is unclear to me > > what else we would need. >=20 > That is true, and I think that is an important thing to keep=20 > in mind for > the solution. The requirement seems valid to me, and hopefully we > ultimately meet the requirement by using RFC 4796. [JRE] This seems reasonable to me - if we think there is a chance we might = want something different from or an extension of RFC 4796, it does no harm = to have the requirement. John >=20 > Cheers, > Charles >=20 > > > > > > Yes, this is information that it would be good to send - I > > > think this is covered in Reqmt 4. > > [JRE] REQMT-4 is very vague (as I think has been mentioned=20 > before), so > it probably needs to be > > tightened up. However, the role of streams is something I think we > already have a solution for, so > > does not need to be mentioned in a reworded REQMT-4. > >=20 > > John > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From eckelcu@cisco.com Thu May 12 09:17:04 2011 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 1B7F9E068E for ; Thu, 12 May 2011 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 lHHtFKhMms1E for ; Thu, 12 May 2011 09:16:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id EB56DE071E for ; Thu, 12 May 2011 09:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2614; q=dns/txt; s=iport; t=1305217019; x=1306426619; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dprR08bxUB5PZaVKtBfHQ85iSMK6A36y3rotkYXbn4M=; b=lCLLjr7D3wRUbZsf75r9SUd/TK0XNyKn6x4XWYg7MP62TyNYLNaFo75D xSNmKIxp0eX7mPp4diFChTOwV7vSUWoIES0JjyyGxveA5T368GC6CmHsm 2s1bzbPn8ylPg9z727k/h20eLwwjVrtHkHWqJWKzSmX7D53OPHA6r0L/p I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAL4GzE2rRDoI/2dsb2JhbACXQI44d6kdniSGFQSGSY1jilg X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208";a="446601984" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 12 May 2011 16:16:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4CGGtWb024944; Thu, 12 May 2011 16:16:55 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 09:16:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 09:16:53 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQAALI+RAAEUwXYA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , , "Allyn Romanow (allyn)" , , X-OriginalArrivalTime: 12 May 2011 16:16:54.0847 (UTC) FILETIME=[027DDCF0:01CC10C0] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 12 May 2011 16:17:04 -0000 +1 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Elwell, John > Sent: Thursday, May 12, 2011 1:02 AM > To: bruno.chatras@orange-ftgroup.com; Allyn Romanow (allyn); = stephane.cazeaux@orange-ftgroup.com; > Even.roni@huawei.com > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > +1 >=20 > John >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of bruno.chatras@orange-ftgroup.com > > Sent: 12 May 2011 07:50 > > To: allyn@cisco.com; stephane.cazeaux@orange-ftgroup.com; > > Even.roni@huawei.com > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > Hi, > > > > From previous discussions on the mailing list and at IETF#80 > > I understood that =AB non-standards compliant =BB was referring > > to solutions that make use of proprietary extensions (e.g. > > proprietary extensions to SDP or RTCP) while "legacy support" > > was referring to standard compliant solutions that do not > > understand the extensions that CLUE will specify (or request > > other groups to specify). The charter does not exclude the > > second case and Req# 10 is not specific enough. From the > > current text, one could understand that Req#10 applies to > > clue-compliant devices (i.e. devices that understand > > clue-defined extensions) with different capabilities, not to > > devices that do not understand clue extensions... > > > > BC > > > > > > > > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De > > la part de Allyn Romanow (allyn) > > Envoy=E9 : jeudi 12 mai 2011 03:20 > > =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > > Cc : CLUE > > Objet : [clue] legacy support in requirements > > > > > > > > Hi, > > > > You both asked to add a requirement for legacy support. > > However, the charter says > > > > > > > > "Interoperation with SIP and related standards for audio and > > video is required. However, backwards compatibility with existing > > non-standards compliant telepresence systems is not required." > > > > > > > > On the basis of this, I think it would not be a good > > requirement to add. However, there is a requirement, 10, that > > addresses making it possible for endpoints with varying > > capabilities to interoperate in a telepresence conference. > > > > > > > > Regards, > > > > Allyn > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mark.gorzynski@hp.com Thu May 12 09:18:49 2011 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 8A0E7E068E for ; Thu, 12 May 2011 09:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 s+h347YYY+bj for ; Thu, 12 May 2011 09:18:45 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 209F5E0671 for ; Thu, 12 May 2011 09:18:45 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 3A9062C1E3 for ; Thu, 12 May 2011 16:18:44 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 16:17:22 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Thu, 12 May 2011 16:17:21 +0000 From: "Gorzynski, Mark E (The Right One)" To: "clue@ietf.org" Date: Thu, 12 May 2011 16:17:15 +0000 Thread-Topic: [clue] virtual space (multi-view) use case Thread-Index: AcwQlDFd0ozUFjRMRBWjLypDevz0EwAKxRDw Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6AF9139@GVW1096EXB.americas.hpqcorp.net> References: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> <4C60EB16-F097-417C-AA75-C0397D0052E7@magorcorp.com> In-Reply-To: <4C60EB16-F097-417C-AA75-C0397D0052E7@magorcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6AF9139GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] virtual space (multi-view) use case 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, 12 May 2011 16:18:49 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF9139GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also should make it clear that the "virtual space" use case below DOES NO= T cover multiview displays. This is also a reason why I used a term like "= virtual space" rather than multiview. There already are definitions for multiview and 3D/Stereo. If we define a = multiview display as a display that produces different images when viewed f= rom different angles. I am NOT covering use of these displays in this use = case. The use case below assumes standard single view displays where "single view= " means the display produces one image regardless of viewing angle. Further, I am assuming that multiview displays are not within scope of a fi= rst output of CLUE but realize this may not be what others understand. We = should be clear on this scope because it would have strong impact on the wo= rk. Regards, Mark. Mark Gorzynski HP From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Thursday, May 12, 2011 4:03 AM To: Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: Re: [clue] virtual space (multi-view) use case +1 (I work on a product which fits this use case). Peter Musgrave On 2011-05-11, at 9:18 PM, Gorzynski, Mark E (The Right One) wrote: Greetings, It occurs to me that one use case commonly represented in products on the m= arket today may not have been fully described. It has been referred to as = a "multi-view" use case since it deals with cameras at different viewpoints= aimed at the same area of an endpoint. However we use the term "virtual s= pace" for this use case since it has been called by this name in the litera= ture (see below). 1. Virtual Space Multipoint This use case describes a virtual space multipoint video meeting with good = eye contact and spatial layout of participants. The use case was proposed = very early in the development of video conferencing systems as described in= 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738 ). = The use case is illustrated in figure 2-5 of their report. Today, the use = case is implemented in multiple telepresence type video conferencing system= s on the market. The term "virtual space" was used in their report. The m= ain difference between the result obtained with modern systems and those fr= om 1983 are larger display sizes. Virtual space multipoint as defined here assumes endpoints with multiple ca= meras and displays. Usually there are the same number of cameras and displ= ays at a given endpoint. A camera is positioned above each display. A key= aspect of virtual space multipoint is the details of how the cameras are a= imed. The cameras are each aimed on the same area of view of the participa= nts at the site. Thus each camera takes a picture of the same set of peopl= e but from a different angle. Each endpoint sender in the virtual space mu= ltipoint meeting therefore offers a choice of video streams to remote recei= vers, each stream representing a different view point. For example a camer= a positioned above a display to a participant's left may take video picture= s of the participant's left ear while at the same time, a camera positioned= above a display to the participant's right may take video pictures of the = participant's right ear. Since a sending endpoint has a camera associated with each display, an asso= ciation is made between the receiving stream output on a particular display= and the corresponding sending stream from the camera associated with that = display. These associations are repeated for each display/camera pair in a= meeting. The result of this system is a horizontal arrangement of video i= mages from remote sites, one per display. The image from each display is p= aired with the camera output from the camera above that display resulting i= n excellent eye contact. Best Regards, Mark Gorzynski HP Visual Collaboration _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF9139GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also sh= ould make it clear that the “virtual space” use case below DOES= NOT cover multiview displays.  This is also a reason why I used a ter= m like “virtual space” rather than multiview.=

 

There already are definitions for multiview and 3D/Stereo.&nbs= p; If we define a multiview display as a display that produces different im= ages when viewed from different angles.  I= am NOT covering use of these displays in this use case.

 

The use case below assumes standard single view displays wh= ere “single view” means the display produces one image regardle= ss of viewing angle.

 

Further, I am assuming = that multiview displays are not within scope of a first output of CLUE but = realize this may not be what others understand.  We should be clear on= this scope because it would have strong impact on the work.

 

Regards, Mark.

 

Mark Gorzynski=

HP

<= p class=3DMsoNormal> 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Thurs= day, May 12, 2011 4:03 AM
To: Gorzynski, Mark E (The Right One)Cc: clue@ietf.org
Subject: Re: [clue] virtual space (mul= ti-view) use case

 

+1

 

(I work on a pr= oduct which fits this use case). 

 

Peter Musgra= ve

 

=

On 2011-05-11, at 9:18 PM, Gorzynski, Mark E (The= Right One) wrote:



Greetings,

=

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>It occur= s to me that one use case commonly represented in products on the market to= day may not have been fully described.  It has been referred to as a &= #8220;multi-view” use case since it deals with cameras at different v= iewpoints aimed at the same area of an endpoint.  However we use the t= erm “virtual space” for this use case since it has been called = by this name in the literature (see below).

 

= 1. Virtual Space Multipoint

 

This use case describes a virtual space multipoint vi= deo meeting with good eye contact and spatial layout of participants. = The use case was proposed very early in the development of video conferenc= ing systems as described in 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738  ).  The use ca= se is illustrated in figure 2-5 of their report.  Today, the use case = is implemented in multiple telepresence type video conferencing systems on = the market.  The term “virtual space” was used in their re= port.  The main difference between the result obtained with modern sys= tems and those from 1983 are larger display sizes.

= Virtual space multipoint as defined here assumes endpoints with multiple ca= meras and displays.  Usually there are the same number of cameras and = displays at a given endpoint.  A camera is positioned above each displ= ay.  A key aspect of virtual space multipoint is the details of how th= e cameras are aimed.  The cameras are each aimed on the same area of v= iew of the participants at the site.  Thus each camera takes a picture= of the same set of people but from a different angle.  Each endpoint = sender in the virtual space multipoint meeting therefore offers a choice of= video streams to remote receivers, each stream representing a different vi= ew point.  For example a camera positioned above a display to a partic= ipant’s left may take video pictures of the participant’s left = ear while at the same time, a camera positioned above a display to the part= icipant’s right may take video pictures of the participant’s ri= ght ear.

 

<= /div>= --_000_4168915E16BA9E47972F4A4B4EE3228276B6AF9139GVW1096EXBame_-- From mark.gorzynski@hp.com Thu May 12 09:47:21 2011 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 BE6ACE068E for ; Thu, 12 May 2011 09:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 2uRFjbBny-5O for ; Thu, 12 May 2011 09:47:21 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 149FBE0682 for ; Thu, 12 May 2011 09:47:20 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 8EC8524515 for ; Thu, 12 May 2011 16:47:20 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 12 May 2011 16:46:44 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Thu, 12 May 2011 16:46:43 +0000 From: "Gorzynski, Mark E (The Right One)" To: CLUE Date: Thu, 12 May 2011 16:46:38 +0000 Thread-Topic: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 Thread-Index: AcwP+ZZPHbJ9ZsRxTtOfaSizjWVsCAAyjRig Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6AF918F@GVW1096EXB.americas.hpqcorp.net> References: <41F80411E3CC644A844E6BED6E472FD91AEA73C97B@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <41F80411E3CC644A844E6BED6E472FD91AEA73C97B@ESESSCMS0363.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 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, 12 May 2011 16:47:21 -0000 I think support for multi-view displays (multi-view, 3D, freeview, etc) sho= uld be optional not mandatory for CLUE. I believe the requirements from Mr. Karlsson would demand a fairly=20 extensive increase in complexity as they would require establishing=20 spatial support such as camera viewing angle and mapping spatial audio to video window position. While this type of support is understandable and even desirable, I=20 believe many systems would consider this as optional, not mandatory. Mark. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Erl= endur Karlsson Sent: Wednesday, May 11, 2011 9:37 AM To: Allyn Romanow (allyn) Cc: CLUE Subject: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Ca= pture Description - Reqm 1, 2 and 3 Hi, I and some of my colleages have looked over the Spatial Capture Description= Requirements (1,2 and 3) and we have some comments and suggestions on thos= e. These requirements mandate means of describing spatial arrangements of vide= o images and audio signals, but there is no mention of what particular func= tionality they should enable or support. Due to this any spatial arrangemen= t description will automatically fulfill the requirements, irrespective of = what functionality it will support. To make these requirements meaningful w= e feel that they need to be complemented with some description of the funct= ionality they are intended to support.=20 One issue we have regards spatial audio capture and rendering. We feel that= it is important to support the capture of several spatial audio sources in= the same space (media stream and position in space) and that there is supp= ort for sending those spatial positions to the rendering instances. In the = case where these spatial audio sources are associated with a video capture,= it is also important to support the positioning of the audio sources in th= e x-y plain of the associated video window as this will make it possible to= properly align the the rendered audio scene with the rendered video scene. Another issue regards video capture of the same object from multiple captur= e angles and rendering of such video images on multiview screens. It is imp= ortant for an endpoint with multiview screens to be able to obtain or evalu= ate the capture angles of the different video captures of the same object, = so that it can display the different video images at the appropriate viewin= g angles. =20 Below we have some suggestions on how requirements 1, 2 amd 3 could be comp= lemented with relevant functionality support descriptions. REQMT-1: The solution MUST support a means of describing the spatial arrangement of source video images sent in video streams in such a way that: - a client with a rendering layout that matches the particul= ar=20 capture layout is able to render the video images in a spa= tially correct manner. - it is possible to make a spatially correct composite video= image=20 of several of the video images. - a client with multiview screens is able to obtain or evalu= ate the capture=20 angles of video images that capture the same visual object= from=20 different angles. REQMT-2: The solution MUST support a means of describing the spatial arrangement of source audio sounds sent in audio streams in such a way that:=20 - a client with an audio rendering layout that matches the=20 particular audio capture layout is able to render the audi= o=20 in a spatially correct manner. - it supports the spatial capture of several audio sources i= n the same space=20 with a spatial position for each source. REQMT-3: The solution MUST support a mechanism to allow spatial matching of audio and video streams from the same endpoints such that: - rendering clients are able to correctly position audio sou= rces=20 associated with a video image in the image plane of the re= ndered=20 video window. - spatial audio sources associated with a video image can be= positioned=20 in the x-y plane of the associated video window. Kind regards, Erlendur Karlsson _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Thu May 12 09:59:14 2011 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 B8A1CE06C3 for ; Thu, 12 May 2011 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, SARE_SUB_OBFU_Q1=0.227] 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 FGEivVxVoKgu for ; Thu, 12 May 2011 09:59:14 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA94E069E for ; Thu, 12 May 2011 09:59:13 -0700 (PDT) Received: from [192.168.13.185] (unverified [94.90.92.250]) by stewe.org (SurgeMail 3.9e) with ESMTP id 587-1743317 for multiple; Thu, 12 May 2011 18:59:12 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 12 May 2011 18:59:02 -0700 From: Stephan Wenger To: "Gorzynski, Mark E (The Right One)" , CLUE Message-ID: Thread-Topic: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6AF918F@GVW1096EXB.americas.hpqcorp.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 94.90.92.250 X-Authenticated-User: stewe@stewe.org Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 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, 12 May 2011 16:59:14 -0000 Hi Mark, Are you sure that you are not mixing up requirements of specification with requirements of implementation? At this point, we are not necessarily discussing levels mandation of an implementation. I think it is totally OK to say that a "solution" (which is: a future set of RFCs) MUST address a certain problem, but the "solution" makes the support by products optional. Stephan On 5.12.2011 09:46 , "Gorzynski, Mark E (The Right One)" wrote: >I think support for multi-view displays (multi-view, 3D, freeview, etc) >should be optional not mandatory for CLUE. > >I believe the requirements from Mr. Karlsson would demand a fairly >extensive increase in complexity as they would require establishing >spatial support such as camera viewing angle and >mapping spatial audio to video window position. > >While this type of support is understandable and even desirable, I >believe many systems would consider this as optional, not mandatory. > > >Mark. > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Erlendur Karlsson >Sent: Wednesday, May 11, 2011 9:37 AM >To: Allyn Romanow (allyn) >Cc: CLUE >Subject: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial >Capture Description - Reqm 1, 2 and 3 > >Hi, > >I and some of my colleages have looked over the Spatial Capture >Description Requirements (1,2 and 3) and we have some comments and >suggestions on those. > >These requirements mandate means of describing spatial arrangements of >video images and audio signals, but there is no mention of what >particular functionality they should enable or support. Due to this any >spatial arrangement description will automatically fulfill the >requirements, irrespective of what functionality it will support. To make >these requirements meaningful we feel that they need to be complemented >with some description of the functionality they are intended to support. > >One issue we have regards spatial audio capture and rendering. We feel >that it is important to support the capture of several spatial audio >sources in the same space (media stream and position in space) and that >there is support for sending those spatial positions to the rendering >instances. In the case where these spatial audio sources are associated >with a video capture, it is also important to support the positioning of >the audio sources in the x-y plain of the associated video window as this >will make it possible to properly align the the rendered audio scene with >the rendered video scene. > >Another issue regards video capture of the same object from multiple >capture angles and rendering of such video images on multiview screens. >It is important for an endpoint with multiview screens to be able to >obtain or evaluate the capture angles of the different video captures of >the same object, so that it can display the different video images at the >appropriate viewing angles. > >Below we have some suggestions on how requirements 1, 2 amd 3 could be >complemented with relevant functionality support descriptions. > > > REQMT-1: The solution MUST support a means of describing the > spatial arrangement of source video images sent in video > streams in such a way that: > - a client with a rendering layout that matches the >particular > capture layout is able to render the video images in a >spatially > correct manner. > - it is possible to make a spatially correct composite >video image > of several of the video images. > - a client with multiview screens is able to obtain or >evaluate the capture > angles of video images that capture the same visual >object from > different angles. > > > REQMT-2: The solution MUST support a means of describing the > spatial arrangement of source audio sounds sent in audio > streams in such a way that: > - a client with an audio rendering layout that matches the > particular audio capture layout is able to render the >audio > in a spatially correct manner. > - it supports the spatial capture of several audio sources >in the same space > with a spatial position for each source. > > REQMT-3: The solution MUST support a mechanism to allow spatial > matching of audio and video streams from the same > endpoints such that: > - rendering clients are able to correctly position audio >sources > associated with a video image in the image plane of the >rendered > video window. > - spatial audio sources associated with a video image can >be positioned > in the x-y plane of the associated video window. > > > >Kind regards, > >Erlendur Karlsson >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From mark.gorzynski@hp.com Thu May 12 10:04:33 2011 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 9FC2AE0730 for ; Thu, 12 May 2011 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 nrO6yKKZegnY for ; Thu, 12 May 2011 10:04:32 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9E82AE070A for ; Thu, 12 May 2011 10:04:32 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id C5DF3380CB; Thu, 12 May 2011 17:04:31 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 12 May 2011 17:03:56 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Thu, 12 May 2011 17:03:54 +0000 From: "Gorzynski, Mark E (The Right One)" To: Stephan Wenger , CLUE Date: Thu, 12 May 2011 17:03:49 +0000 Thread-Topic: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 Thread-Index: AcwQxe+AoaH2eTZAQUSUw+xRPP22aQAADoEg Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6AF91BD@GVW1096EXB.americas.hpqcorp.net> References: <4168915E16BA9E47972F4A4B4EE3228276B6AF918F@GVW1096EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: Spatial Capture Description - Reqm 1, 2 and 3 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, 12 May 2011 17:04:33 -0000 Perhaps, good point. I am concerned about the complexity of including specification support for = multi-view. My concern is about specification not implementation. I ask us to be clear whether specification support for multi-view / 3D is c= ritical now in CLUE. Mark -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Thursday, May 12, 2011 6:59 PM To: Gorzynski, Mark E (The Right One); CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-02: Spatia= l Capture Description - Reqm 1, 2 and 3 Hi Mark, Are you sure that you are not mixing up requirements of specification with = requirements of implementation? At this point, we are not necessarily discussing levels mandation of an imp= lementation. I think it is totally OK to say that a "solution" (which is: a future set of RFCs) MUST address a certain problem, but the "solution= " makes the support by products optional. Stephan On 5.12.2011 09:46 , "Gorzynski, Mark E (The Right One)" wrote: >I think support for multi-view displays (multi-view, 3D, freeview, etc)=20 >should be optional not mandatory for CLUE. > >I believe the requirements from Mr. Karlsson would demand a fairly=20 >extensive increase in complexity as they would require establishing=20 >spatial support such as camera viewing angle and mapping spatial audio=20 >to video window position. > >While this type of support is understandable and even desirable, I=20 >believe many systems would consider this as optional, not mandatory. > > >Mark. > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of=20 >Erlendur Karlsson >Sent: Wednesday, May 11, 2011 9:37 AM >To: Allyn Romanow (allyn) >Cc: CLUE >Subject: [clue] draft-romanow-clue-telepresence-requirements-02:=20 >Spatial Capture Description - Reqm 1, 2 and 3 > >Hi, > >I and some of my colleages have looked over the Spatial Capture=20 >Description Requirements (1,2 and 3) and we have some comments and=20 >suggestions on those. > >These requirements mandate means of describing spatial arrangements of=20 >video images and audio signals, but there is no mention of what=20 >particular functionality they should enable or support. Due to this any=20 >spatial arrangement description will automatically fulfill the=20 >requirements, irrespective of what functionality it will support. To=20 >make these requirements meaningful we feel that they need to be=20 >complemented with some description of the functionality they are intended = to support. > >One issue we have regards spatial audio capture and rendering. We feel=20 >that it is important to support the capture of several spatial audio=20 >sources in the same space (media stream and position in space) and that=20 >there is support for sending those spatial positions to the rendering=20 >instances. In the case where these spatial audio sources are associated=20 >with a video capture, it is also important to support the positioning=20 >of the audio sources in the x-y plain of the associated video window as=20 >this will make it possible to properly align the the rendered audio=20 >scene with the rendered video scene. > >Another issue regards video capture of the same object from multiple=20 >capture angles and rendering of such video images on multiview screens. >It is important for an endpoint with multiview screens to be able to=20 >obtain or evaluate the capture angles of the different video captures=20 >of the same object, so that it can display the different video images=20 >at the appropriate viewing angles. > >Below we have some suggestions on how requirements 1, 2 amd 3 could be=20 >complemented with relevant functionality support descriptions. > > > REQMT-1: The solution MUST support a means of describing the > spatial arrangement of source video images sent in video > streams in such a way that: > - a client with a rendering layout that matches the=20 >particular > capture layout is able to render the video images in a=20 >spatially > correct manner. > - it is possible to make a spatially correct composite=20 >video image > of several of the video images. > - a client with multiview screens is able to obtain or=20 >evaluate the capture > angles of video images that capture the same visual=20 >object from > different angles. > > > REQMT-2: The solution MUST support a means of describing the > spatial arrangement of source audio sounds sent in audio > streams in such a way that: > - a client with an audio rendering layout that matches the > particular audio capture layout is able to render the=20 >audio > in a spatially correct manner. > - it supports the spatial capture of several audio=20 >sources in the same space > with a spatial position for each source. > > REQMT-3: The solution MUST support a mechanism to allow spatial > matching of audio and video streams from the same > endpoints such that: > - rendering clients are able to correctly position audio=20 >sources > associated with a video image in the image plane of=20 >the rendered > video window. > - spatial audio sources associated with a video image=20 >can be positioned > in the x-y plane of the associated video window. > > > >Kind regards, > >Erlendur Karlsson >_______________________________________________ >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 bbaldino@cisco.com Thu May 12 10:04:36 2011 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 608E0E077F for ; Thu, 12 May 2011 10:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPTxQ-adQLKw for ; Thu, 12 May 2011 10:04:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 74803E06DD for ; Thu, 12 May 2011 10:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=10079; q=dns/txt; s=iport; t=1305219875; x=1306429475; h=mime-version:subject:date:message-id:from:to; bh=Bf/WfEc7vJPi5d+z5ZZHTdBmNYe0fKEIWoYIBNPMI1w=; b=LXFTjJR+tyRDTAKnLgSr9J8dZbVHM7NcL/+I4aZIlx6eaFSLpNcWEMI3 OboysAIFVV2q2/LQPh+doM00mS9lokE9dsacjionyIeTrAnZmeI6qM9pb H3EX/Ifa40bRXr8aclbJjl8MaHZpnxyhh6maT8jjxHu/gMK6vcufGlgr3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIHAN0SzE2rRDoJ/2dsb2JhbACCZJUcjXh3qFyBHZ4phhUEhkmNY4pY X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208,217";a="355793567" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 12 May 2011 17:04:35 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4CH4ZuX023133 for ; Thu, 12 May 2011 17:04:35 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 10:04:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC10C6.AACE4324" Date: Thu, 12 May 2011 10:04:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notes: 5/12/11 Thread-Index: AcwQxqoMDcYQhA4TStitT0xAc3vIZA== From: "Brian Baldino (bbaldino)" To: X-OriginalArrivalTime: 12 May 2011 17:04:35.0060 (UTC) FILETIME=[AB4FBB40:01CC10C6] Subject: [clue] Notes: 5/12/11 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, 12 May 2011 17:04:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC10C6.AACE4324 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Definitions Where to put definitions? Single place? In each document? Putting them in each document would require them to be kept in sync. -->Definitions should be from the viewpoint of the user in the room ('left camera' =3D left camera in the room) -->Stephan Wenger will create a separate document just to maintain definitions =20 Requirements -->Go through requirements document and match it against the new definitions doc to make sure everything lines up Too abstract? Should 4 be dropped? Requirement 4 is 'session level' and requirement 7 is 'media level'? -->Requirements 4 and 5 will refer to 'endpoint characteristics' which will be defined in the doc -->Requirement 7 made more specific -->Evolve requirements with the document, clean requirements document up in terms of making things that should be specific are specific and things that should be more broad are broad How specific should requirements be? Where does the line get drawn between requirements and solution? =20 Requirement 15: Mobile-type clients would prefer that mixing is done by the far end, so there should be a way for a client to request such a stream (pre-mixed) -->No problem with requiring that such a request should be able to made as long as it's not a requirement that it has to be fulfilled (far end must always be able to mix) -->Further discussion will continue between Allyn, Stephan, Steve Botzko and Ericsson team (who proposed the change) ------_=_NextPart_001_01CC10C6.AACE4324 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Definitions

    Where to put definitions?  Single place?  In each = document?  Putting them in each document would require them to be kept in = sync.

    -->Definitions should be from the viewpoint of the user in the room = ('left camera' =3D left camera in the room)

    -->Stephan Wenger will create a separate document just to maintain definitions

 

Requirements

    -->Go through requirements document and match it against the new = definitions doc to make sure everything lines up

    Too abstract?  Should 4 be dropped?

    Requirement 4 is 'session level' and requirement 7 is 'media = level'?

    -->Requirements 4 and 5 will refer to 'endpoint characteristics' = which will be defined in the doc

    -->Requirement 7 made more specific

    -->Evolve requirements with the document, clean requirements document = up in terms of making things that should be specific are specific and things = that should be more broad are broad

    How specific should requirements be?  Where does the line get drawn between requirements and solution?

 

    Requirement 15: Mobile-type clients would prefer that mixing is done by = the far end, so there should be a way for a client to request such a stream = (pre-mixed)

    -->No problem with requiring that such a request should be able to = made as long as it's not a requirement that it has to be fulfilled (far end must = always be able to mix)

    -->Further discussion will continue between Allyn, Stephan, Steve = Botzko and Ericsson team (who proposed the change)

------_=_NextPart_001_01CC10C6.AACE4324-- From mary.ietf.barnes@gmail.com Thu May 12 12:31:35 2011 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 A229FE07CE for ; Thu, 12 May 2011 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 o+RwLqmZCNAo for ; Thu, 12 May 2011 12:31:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98B9AE07CB for ; Thu, 12 May 2011 12:31:34 -0700 (PDT) Received: by vws12 with SMTP id 12so1645366vws.31 for ; Thu, 12 May 2011 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=cC+heWqxTVs0m5eChD+xFXNSiBGBl8EzB3w1vc3J0aY=; b=EnnQNt3EmNDG+i/oE7ydmYdlhkcw33IdKGFmepp0S3rkKecYLo6wcJCk4vj8ul1dI+ NPVhio81cS9rRAQ+QdG+iqgEHjprZB3D1Ty9VVeDxf8PliBg+Kl/vFrOmxzkONRscGIt yU1Lu0gwb7RtC51n9axlPgk3tKzfd8dJ8tZFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bgX1vggA1pdnttdWPMzBIqTaUZdaumS7pgJi5BuKje2RZnKxgZDAQimvmyIP00DIOw +vX70EIdAdoZhxMrY+XliwnF6cN6hWFQMHUXLU8rtyISQ9pmnLquAUeTjULqKjYYO9LQ 64XD8FussIJz67fFng9ztxZoYLwBp+LU9tfyI= MIME-Version: 1.0 Received: by 10.52.96.9 with SMTP id do9mr822926vdb.263.1305228693525; Thu, 12 May 2011 12:31:33 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Thu, 12 May 2011 12:31:33 -0700 (PDT) Date: Thu, 12 May 2011 14:31:33 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d0662a0d6ca04a3193ce8 Subject: [clue] Recording "CLUE-20110512 1537-1" from the Interim meeting is 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, 12 May 2011 19:31:35 -0000 --20cf307d0662a0d6ca04a3193ce8 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I goofed and didn't start the recording until 30 minutes into the meeting. However, this should capture the meat of the discussion. We'll get the combined notes out on the wiki soon. Regards, Mary. ---------- Forwarded message ---------- From: Alexa Morris Date: Thu, May 12, 2011 at 1:35 PM Subject: Fwd: Your recording "CLUE-20110512 1537-1" is available for viewing To: Mary Barnes Begin forwarded message: *From: *messenger@webex.com *Date: *May 12, 2011 10:41:00 AM PDT *To: *amorris@amsl.com *Subject: **Your recording "CLUE-20110512 1537-1" is available for viewing* *Reply-To: *messenger@webex.com IETF Secretariat, Your recording is now available on the WebEx service site. Click the link below to play it: https://workgreen.webex.com/workgreen/lsr.php?AT=pb&SP=MC&rID=9805772&rKey=1512177fd7dfac98 CLUE-20110512 1537-1 Thursday, May 12, 2011 8:37 am San Francisco Time 1 Hour 27 Minutes * You can forward this message to others to allow them to play back the recording. * ------------------------------------- Additional Options ------------------------------------- To edit recording information and playback control options, click the link below: https://workgreen.webex.com/workgreen/editrd.php?rID=9805772&SP=MC To view more options for this recording, such as downloading, click the link below: https://workgreen.webex.com/workgreen/viewrd.php?rID=9805772&SP=MC To view all your WebEx Meeting Center recordings, click the link below: https://workgreen.webex.com/workgreen/servicerds.php?SP=MC http://www.webex.com ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com --20cf307d0662a0d6ca04a3193ce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I goofed and didn't start the recording un= til 30 minutes into the meeting. =A0However, this should capture the meat o= f the discussion.

We'll get the combined notes= out on the wiki soon.

Regards,
Mary.=A0

---------- Forwarded message ----------
From: Alexa Morris <amorris@amsl.com>
Date: Thu, May 12, 2011 at 1:35 PM
Subject: Fwd: Your recording "CL= UE-20110512 1537-1" is available for viewing
To: Mary Barnes <mary.ietf.barnes@gmail.com&= gt;




Begin forward= ed message:

Date: May 12, 2011 10:41:00 AM PDT
Subject: Your recording "CLUE= -20110512 1537-1" is available for viewing

IETF Secretariat,

Your recording is now available on the WebEx service site. Click the = link below to play it:

https://workgreen.webex.com/workgreen/lsr.php?AT= =3Dpb&SP=3DMC&rID=3D9805772&rKey=3D1512177fd7dfac98

CLUE-20110512 1537-1
Thursday, May 12, 2011 8:37 am San Francisc= o Time
1 Hour 27 Minutes

* You can forward this message to o= thers to allow them to play back the recording. *

---------------= ----------------------
Additional Options
-------------------------------------

To= edit recording information and playback control options, click the link be= low:
https://workgreen.webex.com/workg= reen/editrd.php?rID=3D9805772&SP=3DMC

To view more options for this recording, such as downloading, click t= he link below:
https://workgreen.webex.c= om/workgreen/viewrd.php?rID=3D9805772&SP=3DMC

To view all your WebEx Meeting Center recordings, click the link belo= w:
https://workgreen.webex.com/workgreen/servicerds.p= hp?SP=3DMC

http://www.webex.c= om

-----------
Alexa Morris / Executive Director / IETF
48377 Fremo= nt Blvd., Suite 117, Fremont, CA =A094538
Phone: +1.510.492.4089 / F= ax: +1.510.492.4001
Email:=A0amorris@amsl= .com

Managed by Association Management Solutions (AMS)
Forum = Management, Meeting and Event Planning
www.amsl.com=A0<http://www.amsl.com/>


--20cf307d0662a0d6ca04a3193ce8-- From allyn@cisco.com Thu May 12 17:02:49 2011 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 4C1F3E065A for ; Thu, 12 May 2011 17:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 gHCMATNXl9ZD for ; Thu, 12 May 2011 17:02:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5C723E067C for ; Thu, 12 May 2011 17:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4111; q=dns/txt; s=iport; t=1305244968; x=1306454568; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vTMPPnVX62Q4NG8cGzMkbN0m9cLwOHLXjpk64fq2osU=; b=YKKfg3BuiLIMkK/duj8IphWPr0qrxe/yUdv0QtolWPWYjOZ8QFjfCy6h I/UegxTBJtaen55pvc3hrgZ9xtKarZ9AaA4fu4ZJ8dY83fTt7N/Wfvdwm sYx4SoJSSrp9TM2BZUlm280ZMGLXwaEzDsUlAhDZ+UCDSZOWOX5yLv9I7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABABl0zE2rRDoJ/2dsb2JhbACXQY44d4hwoHeeFYYVBIZKjWOKWA X-IronPort-AV: E=Sophos;i="4.64,361,1301875200"; d="scan'208";a="696649387" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 13 May 2011 00:02:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4D02lqI017391; Fri, 13 May 2011 00:02:47 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 17:01:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 17:01:52 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0458412E@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the nature of requirements Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAACCqvgAABZq+gABfGi3A= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102DA2BB1@ftrdmel0.rd.francetelecom.fr> From: "Allyn Romanow (allyn)" To: "Elwell, John" , , , X-OriginalArrivalTime: 13 May 2011 00:01:54.0498 (UTC) FILETIME=[F7FAC220:01CC1100] Subject: [clue] the nature of requirements 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, 13 May 2011 00:02:49 -0000 Hi John and all, A similar thing came up during the interim today.. whether requirements = are supposed to only be about functionality that is not already included = in existing IETF protocols? I guess this is the difference between a user group trying to solve a = problem and experts in RAI intimately aware of all the problems that = have already been solved and the mechanisms available for implementing = functionality. I am concerned that if you consider requirements in light of what can = and cannot be accomplished with the usual RAI protocols, that you are in = danger of not focusing on the problem and overly constraining the = solution prematurely. I think that we must of course consider how to = implement the solution (when we have it) with existing RAI standards. But, you may see it differently? Thanks, Allyn . > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 12, 2011 5:37 AM > To: bruno.chatras@orange-ftgroup.com; Allyn Romanow (allyn); > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > Subject: RE: [clue] Commentsondraft-romanow-clue-telepresence- > requirements-02 >=20 > Bruno, >=20 > No, I am not sure the values already standardized are sufficient, but = I > am trying to tease out whether the requirement is about RFC 4796 or > something else entirely. Also, if it is about RFC 4796, whether there > is some telepresence-specific requirement that might give rise to the > need for more standardized values. Although the proposed requirement > does little harm, there is little point in overloading the list of > requirements with irrelevances. >=20 > John >=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 12 May 2011 12:55 > > To: Elwell, John; allyn@cisco.com; > > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > > Subject: RE: [clue] Commentson > > draft-romanow-clue-telepresence-requirements-02 > > > > Are we sure that the values currently defined in RFC4796 are > > sufficient to cover all TP scenarios? If, not we may have to > > issue an RFC to create new values as I noticed that the > > registration policy for new values is 'Specification Required'. > > > > We may indeed conclude that some of the requirements are > > already fulfilled and do not require further standardization > > work but I don't see this as a problem. > > > > BC > > > > > > > > > > > -----Message d'origine----- > > > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > De la part de > > > Elwell, John > > > Envoy=E9=A0: jeudi 12 mai 2011 10:00 > > > =C0=A0: Allyn Romanow (allyn); CAZEAUX Stephane RD-BIZZ-CAE; > > clue@ietf.org > > > Objet=A0: Re: [clue] Commentson draft-romanow-clue-telepresence- > > > requirements-02 > > > > > > > > We could add a requirement for the solution to support > > a means of > > > > > describing the role of streams (e.g. whether a media stream > > > > corresponds > > > > > to a speaker image or to presentation slides). > > > [JRE] I am concerned about adding requirements for which we > > appear to > > > have solutions already, unless those solutions are inappropriate = or > > > need to be extended for use in a telepresence environment. In this > > > particular case, we already have the SDP a=3Dcontent > > attribute (RFC 4796), > > > so it is unclear to me what else we would need. > > > > > > > > > > > Yes, this is information that it would be good to send - I > > > > think this is covered in Reqmt 4. > > > [JRE] REQMT-4 is very vague (as I think has been mentioned > > before), so > > > it probably needs to be tightened up. However, the role of > > streams is > > > something I think we already have a solution for, so does > > not need to > > > be mentioned in a reworded REQMT-4. > > > > > > John > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > From john.elwell@siemens-enterprise.com Thu May 12 23:10:06 2011 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 BA17AE06AC for ; Thu, 12 May 2011 23:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.187 X-Spam-Level: X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 BKUmEiydtZ4v for ; Thu, 12 May 2011 23:10:02 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 2C1B4E0657 for ; Thu, 12 May 2011 23:10:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1305266995!23602891!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 27881 invoked from network); 13 May 2011 06:09:55 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-27.messagelabs.com with SMTP; 13 May 2011 06:09:55 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 90FCC1EB83D3; Fri, 13 May 2011 08:10:00 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 13 May 2011 08:10:00 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , "bruno.chatras@orange-ftgroup.com" , "stephane.cazeaux@orange-ftgroup.com" , "clue@ietf.org" Date: Fri, 13 May 2011 08:10:00 +0200 Thread-Topic: the nature of requirements Thread-Index: AcwP5LQDD9+rE4NGTCWyrWazQSMDIgAQTAZgABTc5IAACCqvgAABZq+gABfGi3AADUC4EA== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583CBC@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102DA2BB1@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0458412E@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0458412E@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] the nature of requirements 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, 13 May 2011 06:10:06 -0000 Allyn, I have already indicated (in response to Charles) that I don't object to ad= ding this particular requirement. Of course, you have to draw the line some= where, and avoid flooding the document with lots of requirements that are a= lready met by existing protocols, thereby masking the "real" requirements. = If there is some doubt as to whether this requirement is already sufficient= ly met, I am happy to include it. Part of the reason for my original commen= t was to tease out what the proposer really meant, and whether it is indeed= similar to what is addressed by RFC 4796. John=20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: 13 May 2011 01:02 > To: Elwell, John; bruno.chatras@orange-ftgroup.com;=20 > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > Subject: the nature of requirements >=20 > Hi John and all, > A similar thing came up during the interim today.. whether=20 > requirements are supposed to only be about functionality that=20 > is not already included in existing IETF protocols? >=20 > I guess this is the difference between a user group trying to=20 > solve a problem and experts in RAI intimately aware of all=20 > the problems that have already been solved and the mechanisms=20 > available for implementing functionality. >=20 > I am concerned that if you consider requirements in light of=20 > what can and cannot be accomplished with the usual RAI=20 > protocols, that you are in danger of not focusing on the=20 > problem and overly constraining the solution prematurely. I=20 > think that we must of course consider how to implement the=20 > solution (when we have it) with existing RAI standards. >=20 > But, you may see it differently? >=20 > Thanks, > Allyn >=20 > . >=20 >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, May 12, 2011 5:37 AM > > To: bruno.chatras@orange-ftgroup.com; Allyn Romanow (allyn); > > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > > Subject: RE: [clue] Commentsondraft-romanow-clue-telepresence- > > requirements-02 > >=20 > > Bruno, > >=20 > > No, I am not sure the values already standardized are=20 > sufficient, but I > > am trying to tease out whether the requirement is about RFC 4796 or > > something else entirely. Also, if it is about RFC 4796,=20 > whether there > > is some telepresence-specific requirement that might give=20 > rise to the > > need for more standardized values. Although the proposed requirement > > does little harm, there is little point in overloading the list of > > requirements with irrelevances. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 12 May 2011 12:55 > > > To: Elwell, John; allyn@cisco.com; > > > stephane.cazeaux@orange-ftgroup.com; clue@ietf.org > > > Subject: RE: [clue] Commentson > > > draft-romanow-clue-telepresence-requirements-02 > > > > > > Are we sure that the values currently defined in RFC4796 are > > > sufficient to cover all TP scenarios? If, not we may have to > > > issue an RFC to create new values as I noticed that the > > > registration policy for new values is 'Specification Required'. > > > > > > We may indeed conclude that some of the requirements are > > > already fulfilled and do not require further standardization > > > work but I don't see this as a problem. > > > > > > BC > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > > De la part de > > > > Elwell, John > > > > Envoy=E9=A0: jeudi 12 mai 2011 10:00 > > > > =C0=A0: Allyn Romanow (allyn); CAZEAUX Stephane RD-BIZZ-CAE; > > > clue@ietf.org > > > > Objet=A0: Re: [clue] Commentson draft-romanow-clue-telepresence- > > > > requirements-02 > > > > > > > > > > We could add a requirement for the solution to support > > > a means of > > > > > > describing the role of streams (e.g. whether a media stream > > > > > corresponds > > > > > > to a speaker image or to presentation slides). > > > > [JRE] I am concerned about adding requirements for which we > > > appear to > > > > have solutions already, unless those solutions are=20 > inappropriate or > > > > need to be extended for use in a telepresence=20 > environment. In this > > > > particular case, we already have the SDP a=3Dcontent > > > attribute (RFC 4796), > > > > so it is unclear to me what else we would need. > > > > > > > > > > > > > > Yes, this is information that it would be good to send - I > > > > > think this is covered in Reqmt 4. > > > > [JRE] REQMT-4 is very vague (as I think has been mentioned > > > before), so > > > > it probably needs to be tightened up. However, the role of > > > streams is > > > > something I think we already have a solution for, so does > > > not need to > > > > be mentioned in a reworded REQMT-4. > > > > > > > > John > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > = From stewe@stewe.org Fri May 13 02:08:06 2011 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 E8E95E069A for ; Fri, 13 May 2011 02:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396] 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 SA8qAvkuGNOg for ; Fri, 13 May 2011 02:08:06 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE94E067B for ; Fri, 13 May 2011 02:08:05 -0700 (PDT) Received: from [192.168.13.185] (unverified [94.90.92.246]) by stewe.org (SurgeMail 3.9e) with ESMTP id 822-1743317 for ; Fri, 13 May 2011 11:08:04 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 13 May 2011 11:07:54 -0700 From: Stephan Wenger To: CLUE Message-ID: Thread-Topic: Definitions Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3388129683_12462306" X-Originating-IP: 94.90.92.246 X-Authenticated-User: stewe@stewe.org Subject: [clue] Definitions 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, 13 May 2011 09:08:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388129683_12462306 Content-type: multipart/alternative; boundary="B_3388129683_12432347" --B_3388129683_12432347 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi folks, Here a VERY rough initial draft. Addressing typos, sorting to alphabetical, and other cleanup tasks will have to wait for the my return to the office next week. I will submit officially only after the most embarrassing bugs are sorted out. No need to comment on typos, but if you have substantial issues then send them now, and I can address them immediately. Stephan --B_3388129683_12432347 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi folks,
Here a V= ERY rough initial draft.  Addressing typos, sorting to alphabetical, an= d other cleanup tasks will have to wait for the my return to the office next= week.  I will submit officially only after the most embarrassing bugs = are sorted out.  No need to comment on typos, but if you have substanti= al issues then send them now, and I can address them immediately.
= Stephan

--B_3388129683_12432347-- --B_3388129683_12462306 Content-type: text/plain; name="draft-wenger-clue-definitions-00-00.txt" Content-disposition: attachment; filename="draft-wenger-clue-definitions-00-00.txt" Content-transfer-encoding: base64 CgoKQ0xVRSBXRyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUy4gV2VuZ2VyCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWaWR5bywgSW5jLgpJbnRlbmRlZCBzdGF0 dXM6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkgMTMs IDIwMTEKRXhwaXJlczogTm92ZW1iZXIgMTQsIDIwMTEKCgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ0xVRSBEZWZpbml0aW9ucwogICAgICAgICAgICAgICAgICBkcmFmdC13ZW5n ZXItY2x1ZS1kZWZpbml0aW9ucy0wMC50eHQKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50 IGNvbGxlY3RzIHRlcm1pbm9sb2d5IGFuZCBkZWZpbml0aW9ucyB0byBiZSB1c2VkCiAgIGNv bnNpc3RlbnRseSBhbW9uZyBkb2N1bWVudHMgcHJvZHVjZWQgaW4gdGhlIENMVUUgd29ya2lu ZyBncm91cC4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg aXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9u cyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2Ug KElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAg IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gTm92ZW1iZXIgMTQsIDIwMTEuCgpDb3B5cmlnaHQgTm90aWNlCgogICBD b3B5cmlnaHQgKGMpIDIwMTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmll ZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVz dCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAg KGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2 aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91 ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBh cmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNp bXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKCgoKCldlbmdlciAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMTQsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBDTFVFIERlZmluaXRpb25zICAgICAgICAgICAgICAg ICAgICBNYXkgMjAxMQoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9u ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMK ICAgMi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzCiAgIDMuICBEZWZpbml0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICA0LiAgQWNrbm93bGVk Z2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDUKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA3LiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDUKICAgQXBwZW5kaXggQS4gIERyYWZ0IEhpc3RvcnkgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKV2VuZ2VyICAgICAgICAgICAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENMVUUgRGVmaW5pdGlvbnMgICAgICAgICAgICAg ICAgICAgIE1heSAyMDExCgoKMS4gIEludHJvZHVjdGlvbgoKICAgdCBUaGlzIGRvY3VtZW50 IGNvbGxlY3RzIHRlcm1pbm9sb2d5IGFuZCBkZWZpbml0aW9ucyB0byBiZSB1c2VkCiAgIGNv bnNpc3RlbnRseSBhbW9uZyBkb2N1bWVudHMgcHJvZHVjZWQgaW4gdGhlIENMVUUgd29ya2lu ZyBncm91cC4gIFRoZQogICBkcmFmdCBpcyBpbnRlbmRlZCB0byBiZSBhIGxpdmluZyBkb2N1 bWVudCwgdG8gYmUgdXBkYXRlZCBhcyB0aGUKICAgd29ya2luZyBncm91cCBkaXNjdXNzaW9u cyBwcm9ncmVzcy4gIEl0IGlzIG5vdCBpbnRlbmRlZCBmb3IKICAgcHVibGljYXRpb24gYXMg YW4gUkZDOyBpbnN0ZWFkLCBpdCBpcyBleHBlY3RlZCB0aGF0IGRlZmluaXRpb25zIGFuZAog ICB0ZXJtaW5vbG9neSBkZWZpbmVkIGhlcmVpbiBhcmUgZ29pbmcgdG8gYmUgcmVwbGljYXRl ZCBpbiBvdGhlciBDTFVFCiAgIGRvY3VtZW50cy4KCgoyLiAgVGVybWlub2xvZ3kKCiAgIFRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg Ik1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uCgoKMy4gIERl ZmluaXRpb25zCgogICAgICAgIEF1ZGlvIG1peGluZyAtIHJlZmVycyB0byB0aGUgYWNjdW11 bGF0aW9uIG9mIHNjYWxlZCBhdWRpbwogICAgICAgIHNpZ25hbHMgdG8gcHJvZHVjZSBhIHNp bmdsZSBhdWRpbyBzdHJlYW0uICBTZWUgUlRQIFRvcG9sb2dpZXMsCiAgICAgICAgW1JGQzUx MTddLgoKICAgICAgICBDYXB0dXJlIGRldmljZSAtIEEgZGV2aWNlIHRoYXQgY29udmVydHMg YXVkaW8gYW5kIHZpZGVvIGlucHV0CiAgICAgICAgaW50byBhbiBlbGVjdHJpY2FsIHNpZ25h bCwgaW4gbW9zdCBjYXNlcyB0byBiZSBmZWQgaW50byBhIG1lZGlhCiAgICAgICAgZW5jb2Rl ci4gIENhbWVyYXMgYW5kIG1pY3JvcGhvbmVzIGFyZSBleGFwbGVzIGZvciBjYXB0dXJlCiAg ICAgICAgZGV2aWNlcy4KCiAgICAgICAgUmVuZGVyaW5nIGRldmljZSAtIEEgZGV2aWNlIHRo YXQgY29udmVydHMgYW4gZWxlY3RyaWNhbCBzaWduYWwgLQogICAgICAgIGluIG1vc3QgY2Fz ZXMgc3RlbW1pbmcgZnJvbSBhIG1lZGlhIGRlY29kZXIgLSB0byBhdWRpYmxlIGFuZAogICAg ICAgIG9wdGljYWwgc2lnbmFscy4gIFNjcmVlbnMgYW5kIGxvdWRzcGVha2VycyBhcmUgZXhh bXBsZXMgZm9yCiAgICAgICAgcmVuZGVyaW5nIGRldmljZXMuCgogICAgICAgIENvbmZlcmVu Y2UgLSBkZWZpbmVkIGluIFtSRkM0MzUzXSwgQSBGcmFtZXdvcmsgZm9yIENvbmZlcmVuY2lu ZwogICAgICAgIHdpdGhpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp LgoKICAgICAgICBFbmRwb2ludCAtIFRoZSBsb2dpY2FsIHBvaW50IG9mIGZpbmFsIHRlcm1p bmF0aW9uIHRocm91Z2gKICAgICAgICByZWNlaXZpbmcsIGRlY29kaW5nIGFuZCByZW5kZXJp bmcsIGFuZC9vciBpbml0aWF0aW9uIHRocm91Z2gKICAgICAgICBjYXB0dXJpbmcsIGVuY29k aW5nLCBhbmQgc2VuZGluZyBvZiBtZWRpYSBzdHJlYW1zLiAgQW4gZW5kcG9pbnQKICAgICAg ICBjb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBwaHlzaWNhbCBkZXZpY2VzIHdoaWNoIHNvdXJj ZSBhbmQgc2luawogICAgICAgIG1lZGlhIHN0cmVhbXMuICBJbiBjb250cmFzdCB0byBhbiBl bmRwb2ludCwgYSBtaWRkbGUgYm94LCBzdWNoCiAgICAgICAgYXMgYW4gTUNVLCBtYXkgYWxz byBzZW5kIGFuZCByZWNlaXZlIG1lZGlhIHN0cmVhbXMsIGJ1dCBpdCBpcwogICAgICAgIG5v dCB0aGUgaW5pdGlhdG9yIG5vciB0aGUgZmluYWwgdGVybWluYXRvci4gIEVuZHBvaW50cyBj YW4gYmUKICAgICAgICBhbnl0aGluZyBmcm9tIG11bHRpc2NyZWVuL211bHRpY2FtZXJhIHJv b21zIHRvIGhhbmRoZWxkIGRldmljZXMuCgoKCgoKCldlbmdlciAgICAgICAgICAgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAzXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDTFVFIERlZmluaXRpb25zICAgICAgICAgICAg ICAgICAgICBNYXkgMjAxMQoKCiAgICAgICAgTGF5b3V0IC0gSG93IG1lZGlhIHN0cmVhbXMg YXJlIHNwYXRpYWxseSBhcnJhbmdlZCB3aXRoIHJlc3BlY3QKICAgICAgICB0byBlYWNoIG90 aGVyIG9uIGEgc2luZ2xlIHNjcmVlbi9tb25vIGF1ZGlvIHRlbGVwcmVzZW5jZQogICAgICAg IGVuZHBvaW50LCBhbmQgaG93IG1lZGlhIHN0cmVhbXMgYXJlIGFycmFuZ2VkIHdpdGggcmVz cGVjdCB0bwogICAgICAgIGVhY2ggb3RoZXIgb24gYSBtdWx0aXBsZSBzY3JlZW4vc3BlYWtl ciB0ZWxlcHJlc2VuY2UgZW5kcG9pbnQuCiAgICAgICAgTm90ZSB0aGF0IGF1ZGlvIGFzIHdl bGwgYXMgdmlkZW8gaXMgZW5jb21wYXNzZWQgYnkgdGhlIHRlcm0KICAgICAgICBsYXlvdXQt LWluIG90aGVyIHdvcmRzLCBpbmNsdWRlZCBpcyB0aGUgcGxhY2VtZW50IG9mIGF1ZGlvCiAg ICAgICAgc3RyZWFtcyBvbiBzcGVha2VycyBhcyB3ZWxsIGFzIHZpZGVvIHN0cmVhbXMgb24g dmlkZW8gc2NyZWVucy4KCiAgICAgICAgTWVkaWEgLSBBbnkgZGF0YSB0aGF0LCBhZnRlciBz dWl0YWJsZSBlbmNvZGluZywgY2FuIGJlIGNvbnZleWVkCiAgICAgICAgb3ZlciBSVFAsIGlu Y2x1ZGluZyBhdWRpbywgdmlkZW8gb3IgdGltZWQgdGV4dC4KCiAgICAgICAgTUNVIC0gTXVs dGlwb2ludCBDb250cm9sIFVuaXQgKE1DVSkgLSBhIGRldmljZSB0aGF0IGNvbm5lY3RzIHR3 bwogICAgICAgIG9yIG1vcmUgZW5kcG9pbnRzIHRvZ2V0aGVyIGludG8gb25lIHNpbmdsZSBt dWx0aW1lZGlhIGNvbmZlcmVuY2UKICAgICAgICBbUkZDNTExN10uCgogICAgICAgIFJlbW90 ZSAtIFNlbmRlciBvciByZWNlaXZlciBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUKICAgICAg ICBjb21tdW5pY2F0aW9uIGNoYW5uZWw7IG5vdCBsb2NhbC4gIEEgcmVtb3RlIGNhbiBiZSBh biBlbmRwb2ludAogICAgICAgIG9yIGFuIE1DVS4KCiAgICAgICAgUmVuZGVyIC0gdGhlIHBy b2Nlc3Mgb2YgZ2VuZXJhdGluZyBhIHJlcHJlc2VudGF0aW9uIGZyb20gYQogICAgICAgIG1l ZGlhLCBzdWNoIGFzIGRpc3BsYXllZCBtb3Rpb24gdmlkZW8gb3Igc291bmQgZW1pdHRlZCBm cm9tCiAgICAgICAgbG91ZHNwZWFrZXJzLgoKICAgICAgICBTZXNzaW9uIC0gUlRQIHNlc3Np b24uICBBbiBhc3NvY2lhdGlvbiBhbW9uZyBhIHNldCBvZgogICAgICAgIHBhcnRpY2lwYW50 cyBjb21tdW5pY2F0aW5nIHdpdGggUlRQLiAgVGhlIGRpc3Rpbmd1aXNoaW5nIGZlYXR1cmUK ICAgICAgICBvZiBhbiBSVFAgc2Vzc2lvbiBpcyB0aGF0IGVhY2ggbWFpbnRhaW5zIGEgZnVs bCwgc2VwYXJhdGUgc3BhY2UKICAgICAgICBvZiBTU1JDIGlkZW50aWZpZXJzLiAgW1JGQzM1 NTBdCgogICAgICAgIFNvdXJjZSBzZWxlY3Rpb24gcG9saWNpZXMgLSBydWxlcyBmb3IgZGV0 ZXJtaW5pbmcgd2hpY2ggbWVkaWEKICAgICAgICBzb3VyY2UocykgdG8gcGxheSBvciBzaG93 LgoKICAgICAgICBTcGF0aWFsIHJlbGF0aW9ucyAtIFRoZSBhcnJhbmdlbWVudCBpbiBzcGFj ZSBvZiBvYmplY3RzLCBpbgogICAgICAgIGNvbnRyYXN0IHRvIHJlbGF0aW9uIGluIHRpbWUg b3Igb3RoZXIgcmVsYXRpb25zaGlwcy4KCiAgICAgICAgVmlkZW8gY29tcG9zaXRlIC0gQSBz aW5nbGUgaW1hZ2UgdGhhdCBpcyBmb3JtZWQgZnJvbSBjb21iaW5pbmcKICAgICAgICB2aXN1 YWwgZWxlbWVudHMgZnJvbSBzZXBhcmF0ZSBzb3VyY2VzLgoKICAgICAgICBUZWxlcHJlc2Vu Y2UgLSBhbiBlbnZpcm9ubWVudCB0aGF0IGdpdmVzIG5vbiBjby1sb2NhdGVkIHVzZXJzIG9y CiAgICAgICAgdXNlciBncm91cHMgYSBmZWVsaW5nIG9mIChjby1sb2NhdGVkKSBwcmVzZW5j ZSAtIHRoZSBmZWVsaW5nCiAgICAgICAgdGhhdCBhIGxvY2FsIHVzZXIgaXMgaW4gdGhlIHNh bWUgcm9vbSB3aXRoIG90aGVyIGxvY2FsIHVzZXJzIGFuZAogICAgICAgIHRoZSByZW1vdGUg cGFydGllcy4gIFRoZSBpbmNsdXNpb24gb2YgcmVtb3RlIHBhcnRpZXMgaXMgYWNoaWV2ZWQK ICAgICAgICB0aHJvdWdoIG11bHRpbWVkaWEgY29tbXVuaWNhdGlvbiBpbmNsdWRpbmcgYXQg bGVhc3QgYXVkaW8gYW5kCiAgICAgICAgdmlkZW8gc2lnbmFscyBvZiBoaWdoIGZpZGVsaXR5 LgoKICAgICAgICBFbmRwb2ludCBDaGFyYWN0ZXJpc3RpY3MgLSBpbmNsdWRlIHBsYWNlbWVu dCBvZiBjYXB0dXJlIGFuZAogICAgICAgIHJlbmRlcmluZyBkZXZpY2VzLCBjYXB0dXJlL3Jl bmRlciBhbmdsZSwgcmVzb2x1dGlvbiBvZiBjYW1lcmFzCiAgICAgICAgYW5kIHNjcmVlbnMs IHNwYXRpYWwgbG9jYXRpb24gYW5kIG1peGluZyBwYXJhbWV0ZXJzIG9mCiAgICAgICAgbWlj cm9waG9uZXMuICBFbmRwb2ludCBjaGFyYWN0ZXJpc3RpY3MgYXJlIG5vdCBzcGVjaWZpYyB0 bwoKCgpXZW5nZXIgICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDEx ICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg Q0xVRSBEZWZpbml0aW9ucyAgICAgICAgICAgICAgICAgICAgTWF5IDIwMTEKCgogICAgICAg IGluZGljdWR1YWwgbWVkaWEgc3RyZWFtcyBzZW50IGJ5IHRoZSBlbmRwb2ludC4KCiAgICAg ICAgU3RyZWFtIENoYXJhY3RlcmlzdGljcyAtIGluY2x1ZGUgbWVkaWEgc3RyZWFtIGF0dHJp YnV0ZXMKICAgICAgICBjb21tb25seSB1c2VkIGluIG5vbi1DTFVFIFNJUC9TRFAgZW52aXJv bm1lbnRzIChzdWNoIGFzOiBtZWRpYQogICAgICAgIGNvZGVjLCBiaXRyYXRlLCByZXNvbHV0 aW9uLCBwcm9maWxlL2xldmVsIGV0Yy4pIGFzIHdlbGwgYXMgQ0xVRQogICAgICAgIHNwZWNp ZmljIGF0dHJpYnV0ZXMgKHdoaWNoIGNvdWxkIGluY2x1ZGUgZm9yIGV4YW1wbGUgYW5kCiAg ICAgICAgZGVwZW5kaW5nIG9uIHRoZSBzb2x1dGlvbiBmb3VuZDogdGhlIEktRCBvciBzcGF0 aWFsIGxvY2F0aW9uIG9mCiAgICAgICAgYSBjYXB0dXJlIGRldmljZSBhIHN0cmVhbSBvcmln aW5hdGVzIGZyb20pLgoKICAgICAgICBNb2RlbCAtIGEgc2V0IG9mIGFzc3VtcHRpb25zIGEg dGVsZXByZXNlbmNlIHN5c3RlbSBvZiBhIGdpdmVuCiAgICAgICAgdmVuZG9yIGFkaGVyZXMg dG8gYW5kIGV4cGVjdHMgdGhlIHJlbW90ZSB0ZWxlcHJlc2VuY2Ugc3lzdGVtKHMpCiAgICAg ICAgYWxzbyB0byBhZGhlcmUgdG8uCgoKNC4gIEFja25vd2xlZGdlbWVudHMKCiAgIE1vc3Qg b2YgdGhpcyBzdHVmZiBpcyBjb3BpZWQgZnJvbSB0aGUgQ0xVRSByZXF1aXJlbWVudHMgZHJh ZnQuICBHbwogICB0aGVyZSB0byBsb29rIGF0IGRpZ25pdGFyaWVzLgoKCjUuICBJQU5BIENv bnNpZGVyYXRpb25zCgogICBOb25lCgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgog ICBOb25lCgoKNy4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJh ZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2gg MTk5Ny4KCiAgIFtSRkM1MTE3XSAgV2VzdGVybHVuZCwgTS4gYW5kIFMuIFdlbmdlciwgIlJU UCBUb3BvbG9naWVzIiwgUkZDIDUxMTcsCiAgICAgICAgICAgICAgSmFudWFyeSAyMDA4LgoK ICAgW1JGQzM1NTBdICBTY2h1bHpyaW5uZSwgSC4sIENhc25lciwgUy4sIEZyZWRlcmljaywg Ui4sIGFuZCBWLgogICAgICAgICAgICAgIEphY29ic29uLCAiUlRQOiBBIFRyYW5zcG9ydCBQ cm90b2NvbCBmb3IgUmVhbC1UaW1lCiAgICAgICAgICAgICAgQXBwbGljYXRpb25zIiwgU1RE IDY0LCBSRkMgMzU1MCwgSnVseSAyMDAzLgoKICAgW1JGQzQzNTNdICBSb3NlbmJlcmcsIEou LCAiQSBGcmFtZXdvcmsgZm9yIENvbmZlcmVuY2luZyB3aXRoIHRoZQogICAgICAgICAgICAg IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSIsIFJGQyA0MzUzLAogICAgICAg ICAgICAgIEZlYnJ1YXJ5IDIwMDYuCgoKCgoKCldlbmdlciAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMTQsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBDTFVFIERlZmluaXRpb25zICAgICAgICAgICAgICAg ICAgICBNYXkgMjAxMQoKCkFwcGVuZGl4IEEuICBEcmFmdCBIaXN0b3J5CgogICAwMDogSW5p dGlhbCB2ZXJzaW9uOyBtb3N0bHkgY29weS1wYXN0IGZyb20gcmVxdWlyZW1lbnRzLTAyLgoK CkF1dGhvcidzIEFkZHJlc3MKCiAgIFN0ZXBoYW4gV2VuZ2VyCiAgIFZpZHlvLCBJbmMuCiAg IDQzMyBIYWNrZW5zYWNrIEF2ZS4sIDd0aCBGbG9vcgogICBIYWNrZW5zYWNrLCBOSiAgMDc2 MDEKICAgVVNBCgogICBFbWFpbDogc3Rld2VAc3Rld2Uub3JnCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpXZW5nZXIgICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDE0LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNl0KDAo= --B_3388129683_12462306-- From mary.ietf.barnes@gmail.com Fri May 13 12:54:04 2011 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 0F1D9E087B for ; Fri, 13 May 2011 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.098 X-Spam-Level: X-Spam-Status: No, score=-104.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 N3gLu3zbUjXj for ; Fri, 13 May 2011 12:54:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74129E087A for ; Fri, 13 May 2011 12:54:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so2473673vxg.31 for ; Fri, 13 May 2011 12:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=YsP3Zz3RBOWRsTtaM5xgfqpCqC0WhN1+tVQP8km2rbw=; b=iJf13eO0jj8uTMqU/rNXYtg0nrIV3gHdmygjVjU8IACXAb+Wg0BU7yBGOtSmUqtSIR 6zb1alWk35KzjB1vlgi5JYdf2dBdrVIvUZAchnK46ELnpKVugIFMlkQlSfFqWwCoekt/ bvTP5KTAAfxpg2aIRknP1rhbl0J1im0wGACB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=TA9IKP8qEDWnhXJLbWvNsVnNMTF78fVsT/R41VAUi8Fp7XMG8PpfyTDbub1+qhQjeq qbbn98uF4hYalPAbioiofJfiTPUSJkvMvxsLD6wUwdaSb2I145Ew+g0sQSxfuXYt/Ukx 0Rpn271gLsC6ghvm0txk13pag07bBcNJ/bTbM= MIME-Version: 1.0 Received: by 10.52.96.9 with SMTP id do9mr2620862vdb.263.1305316442749; Fri, 13 May 2011 12:54:02 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Fri, 13 May 2011 12:54:02 -0700 (PDT) Date: Fri, 13 May 2011 14:54:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d0662e3bd5204a32daa92 Subject: [clue] Notes from CLUE WG Interim - May 12, 2011 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, 13 May 2011 19:54:04 -0000 --20cf307d0662e3bd5204a32daa92 Content-Type: text/plain; charset=ISO-8859-1 HI folks, I have uploaded Brian Baldino and Paul Coverdale's notes from the meeting. Paul and I will use those, along with our own notes to produce the official meeting notes that will post shortly on the same page, which also includes a link to the email with all the details for accessing the recording. http://trac.tools.ietf.org/wg/clue/trac/wiki/Minutes-May-12-2011 Regards, Mary CLUE WG co-chair --20cf307d0662e3bd5204a32daa92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI folks,

I have uploaded Brian Baldino and Paul Coverda= le's notes from the meeting. =A0Paul and I will use those, along with o= ur own notes to produce the official meeting notes that will post shortly o= n the same page, which also includes a link to the email with all the detai= ls for accessing the recording.=A0



Regards,
Mary
CLUE WG co-chair
--20cf307d0662e3bd5204a32daa92-- From mary.ietf.barnes@gmail.com Fri May 13 13:27:47 2011 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 4BCF6E07DB for ; Fri, 13 May 2011 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.931 X-Spam-Level: X-Spam-Status: No, score=-103.931 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 3iojPqwW9wG5 for ; Fri, 13 May 2011 13:27:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76578E07D8 for ; Fri, 13 May 2011 13:27:46 -0700 (PDT) Received: by vws12 with SMTP id 12so2503005vws.31 for ; Fri, 13 May 2011 13:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=pXwNeyB752ArfUWfZUQXU+OOMS7inqT0QGaXGwxLWuQ=; b=LknW6BxVxNvF5mIutdNV82WuzK2wMFQShxBTHNB0G0eTo4HFh+bTDeriguEKwkVPxP z8ady29KR5UpVKYk9nJ4mBo6tUWz9xYrfvHIbmZx4bZ7DqPVjtJmZvkIZSL/cm4VqZoW pxRRzEE9Yz1f8AA27Lxxgc9O4CNNWtNNlPbsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=WXpzMxM/31hR7Tdr7uqYgFm/BYNeJ8uC4VjtsjpK9QQZwlWseyh47/DpeYiRLqbZNG khRUUPOEJ7jSPT01kdRE/Wb3pFQ+dZonREg5RWGrf0LDyiLJ9naKn6BzYmeQwBMK4ufZ 37k8qvOyRQTu0Pb9GDswVVCqW38i9Bo7K/4o8= MIME-Version: 1.0 Received: by 10.52.176.1 with SMTP id ce1mr63769vdc.63.1305318417254; Fri, 13 May 2011 13:26:57 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Fri, 13 May 2011 13:26:57 -0700 (PDT) Date: Fri, 13 May 2011 15:26:57 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec517a812944d1d04a32e2095 Subject: [clue] Doodle poll - Another CLUE WG interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 20:27:47 -0000 --bcaec517a812944d1d04a32e2095 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I've setup a doodle to determine a time for the next interim meeting as discussed on yesterday's call. I am proposing June 9th, 10th or 13th or June 23rd. If those dates don't work for the majority we can try some after that, but we want to have the meeting at least one month prior to the IETF meeting which limits us to June 23rd. Unfortunately, I am on vacation from the 14th-22nd. So, unless we want to have it earlier (if the doc editors are okay with that) or while I'm in vacation (Paul can certainly run the meeting - I just hate to miss anything ;), we are somewhat limited. If folks could please respond to the doodle by next Friday (May 20th) http://www.doodle.com/uxr58upmwc3783n7 that will allow us to make any necessary adjustments to the date and make the arrangements in time. Thanks, Mary CLUE WG co-chair --bcaec517a812944d1d04a32e2095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi folks,=A0

I've setup a doodle to determine a ti= me for the next interim meeting as discussed on yesterday's call. =A0I = am proposing June 9th, 10th or 13th or June 23rd. =A0If those dates don'= ;t work for the majority we can try some after that, but we want to have th= e meeting at least one month prior to the IETF meeting which limits us to J= une 23rd. =A0Unfortunately, I am on vacation from the 14th-22nd. =A0So, unl= ess we want to have it earlier (if the doc editors are okay with that) or w= hile I'm in vacation (Paul can certainly run the meeting - I just hate = to miss anything ;), we are somewhat limited.

If folks could please respond to the doodle by next Friday (May 20t= h)=A0h= ttp://www.doodle.com/uxr58upmwc3783n7
that will allow us to make any necessary adjustm= ents to the date and make the arrangements in time.=A0

Thanks,
Mary
CLUE WG co-chair


=A0


--bcaec517a812944d1d04a32e2095-- From Even.roni@huawei.com Sat May 14 23:54:33 2011 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 2449BE0681 for ; Sat, 14 May 2011 23:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 6pn2E4+Cieyp for ; Sat, 14 May 2011 23:54:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 09267E066C for ; Sat, 14 May 2011 23:54:31 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL800JNE5UQAP@szxga05-in.huawei.com> for clue@ietf.org; Sun, 15 May 2011 14:54:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL800CH95UQRN@szxga05-in.huawei.com> for clue@ietf.org; Sun, 15 May 2011 14:54:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-43-141.red.bezeqint.net [79.183.43.141]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL800IAG5UDEI@szxml12-in.huawei.com>; Sun, 15 May 2011 14:54:26 +0800 (CST) Date: Sun, 15 May 2011 09:52:48 +0300 From: Roni Even In-reply-to: To: 'Stephan Wenger' , 'CLUE' Message-id: <001901cc12cc$bc123540$34369fc0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+uRXVoin1CjTiRuBLHElzg)" Content-language: en-us Thread-index: AcwRTXYx0XEOqy2GSsKyiniTyBtDvgBeMS3A References: Subject: Re: [clue] Definitions 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, 15 May 2011 06:54:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+uRXVoin1CjTiRuBLHElzg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Stephan, I am missing the "left" "right" definition. I also think that it will be good to state that the definitions are from the viewpoint of the local user, this will mean that we have to say what is a local user. Regards Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Friday, May 13, 2011 9:08 PM To: CLUE Subject: [clue] Definitions Hi folks, Here a VERY rough initial draft. Addressing typos, sorting to alphabetical, and other cleanup tasks will have to wait for the my return to the office next week. I will submit officially only after the most embarrassing bugs are sorted out. No need to comment on typos, but if you have substantial issues then send them now, and I can address them immediately. Stephan --Boundary_(ID_+uRXVoin1CjTiRuBLHElzg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Stephan,

I am missing the "left" "right" definition.

I also think that it will be good to state that the definitions are from the viewpoint of the local user, this will mean that we have to say what is a local user.

Regards

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, May 13, 2011 9:08 PM
To: CLUE
Subject: [clue] Definitions

 

Hi folks,

Her aft.  Addressing typos, sorting to alphabetical, and other cleanup tasks will have to wait for the my return to the office next week.  I will submit officially only after the most embarrassing bugs are sorted out.  No need to comment on typos, but if you have substantial issues then send them now, and I can address them immediately.

Stephan

 

--Boundary_(ID_+uRXVoin1CjTiRuBLHElzg)-- From Even.roni@huawei.com Sun May 15 05:19:01 2011 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 8A4A3E0715 for ; Sun, 15 May 2011 05:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fI-0RBAg1zuD for ; Sun, 15 May 2011 05:19:00 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 80B91E06A0 for ; Sun, 15 May 2011 05:19:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL800GSRKVN5J@szxga03-in.huawei.com> for clue@ietf.org; Sun, 15 May 2011 20:18:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL80094ZKVNIG@szxga03-in.huawei.com> for clue@ietf.org; Sun, 15 May 2011 20:18:59 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-15-5.red.bezeqint.net [79.177.15.5]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL8005N6KVHP5@szxml11-in.huawei.com> for clue@ietf.org; Sun, 15 May 2011 20:18:59 +0800 (CST) Date: Sun, 15 May 2011 15:17:29 +0300 From: Roni Even To: 'CLUE' Message-id: <003c01cc12fa$13595f90$3a0c1eb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bogthcps2y3qVivRha8Nvg)" Content-language: en-us Thread-index: AcwS+g64s2M4j9XeQ5+T/4k3vwiYrQ== Subject: [clue] Requirements for endpoint characteristics 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, 15 May 2011 12:19:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bogthcps2y3qVivRha8Nvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, During the interim we discussed the issue of requirements for endpoint characteristics and stream characteristics. Looking at the use cases I noticed that in the case of point to point asymmetric in section 4.2 there are a couple of ways an endpoint with three screens (and cameras) can send video to a one screen system. Describing these options by the sender and selecting the right one by the receiver may be endpoint characteristics. BTW: I think that mixing all streams to one (as was suggested by req 15) is applicable to video and audio as can be seen in the 3 screen system sending 1 composite stream to the one screen system Roni --Boundary_(ID_bogthcps2y3qVivRha8Nvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

During the interim we discussed the issue of requirements for endpoint characteristics and stream characteristics.

Looking at the use cases I noticed that in the case of point to point asymmetric in section 4.2 there are a couple of ways an endpoint with three screens (and cameras) can send video to a one screen system. Describing these options by the sender and selecting the right one by the receiver may be  endpoint characteristics.

 

 

BTW: I think that mixing all streams to one (as was suggested by req 15) is applicable to video and audio as can be seen in the 3 screen system sending 1 composite stream to the one screen system

  ;< i

 

--Boundary_(ID_bogthcps2y3qVivRha8Nvg)-- From eckelcu@cisco.com Sun May 15 18:34:47 2011 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 A8BD2E06D6 for ; Sun, 15 May 2011 18:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 J4QNQnkUXTA2 for ; Sun, 15 May 2011 18:34:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id EC4C9E06B9 for ; Sun, 15 May 2011 18:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2415; q=dns/txt; s=iport; t=1305509686; x=1306719286; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=thsp5zAMkfCD59hicZbBCX/pSnWx4wfz6KCu7FqbPo4=; b=MAFt4q/n+R3LBuNuZ8OVUmxr7ldIGJc6r2RAHCLm9trpzk1QnhSlTAqg +4BF6womKj1/XZTkd4aW2vb5ehMRNppZmvW9wnFR81T+TNNE01POlb89V lpwJXiF6+v6QHDe+P0mjgAop2uBf8E0J2Vtm7HTKD3V9s51jzzDpeibw2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBAOF+0E2rRDoG/2dsb2JhbACXS45Hd4hwn3Sce4YZBIZQjXmKXQ X-IronPort-AV: E=Sophos;i="4.64,372,1301875200"; d="scan'208";a="697737141" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 16 May 2011 01:34:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4G1YVww001812; Mon, 16 May 2011 01:34:32 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 May 2011 18:34:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 May 2011 18:34:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions Thread-Index: AcwRTUsM1KxMHEe+TdGDsqXT44uGzAB7X+Lg References: From: "Charles Eckel (eckelcu)" To: "Stephan Wenger" , "CLUE" X-OriginalArrivalTime: 16 May 2011 01:34:31.0952 (UTC) FILETIME=[67B83100:01CC1369] Subject: Re: [clue] Definitions 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, 16 May 2011 01:34:47 -0000 Hi Stephan, This is a great start. I do not know if you volunteered to update as well as provide the initial version of this document. In any case, here are some comments. > Endpoint - The logical point of final termination through > receiving, decoding and rendering, and/or initiation through > capturing, encoding, and sending of media streams. An endpoint > consists of one or more physical devices which source and sink > media streams. In contrast to an endpoint, a middle box, such > as an MCU, may also send and receive media streams, but it is > not the initiator nor the final terminator. I am not sure we should differentiate between endpoint and MCU. The distinction blurs in that an MCU generates and send media streams that are not necessarily equivalent to those it received, and it receives input from other endpoints. I think trying to distinguish them simply makes more work and add complexity. I also think we will find that the majority of "MCUs" are really more "endpoints" than "MCUs".=20 You introduced the concept of remote. I am proposing remote =3D=3D = endpoint and remove MCU. > Media - Any data that, after suitable encoding, can be conveyed > over RTP, including audio, video or timed text. I think this is too general, but I am not able to suggest a good way to improve it. > Session - RTP session. An association among a set of > participants communicating with RTP. The distinguishing feature > of an RTP session is that each maintains a full, separate space > of SSRC identifiers. [RFC3550] In this case, do we also need a term for the collection of RTP sessions the contains the complete set media exchanged between two endpoints?=20 "Layouts" vs. "Spatial Relations", what is the difference? Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger > Sent: Friday, May 13, 2011 11:08 AM > To: CLUE > Subject: [clue] Definitions >=20 > Hi folks, > Here a VERY rough initial draft. Addressing typos, sorting to alphabetical, and other cleanup tasks > will have to wait for the my return to the office next week. I will submit officially only after the > most embarrassing bugs are sorted out. No need to comment on typos, but if you have substantial > issues then send them now, and I can address them immediately. > Stephan From allyn@cisco.com Mon May 16 11:54:23 2011 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 E36D0E07A6 for ; Mon, 16 May 2011 11:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DyVr0YFH6iBq for ; Mon, 16 May 2011 11:54:21 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 28019E0791 for ; Mon, 16 May 2011 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11929; q=dns/txt; s=iport; t=1305572061; x=1306781661; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=FtQRua4jOj/FwyTPo9rI/+IcvrWMVKU8jWP5UaACgE8=; b=kT9/uLxg5tm9TyOPnaRzHLIupldDmYdpvm8VDfgLn/60qYkdTmov38Lc R1S7O057w/r/Syu7H0NcMsPELfvrfUI9114KmfMtGMuNlWOEJd3OkcjuK rAj9E6rmtyWb9NVekEs80/rinR/B1UP2AGsBjqC/hyAkMuqopOn1/Dpx4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAALBx0U2rRDoH/2dsb2JhbACCZZRmjkx3qCaeHIYZBIZQjXmKXQ X-IronPort-AV: E=Sophos;i="4.65,220,1304294400"; d="scan'208,217";a="358119785" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 16 May 2011 18:54:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4GIsJjK025755; Mon, 16 May 2011 18:54:19 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 11:54:19 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC13FA.A97C0C23" Date: Mon, 16 May 2011 11:54:18 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> From: "Allyn Romanow (allyn)" To: , , X-OriginalArrivalTime: 16 May 2011 18:54:19.0713 (UTC) FILETIME=[A9B90B10:01CC13FA] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 16 May 2011 18:54:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC13FA.A97C0C23 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Bruno and other folks interested in saying something about legacy in = the requirements doc- =20 Thanks for pointing out the distinction between proprietary extensions = versus standard SIP compliant solutions. Also, I agree with you that Req = #10 is aimed at CLUEful players, not devices that do not understand = CLUE. =20 Could you be a bit more specific about what you feel should be included = in "legacy support"? =20 Roni suggested, I am also missing a requirement for "legacy" system support like the = solution MUST enable a system that does not support the mechanism to = select the best set of streams to render (audio + video). =20 I don't quite get this in that a system that doesn't support the CLUE = mechanism cannot select streams, that's the issue. I would assume that = the interaction between a non-CLUE and a CLUE system would be the same = as between 2 non-CLUE systems - they don't interwork, but CLUE shouldn't = make the situation any worse. =20 It would be great if you could suggest some wording that you would like = to have added. =20 =20 Thanks, Allyn =20 From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Wednesday, May 11, 2011 11:50 PM To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; = Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 Hi, >From previous discussions on the mailing list and at IETF#80 I = understood that =AB non-standards compliant =BB was referring to = solutions that make use of proprietary extensions (e.g. proprietary = extensions to SDP or RTCP) while "legacy support" was referring to = standard compliant solutions that do not understand the extensions that = CLUE will specify (or request other groups to specify). The charter does = not exclude the second case and Req# 10 is not specific enough. From = the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined = extensions) with different capabilities, not to devices that do not = understand clue extensions... BC =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Allyn Romanow (allyn) Envoy=E9 : jeudi 12 mai 2011 03:20 =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even Cc : CLUE Objet : [clue] legacy support in requirements =20 Hi,=20 You both asked to add a requirement for legacy support. However, the = charter says =20 "Interoperation with SIP and related standards for audio and video is = required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required." =20 On the basis of this, I think it would not be a good requirement to add. = However, there is a requirement, 10, that addresses making it possible = for endpoints with varying capabilities to interoperate in a = telepresence conference. =20 Regards, Allyn ------_=_NextPart_001_01CC13FA.A97C0C23 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

HI Bruno and other = folks interested in saying something about legacy in the requirements = doc-

 

Thanks for pointing = out=A0 the distinction=A0 between proprietary extensions versus standard SIP = compliant solutions. Also, I agree with you that Req #10 is aimed at CLUEful = players, not devices that do not understand CLUE.

 

Could you be a bit = more specific about what you feel=A0 should be included in “legacy = support”?

 

Roni = suggested,

I am also missing a = requirement for "legacy" system support like the solution MUST enable a = system that does not support the mechanism to select the best set of streams to = render (audio + video).

 

I don’t quite = get this in that a system that doesn’t support the CLUE mechanism cannot = select streams, that’s the issue. I would assume that the interaction = between a non-CLUE and a CLUE system would be the same as between 2 non-CLUE = systems – they don’t interwork, but CLUE shouldn’t make the = situation any worse.

 

It would be great if = you could suggest some wording that you would like to have = added.

 

 

Thanks,

Allyn

 

From:= bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Wednesday, May 11, 2011 11:50 PM
To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

Hi,

From previous = discussions on the mailing list and at IETF#80 I understood that =AB non-standards compliant =BB was referring to solutions that make use of = proprietary extensions (e.g. proprietary extensions to SDP or RTCP) while = “legacy support” was referring to standard compliant solutions that do not understand the extensions that CLUE will specify (or request other = groups to specify). The charter does not exclude the second case and Req# 10 is = not specific enough.  From the current text, one could understand that = Req#10 applies to clue-compliant devices (i.e. devices that understand = clue-defined extensions) with different capabilities, not to devices that do not = understand clue extensions...

BC

 

De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Allyn Romanow (allyn)
Envoy=E9 : jeudi 12 mai 2011 03:20
=C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
Cc : CLUE
Objet : [clue] legacy support in = requirements

 

Hi,

You both asked to add a requirement for legacy = support. However, the charter says

 

“Interoperation with SIP and related = standards for audio and video is required. However, backwards compatibility with = existing
non-standards compliant telepresence systems is not = required.”

 

On the basis of this, I think it would not be a = good requirement to add. However, there is a requirement, 10, that addresses = making it possible for endpoints with varying capabilities to interoperate in a telepresence conference.

 

Regards,

Allyn

------_=_NextPart_001_01CC13FA.A97C0C23-- From allyn@cisco.com Mon May 16 11:57:58 2011 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 84C95E0799 for ; Mon, 16 May 2011 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 F1P1vS9UYMFC for ; Mon, 16 May 2011 11:57:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id D8A81E07A9 for ; Mon, 16 May 2011 11:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3055; q=dns/txt; s=iport; t=1305572273; x=1306781873; h=mime-version:subject:date:message-id:from:to; bh=Uo5iZk4sDk8DITbHQnHkWYu37iMwnt8fEtAURdHF/EE=; b=VxjOwPW/rh9Xfm1NVsoL5PQ5VzKapN3BLaQllF733Q2Lmw1s2x7jIuEI JYcE3ojL6rXUiywlpC0yludiLrMUxoX2tF6x8jooe/0q/RWKj0Ov+zaC4 rEmJyCYOOWi482/yYBEqdnm1mW5fE+c5eSm7GfVEtDuDOlNlVqiaV81We s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucHAIxz0U2rRDoJ/2dsb2JhbACCZZUmjgx3pn+BHZ4ehhkEhlCNeYpd X-IronPort-AV: E=Sophos;i="4.65,220,1304294400"; d="scan'208,217";a="448694623" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 16 May 2011 18:57:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4GIvZ4G023834 for ; Mon, 16 May 2011 18:57:35 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 11:57:27 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC13FB.1915901A" Date: Mon, 16 May 2011 11:57:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F8@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: requirements draft- heads up Thread-Index: AcwT+xi+Zv3z4n+RRwSP7Lw94vQjsg== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 16 May 2011 18:57:27.0358 (UTC) FILETIME=[199165E0:01CC13FB] Subject: [clue] requirements draft- heads up 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, 16 May 2011 18:57:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC13FB.1915901A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi- After the interim meeting, I tried looking at the requirements from another perspective. I thought tying them more closely to the use cases, as is often done in reqmts drafts, might solve the issue of the lack of specificity that was of concern.=20 =20 I'll have an updated version for you to look at very soon - later today or tomorrow. =20 Thanks, Allyn ------_=_NextPart_001_01CC13FB.1915901A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi-

After the interim meeting, I tried looking at the = requirements from another perspective. I thought tying them more closely to the use = cases, as is often done in reqmts drafts, might solve the issue of the lack of specificity that was of concern.

 

I’ll have an updated version for you to look = at very soon – later today or tomorrow.

 

Thanks,

Allyn

------_=_NextPart_001_01CC13FB.1915901A-- From pkyzivat@cisco.com Mon May 16 12:02:24 2011 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 58688E0793 for ; Mon, 16 May 2011 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1RLj0vx7-+hl for ; Mon, 16 May 2011 12:02:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 30F81E0681 for ; Mon, 16 May 2011 12:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=629; q=dns/txt; s=iport; t=1305572522; x=1306782122; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NsPTJhw1FLBhqgxARS0Fxj090Bep1wXalomeH/fdOo4=; b=JIa/PusEtFGbcKS1tHw2z5yYkJgaBXjQUXXPe+8AJs0dnhE3RgCYdNUW qH0vex+lAK+4UCbOenSIXi3JQ6wwdqinqvvTCiaPd8b5cdHCAWvMB9nlD C/Vmokq+Jio14+JlgJdrj1BxJoshfIFQf2lMTwwJ3FYRpYwpOTRu9kY3q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUHAAt00U2rRDoG/2dsb2JhbACYC44Md4hwnyyeI4YZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,220,1304294400"; d="scan'208";a="698245043" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 16 May 2011 19:01:59 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4GJ1wVa013801 for ; Mon, 16 May 2011 19:01:59 GMT Message-ID: <4DD174A6.6090005@cisco.com> Date: Mon, 16 May 2011 15:01:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F8@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F8@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] requirements draft- heads up 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, 16 May 2011 19:02:24 -0000 On 5/16/2011 2:57 PM, Allyn Romanow (allyn) wrote: > Hi- > > After the interim meeting, I tried looking at the requirements from > another perspective. I thought tying them more closely to the use cases, > as is often done in reqmts drafts, might solve the issue of the lack of > specificity that was of concern. Yes, it would help! Thanks, Paul > I’ll have an updated version for you to look at very soon – later today > or tomorrow. > > Thanks, > > Allyn > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Mon May 16 23:20:16 2011 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 3D89BE06BE for ; Mon, 16 May 2011 23:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 03hv9pWYgF3j for ; Mon, 16 May 2011 23:20:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E1570E07AE for ; Mon, 16 May 2011 23:20:12 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB0070XTKDOV@szxga05-in.huawei.com> for clue@ietf.org; Tue, 17 May 2011 14:19:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00BZ0TKC3Y@szxga05-in.huawei.com> for clue@ietf.org; Tue, 17 May 2011 14:19:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-5-237.red.bezeqint.net [79.180.5.237]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLB0053MTK5BK@szxml11-in.huawei.com>; Tue, 17 May 2011 14:19:24 +0800 (CST) Date: Tue, 17 May 2011 09:17:47 +0300 From: Roni Even In-reply-to: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> To: "'Gorzynski, Mark E (The Right One)'" , clue@ietf.org Message-id: <011a01cc145a$2856a180$7903e480$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZmSvAzc3Vfoe2C5MaWnqkw)" Content-language: en-us Thread-index: AcwQQdt4Du/Zyg6GRuuSA4Zz7g1W6AEF19qA References: <4168915E16BA9E47972F4A4B4EE3228276B6AF8E92@GVW1096EXB.americas.hpqcorp.net> Subject: Re: [clue] virtual space (multi-view) use case 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, 17 May 2011 06:20:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZmSvAzc3Vfoe2C5MaWnqkw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described. Will it make sense to mention that the camera can provide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera. Regards Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gorzynski, Mark E (The Right One) Sent: Thursday, May 12, 2011 4:18 AM To: clue@ietf.org Subject: [clue] virtual space (multi-view) use case Greetings, It occurs to me that one use case commonly represented in products on the market today may not have been fully described. It has been referred to as a "multi-view" use case since it deals with cameras at different viewpoints aimed at the same area of an endpoint. However we use the term "virtual space" for this use case since it has been called by this name in the literature (see below). 1. Virtual Space Multipoint This use case describes a virtual space multipoint video meeting with good eye contact and spatial layout of participants. The use case was proposed very early in the development of video conferencing systems as described in 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738 ). The use case is illustrated in figure 2-5 of their report. Today, the use case is implemented in multiple telepresence type video conferencing systems on the market. The term "virtual space" was used in their report. The main difference between the result obtained with modern systems and those from 1983 are larger display sizes. Virtual space multipoint as defined here assumes endpoints with multiple cameras and displays. Usually there are the same number of cameras and displays at a given endpoint. A camera is positioned above each display. A key aspect of virtual space multipoint is the details of how the cameras are aimed. The cameras are each aimed on the same area of view of the participants at the site. Thus each camera takes a picture of the same set of people but from a different angle. Each endpoint sender in the virtual space multipoint meeting therefore offers a choice of video streams to remote receivers, each stream representing a different view point. For example a camera positioned above a display to a participant's left may take video pictures of the participant's left ear while at the same time, a camera positioned above a display to the participant's right may take video pictures of the participant's right ear. Since a sending endpoint has a camera associated with each display, an association is made between the receiving stream output on a particular display and the corresponding sending stream from the camera associated with that display. These associations are repeated for each display/camera pair in a meeting. The result of this system is a horizontal arrangement of video images from remote sites, one per display. The image from each display is paired with the camera output from the camera above that display resulting in excellent eye contact. Best Regards, Mark Gorzynski HP Visual Collaboration --Boundary_(ID_ZmSvAzc3Vfoe2C5MaWnqkw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Mark,

I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described.

Will it make sense to mention that the camera can provide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera.

 

Regards

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gorzynski, Mark E (The Right One)
Sent: Thursday, May 12, 2011 4:18 AM
To: clue@ietf.org
Subject: [clue] virtual space (multi-view) use case

 

Greetings,

 

It occurs to me that one use case commonly represented in products on the market today may not have been fully described.  It has been referred t o as a & se case since it deals with cameras at different viewpoints aimed at the same area of an endpoint.  However we use the term “virtual space” for this use case since it has been called by this name in the literature (see below).

 

1. Virtual Space Multipoint

 

This use case describes a virtual space multipoint video meeting with good eye contact and spatial layout of participants.  The use case was proposed very early in the development of video conferencing systems as described in 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738  ).  The use case is illustrated in figure 2-5 of their report.  Today, the use case is implemented in multiple telepresence type video conferencing system s on the #8220;virtual space” was used in their report.  The main difference between the result obtained with modern systems and those from 1983 are larger display sizes.

 

Virtual space multipoint as defined here assumes endpoints with multiple cameras and displays.  Usually there are the same number of cameras and displays at a given endpoint.  A camera is positioned above each display.  A key aspect of virtual space multipoint is the details of how the cameras are aimed.  The cameras are each aimed on the same area of view of the participants at the site.  Thus each camera takes a picture of the same set of people but from a different angle.  Each endpoint sender in the virtual space multipoint meeting therefore offers a choice of video streams to remote receivers, each stream representing a different view point.  For example a camera positioned above a display to a particip video pictures of the participant’s left ear while at the same time, a camera positioned above a display to the participant’s right may take video pictures of the participant’s right ear.

 

Since a sending endpoint has a camera associated with each display, an association is made between the receiving stream output on a particular display and the corresponding sending stream from the camera associated with that display.  These associations are repeated for each display/camera pair in a meeting.  The result of this system is a horizontal arrangement of video images from remote sites, one per display.  The image from each display is paired with the camera output from the camera above that display resulting in excellent eye contact.

 

 

 

 

Mark Gorzynski

HP Visual Collaboration

 

--Boundary_(ID_ZmSvAzc3Vfoe2C5MaWnqkw)-- From Even.roni@huawei.com Mon May 16 23:26:19 2011 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 8DD93E072D for ; Mon, 16 May 2011 23:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9wgwvzUYyV9o for ; Mon, 16 May 2011 23:26:14 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2F389E06BE for ; Mon, 16 May 2011 23:26:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00JT0TVB3P@szxga03-in.huawei.com> for clue@ietf.org; Tue, 17 May 2011 14:25:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00FOHTVBDQ@szxga03-in.huawei.com> for clue@ietf.org; Tue, 17 May 2011 14:25:59 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-5-237.red.bezeqint.net [79.180.5.237]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLB00HCXTV4U0@szxml12-in.huawei.com>; Tue, 17 May 2011 14:25:59 +0800 (CST) Date: Tue, 17 May 2011 09:24:22 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" , bruno.chatras@orange-ftgroup.com, stephane.cazeaux@orange-ftgroup.com Message-id: <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/HFgb4Neq1I89N0oVUEZIA)" Content-language: en-us Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4A== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 06:26:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/HFgb4Neq1I89N0oVUEZIA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi Allyn, When the offer includes parameters that the answerer does not understand there are two options, he can ignore the unknown parameters or reject = the offer. If the answerer ignores the SDP parameters that he does not understand the remaining parameters should allow him to establish a = media connection that will use the media stream that the offerer wants to be = used in this case. One example is using potential configurations as specified = in the MMUSIC media capability negotiation draft. =20 Roni =20 From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Sent: Monday, May 16, 2011 9:54 PM To: bruno.chatras@orange-ftgroup.com; = stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 HI Bruno and other folks interested in saying something about legacy in = the requirements doc- =20 Thanks for pointing out the distinction between proprietary extensions versus standard SIP compliant solutions. Also, I agree with you that Req = #10 is aimed at CLUEful players, not devices that do not understand CLUE. =20 Could you be a bit more specific about what you feel should be included = in =93legacy support=94? =20 Roni suggested, I am also missing a requirement for "legacy" system support like the solution MUST enable a system that does not support the mechanism to = select the best set of streams to render (audio + video). =20 I don=92t quite get this in that a system that doesn=92t support the = CLUE mechanism cannot select streams, that=92s the issue. I would assume that = the interaction between a non-CLUE and a CLUE system would be the same as between 2 non-CLUE systems =96 they don=92t interwork, but CLUE = shouldn=92t make the situation any worse. =20 It would be great if you could suggest some wording that you would like = to have added. =20 =20 Thanks, Allyn =20 From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Wednesday, May 11, 2011 11:50 PM To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 Hi, >From previous discussions on the mailing list and at IETF#80 I = understood that =AB non-standards compliant =BB was referring to solutions that = make use of proprietary extensions (e.g. proprietary extensions to SDP or RTCP) = while =93legacy support=94 was referring to standard compliant solutions that = do not understand the extensions that CLUE will specify (or request other = groups to specify). The charter does not exclude the second case and Req# 10 is = not specific enough. From the current text, one could understand that = Req#10 applies to clue-compliant devices (i.e. devices that understand = clue-defined extensions) with different capabilities, not to devices that do not understand clue extensions... BC =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Allyn Romanow (allyn) Envoy=E9 : jeudi 12 mai 2011 03:20 =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even Cc : CLUE Objet : [clue] legacy support in requirements =20 Hi,=20 You both asked to add a requirement for legacy support. However, the = charter says =20 =93Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required.=94 =20 On the basis of this, I think it would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible = for endpoints with varying capabilities to interoperate in a telepresence conference. =20 Regards, Allyn --Boundary_(ID_/HFgb4Neq1I89N0oVUEZIA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable

Hi Allyn,

When the offer includes = parameters that the answerer does not understand there are two options, = he can ignore the unknown parameters or reject the offer. If the = answerer ignores the SDP parameters that he does not understand the = remaining parameters should allow him to establish a media connection = that will use the media stream that the offerer wants to be used in this = case. One example is using potential configurations as specified in the = MMUSIC media capability negotiation draft.

 

Roni

 

From:= = Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Monday, = May 16, 2011 9:54 PM
To: bruno.chatras@orange-ftgroup.com; = stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: = clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

HI Bruno and other folks interested in saying = something about legacy in the requirements doc-

 

Thanks for pointing = out  the distinction  between proprietary extensions versus = standard SIP compliant solutions. Also, I agree with you that Req #10 is = aimed at CLUEful players, not devices that do not understand = CLUE.

 

Could you be a bit more = specific about what you feel  should be included in “legacy = support”?

 

Roni = suggested,

I am also missing a requirement for = "legacy" system support like the solution MUST enable a system = that does not support the mechanism to select the best set of streams to = render (audio + video).

 

I don’t quite get = this in that a system that doesn’t support the CLUE mechanism = cannot select streams, that’s the issue. I would assume that the = interaction between a non-CLUE and a CLUE system would be the same as = between 2 non-CLUE systems – they don’t interwork, but CLUE = shouldn’t make the situation any worse.

 

It would be great if you = could suggest some wording that you would like to have = added.

 

 

Thanks,

Allyn

 

From:= = bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Wednesday, = May 11, 2011 11:50 PM
To: Allyn Romanow (allyn); = stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: = clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

Hi,

From previous = discussions on the mailing list and at IETF#80 I understood that = =AB non-standards compliant =BB was referring to solutions = that make use of proprietary extensions (e.g. proprietary extensions to = SDP or RTCP) while “legacy support” was referring to = standard compliant solutions that do not understand the extensions that = CLUE will specify (or request other groups to specify). The charter does = not exclude the second case and Req# 10 is not specific enough. =  From the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined = extensions) with different capabilities, not to devices that do not = understand clue extensions...

BC

 

De : = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Allyn Romanow (allyn)
Envoy=E9 : jeudi 12 mai 2011 = 03:20
=C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni = Even
Cc : CLUE
Objet : [clue] legacy = support in requirements

 

Hi,

You both asked = to add a requirement for legacy support. However, the charter = says

 

“Interoperation with SIP and related standards = for audio and video is required. However, backwards compatibility with = existing
non-standards compliant telepresence systems is not = required.”

 

On the basis = of this, I think it would not be a good requirement to add. However, = there is a requirement, 10, that addresses making it possible for = endpoints with varying capabilities to interoperate in a telepresence = conference.

 

Regards,

Allyn

= --Boundary_(ID_/HFgb4Neq1I89N0oVUEZIA)-- From john.elwell@siemens-enterprise.com Mon May 16 23:34:07 2011 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 AFDCDE069E for ; Mon, 16 May 2011 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 fQbr8UfK6lIp for ; Mon, 16 May 2011 23:34:06 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 697C7E0682 for ; Mon, 16 May 2011 23:34:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1305614045!20018244!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 5573 invoked from network); 17 May 2011 06:34:05 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-174.messagelabs.com with SMTP; 17 May 2011 06:34:05 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1C99A1EB83D3; Tue, 17 May 2011 08:34:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 17 May 2011 08:34:05 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , "bruno.chatras@orange-ftgroup.com" , "stephane.cazeaux@orange-ftgroup.com" , "Even.roni@huawei.com" Date: Tue, 17 May 2011 08:34:03 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1p9IYA== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 06:34:07 -0000 I would suggest a simple extension of REQ-10 as follows: OLD: REQMT-10: The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference. NEW: REQMT-10: The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference, including audio/vi= deo endpoints that do not support any telepresence extensions. John > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Allyn Romanow (allyn) > Sent: 16 May 2011 19:54 > To: bruno.chatras@orange-ftgroup.com;=20 > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > HI Bruno and other folks interested in saying something about=20 > legacy in the requirements doc- >=20 > =20 >=20 > Thanks for pointing out the distinction between proprietary=20 > extensions versus standard SIP compliant solutions. Also, I=20 > agree with you that Req #10 is aimed at CLUEful players, not=20 > devices that do not understand CLUE. >=20 > =20 >=20 > Could you be a bit more specific about what you feel should=20 > be included in "legacy support"? >=20 > =20 >=20 > Roni suggested, >=20 > I am also missing a requirement for "legacy" system support=20 > like the solution MUST enable a system that does not support=20 > the mechanism to select the best set of streams to render=20 > (audio + video). >=20 > =20 >=20 > I don't quite get this in that a system that doesn't support=20 > the CLUE mechanism cannot select streams, that's the issue. I=20 > would assume that the interaction between a non-CLUE and a=20 > CLUE system would be the same as between 2 non-CLUE systems -=20 > they don't interwork, but CLUE shouldn't make the situation any worse. >=20 > =20 >=20 > It would be great if you could suggest some wording that you=20 > would like to have added. >=20 > =20 >=20 > =20 >=20 > Thanks, >=20 > Allyn >=20 > =20 >=20 > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: Wednesday, May 11, 2011 11:50 PM > To: Allyn Romanow (allyn);=20 > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > =20 >=20 > Hi, >=20 > From previous discussions on the mailing list and at IETF#80=20 > I understood that =AB non-standards compliant =BB was referring=20 > to solutions that make use of proprietary extensions (e.g.=20 > proprietary extensions to SDP or RTCP) while "legacy support"=20 > was referring to standard compliant solutions that do not=20 > understand the extensions that CLUE will specify (or request=20 > other groups to specify). The charter does not exclude the=20 > second case and Req# 10 is not specific enough. From the=20 > current text, one could understand that Req#10 applies to=20 > clue-compliant devices (i.e. devices that understand=20 > clue-defined extensions) with different capabilities, not to=20 > devices that do not understand clue extensions... >=20 > BC >=20 > =20 >=20 > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De=20 > la part de Allyn Romanow (allyn) > Envoy=E9 : jeudi 12 mai 2011 03:20 > =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > Cc : CLUE > Objet : [clue] legacy support in requirements >=20 > =20 >=20 > Hi,=20 >=20 > You both asked to add a requirement for legacy support.=20 > However, the charter says >=20 > =20 >=20 > "Interoperation with SIP and related standards for audio and=20 > video is required. However, backwards compatibility with existing > non-standards compliant telepresence systems is not required." >=20 > =20 >=20 > On the basis of this, I think it would not be a good=20 > requirement to add. However, there is a requirement, 10, that=20 > addresses making it possible for endpoints with varying=20 > capabilities to interoperate in a telepresence conference. >=20 > =20 >=20 > Regards, >=20 > Allyn >=20 > = From bruno.chatras@orange-ftgroup.com Tue May 17 00:13:02 2011 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 6953EE07E2 for ; Tue, 17 May 2011 00:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 sdrFi4Yx9Y03 for ; Tue, 17 May 2011 00:12:56 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C69BDE07E1 for ; Tue, 17 May 2011 00:12:55 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 400BDFC4009; Tue, 17 May 2011 09:12:54 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2CBACFC4006; Tue, 17 May 2011 09:12:54 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 09:12:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1461.D6C0716B" Date: Tue, 17 May 2011 09:12:54 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102DDAF56@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4AAB0qCw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> From: To: , , X-OriginalArrivalTime: 17 May 2011 07:12:54.0160 (UTC) FILETIME=[D7310900:01CC1461] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 07:13:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1461.D6C0716B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Same view =20 De : Roni Even [mailto:Even.roni@huawei.com]=20 Envoy=E9 : mardi 17 mai 2011 08:24 =C0 : 'Allyn Romanow (allyn)'; CHATRAS Bruno RD-CORE-ISS; CAZEAUX = Stephane RD-BIZZ-CAE Cc : clue@ietf.org Objet : RE: [clue] legacy support in requirements =20 Hi Allyn, When the offer includes parameters that the answerer does not understand = there are two options, he can ignore the unknown parameters or reject = the offer. If the answerer ignores the SDP parameters that he does not = understand the remaining parameters should allow him to establish a = media connection that will use the media stream that the offerer wants = to be used in this case. One example is using potential configurations = as specified in the MMUSIC media capability negotiation draft. =20 Roni =20 From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Sent: Monday, May 16, 2011 9:54 PM To: bruno.chatras@orange-ftgroup.com; = stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 HI Bruno and other folks interested in saying something about legacy in = the requirements doc- =20 Thanks for pointing out the distinction between proprietary extensions = versus standard SIP compliant solutions. Also, I agree with you that Req = #10 is aimed at CLUEful players, not devices that do not understand = CLUE. =20 Could you be a bit more specific about what you feel should be included = in "legacy support"? =20 Roni suggested, I am also missing a requirement for "legacy" system support like the = solution MUST enable a system that does not support the mechanism to = select the best set of streams to render (audio + video). =20 I don't quite get this in that a system that doesn't support the CLUE = mechanism cannot select streams, that's the issue. I would assume that = the interaction between a non-CLUE and a CLUE system would be the same = as between 2 non-CLUE systems - they don't interwork, but CLUE shouldn't = make the situation any worse. =20 It would be great if you could suggest some wording that you would like = to have added. =20 =20 Thanks, Allyn =20 From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Wednesday, May 11, 2011 11:50 PM To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; = Even.roni@huawei.com Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements =20 Hi, >From previous discussions on the mailing list and at IETF#80 I = understood that =AB non-standards compliant =BB was referring to = solutions that make use of proprietary extensions (e.g. proprietary = extensions to SDP or RTCP) while "legacy support" was referring to = standard compliant solutions that do not understand the extensions that = CLUE will specify (or request other groups to specify). The charter does = not exclude the second case and Req# 10 is not specific enough. From = the current text, one could understand that Req#10 applies to = clue-compliant devices (i.e. devices that understand clue-defined = extensions) with different capabilities, not to devices that do not = understand clue extensions... BC =20 De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Allyn Romanow (allyn) Envoy=E9 : jeudi 12 mai 2011 03:20 =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even Cc : CLUE Objet : [clue] legacy support in requirements =20 Hi,=20 You both asked to add a requirement for legacy support. However, the = charter says =20 "Interoperation with SIP and related standards for audio and video is = required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required." =20 On the basis of this, I think it would not be a good requirement to add. = However, there is a requirement, 10, that addresses making it possible = for endpoints with varying capabilities to interoperate in a = telepresence conference. =20 Regards, Allyn ------_=_NextPart_001_01CC1461.D6C0716B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Same = view

 

De : Roni Even [mailto:Even.roni@huawei.com]
Envoy=E9 : mardi 17 mai 2011 08:24
=C0 : 'Allyn Romanow (allyn)'; CHATRAS Bruno RD-CORE-ISS; = CAZEAUX Stephane RD-BIZZ-CAE
Cc : clue@ietf.org
Objet : RE: [clue] legacy support in = requirements

 

Hi = Allyn,

When the = offer includes parameters that the answerer does not understand there are two options, he can ignore the unknown parameters or reject the offer. If = the answerer ignores the SDP parameters that he does not understand the = remaining parameters should allow him to establish a media connection that will = use the media stream that the offerer wants to be used in this case. One example = is using potential configurations as specified in the MMUSIC media = capability negotiation draft.

 

Roni

 

From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Monday, May 16, 2011 9:54 PM
To: bruno.chatras@orange-ftgroup.com; stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

HI Bruno = and other folks interested in saying something about legacy in the requirements = doc-

 

Thanks = for pointing out  the distinction  between proprietary extensions versus = standard SIP compliant solutions. Also, I agree with you that Req #10 is aimed at CLUEful players, not devices that do not understand = CLUE.

 

Could = you be a bit more specific about what you feel  should be included in = “legacy support”?

 

Roni = suggested,

I am also missing a requirement for "legacy" system support like the = solution MUST enable a system that does not support the mechanism to select the = best set of streams to render (audio + video).

 

I = don’t quite get this in that a system that doesn’t support the CLUE mechanism = cannot select streams, that’s the issue. I would assume that the interaction = between a non-CLUE and a CLUE system would be the same as between 2 non-CLUE = systems – they don’t interwork, but CLUE shouldn’t make the situation = any worse.

 

It would = be great if you could suggest some wording that you would like to have = added.

 

 

Thanks,

Allyn

 

From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Wednesday, May 11, 2011 11:50 PM
To: Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
Cc: clue@ietf.org
Subject: RE: [clue] legacy support in = requirements

 

Hi,

From = previous discussions on the mailing list and at IETF#80 I understood that =AB non-standards compliant =BB was referring to solutions = that make use of proprietary extensions (e.g. proprietary extensions to SDP or RTCP) = while “legacy support” was referring to standard compliant = solutions that do not understand the extensions that CLUE will specify (or request other = groups to specify). The charter does not exclude the second case and Req# 10 is = not specific enough.  From the current text, one could understand that = Req#10 applies to clue-compliant devices (i.e. devices that understand = clue-defined extensions) with different capabilities, not to devices that do not = understand clue extensions...

BC

 

De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Allyn Romanow (allyn)
Envoy=E9 : jeudi 12 mai 2011 03:20
=C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
Cc : CLUE
Objet : [clue] legacy support in = requirements

 

Hi,

You both asked to add a = requirement for legacy support. However, the charter says

 

“Interoperation with SIP = and related standards for audio and video is required. However, backwards = compatibility with existing
non-standards compliant telepresence systems is not = required.”

 

On the basis of this, I think it = would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible for endpoints with varying capabilities to interoperate in a telepresence conference.

 

Regards,

Allyn

------_=_NextPart_001_01CC1461.D6C0716B-- From bruno.chatras@orange-ftgroup.com Tue May 17 00:16:10 2011 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 5053FE07E6 for ; Tue, 17 May 2011 00:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 BvIwZfXt3gIn for ; Tue, 17 May 2011 00:16:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DDE067F for ; Tue, 17 May 2011 00:16:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5CE16D8002; Tue, 17 May 2011 09:17:23 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id BA0966C0003; Tue, 17 May 2011 09:17:23 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 09:16:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 May 2011 09:16:09 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102DDAF61@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1p9IYAABeCrQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> From: To: , , , X-OriginalArrivalTime: 17 May 2011 07:16:08.0414 (UTC) FILETIME=[4AF9D7E0:01CC1462] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 07:16:10 -0000 We don't have to be explicit about the type of media (audio/video)... = just write "including endpoints that..." or "including those that..." > -----Message d'origine----- > De=A0: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Envoy=E9=A0: mardi 17 mai 2011 08:34 > =C0=A0: Allyn Romanow (allyn); CHATRAS Bruno RD-CORE-ISS; CAZEAUX = Stephane > RD-BIZZ-CAE; Even.roni@huawei.com > Cc=A0: clue@ietf.org > Objet=A0: RE: [clue] legacy support in requirements >=20 > I would suggest a simple extension of REQ-10 as follows: >=20 > OLD: > REQMT-10: The solution MUST include a mechanism that makes it > possible for endpoints with different capabilities to > interoperate in a telepresence conference. > NEW: > REQMT-10: The solution MUST include a mechanism that makes it > possible for endpoints with different capabilities to > interoperate in a telepresence conference, including > audio/video endpoints that do not support any telepresence extensions. >=20 >=20 > John >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Allyn Romanow (allyn) > > Sent: 16 May 2011 19:54 > > To: bruno.chatras@orange-ftgroup.com; > > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > HI Bruno and other folks interested in saying something about > > legacy in the requirements doc- > > > > > > > > Thanks for pointing out the distinction between proprietary > > extensions versus standard SIP compliant solutions. Also, I > > agree with you that Req #10 is aimed at CLUEful players, not > > devices that do not understand CLUE. > > > > > > > > Could you be a bit more specific about what you feel should > > be included in "legacy support"? > > > > > > > > Roni suggested, > > > > I am also missing a requirement for "legacy" system support > > like the solution MUST enable a system that does not support > > the mechanism to select the best set of streams to render > > (audio + video). > > > > > > > > I don't quite get this in that a system that doesn't support > > the CLUE mechanism cannot select streams, that's the issue. I > > would assume that the interaction between a non-CLUE and a > > CLUE system would be the same as between 2 non-CLUE systems - > > they don't interwork, but CLUE shouldn't make the situation any = worse. > > > > > > > > It would be great if you could suggest some wording that you > > would like to have added. > > > > > > > > > > > > Thanks, > > > > Allyn > > > > > > > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: Wednesday, May 11, 2011 11:50 PM > > To: Allyn Romanow (allyn); > > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > Hi, > > > > From previous discussions on the mailing list and at IETF#80 > > I understood that =AB non-standards compliant =BB was referring > > to solutions that make use of proprietary extensions (e.g. > > proprietary extensions to SDP or RTCP) while "legacy support" > > was referring to standard compliant solutions that do not > > understand the extensions that CLUE will specify (or request > > other groups to specify). The charter does not exclude the > > second case and Req# 10 is not specific enough. From the > > current text, one could understand that Req#10 applies to > > clue-compliant devices (i.e. devices that understand > > clue-defined extensions) with different capabilities, not to > > devices that do not understand clue extensions... > > > > BC > > > > > > > > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De > > la part de Allyn Romanow (allyn) > > Envoy=E9 : jeudi 12 mai 2011 03:20 > > =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > > Cc : CLUE > > Objet : [clue] legacy support in requirements > > > > > > > > Hi, > > > > You both asked to add a requirement for legacy support. > > However, the charter says > > > > > > > > "Interoperation with SIP and related standards for audio and > > video is required. However, backwards compatibility with existing > > non-standards compliant telepresence systems is not required." > > > > > > > > On the basis of this, I think it would not be a good > > requirement to add. However, there is a requirement, 10, that > > addresses making it possible for endpoints with varying > > capabilities to interoperate in a telepresence conference. > > > > > > > > Regards, > > > > Allyn > > > > From john.elwell@siemens-enterprise.com Tue May 17 01:46:14 2011 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 96177E072F for ; Tue, 17 May 2011 01:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 QSt1k71Gp84D for ; Tue, 17 May 2011 01:46:14 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 5608BE0724 for ; Tue, 17 May 2011 01:46:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1305621972!13670163!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 8555 invoked from network); 17 May 2011 08:46:12 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-174.messagelabs.com with SMTP; 17 May 2011 08:46:12 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 23EF023F03E9; Tue, 17 May 2011 10:46:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 17 May 2011 10:46:12 +0200 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "allyn@cisco.com" , "stephane.cazeaux@orange-ftgroup.com" , "Even.roni@huawei.com" Date: Tue, 17 May 2011 10:46:10 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1p9IYAABeCrQAAM5lgA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102DDAF61@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102DDAF61@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 08:46:14 -0000 Yes, that would be OK too. John=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 17 May 2011 08:16 > To: Elwell, John; allyn@cisco.com;=20 > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > We don't have to be explicit about the type of media=20 > (audio/video)... just write "including endpoints that..." or=20 > "including those that..." >=20 > > -----Message d'origine----- > > De=A0: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9=A0: mardi 17 mai 2011 08:34 > > =C0=A0: Allyn Romanow (allyn); CHATRAS Bruno RD-CORE-ISS;=20 > CAZEAUX Stephane > > RD-BIZZ-CAE; Even.roni@huawei.com > > Cc=A0: clue@ietf.org > > Objet=A0: RE: [clue] legacy support in requirements > >=20 > > I would suggest a simple extension of REQ-10 as follows: > >=20 > > OLD: > > REQMT-10: The solution MUST include a mechanism that makes it > > possible for endpoints with different capabilities to > > interoperate in a telepresence conference. > > NEW: > > REQMT-10: The solution MUST include a mechanism that makes it > > possible for endpoints with different capabilities to > > interoperate in a telepresence conference, including > > audio/video endpoints that do not support any telepresence=20 > extensions. > >=20 > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf Of Allyn Romanow (allyn) > > > Sent: 16 May 2011 19:54 > > > To: bruno.chatras@orange-ftgroup.com; > > > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > HI Bruno and other folks interested in saying something about > > > legacy in the requirements doc- > > > > > > > > > > > > Thanks for pointing out the distinction between proprietary > > > extensions versus standard SIP compliant solutions. Also, I > > > agree with you that Req #10 is aimed at CLUEful players, not > > > devices that do not understand CLUE. > > > > > > > > > > > > Could you be a bit more specific about what you feel should > > > be included in "legacy support"? > > > > > > > > > > > > Roni suggested, > > > > > > I am also missing a requirement for "legacy" system support > > > like the solution MUST enable a system that does not support > > > the mechanism to select the best set of streams to render > > > (audio + video). > > > > > > > > > > > > I don't quite get this in that a system that doesn't support > > > the CLUE mechanism cannot select streams, that's the issue. I > > > would assume that the interaction between a non-CLUE and a > > > CLUE system would be the same as between 2 non-CLUE systems - > > > they don't interwork, but CLUE shouldn't make the=20 > situation any worse. > > > > > > > > > > > > It would be great if you could suggest some wording that you > > > would like to have added. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Allyn > > > > > > > > > > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: Wednesday, May 11, 2011 11:50 PM > > > To: Allyn Romanow (allyn); > > > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > > > Hi, > > > > > > From previous discussions on the mailing list and at IETF#80 > > > I understood that =AB non-standards compliant =BB was referring > > > to solutions that make use of proprietary extensions (e.g. > > > proprietary extensions to SDP or RTCP) while "legacy support" > > > was referring to standard compliant solutions that do not > > > understand the extensions that CLUE will specify (or request > > > other groups to specify). The charter does not exclude the > > > second case and Req# 10 is not specific enough. From the > > > current text, one could understand that Req#10 applies to > > > clue-compliant devices (i.e. devices that understand > > > clue-defined extensions) with different capabilities, not to > > > devices that do not understand clue extensions... > > > > > > BC > > > > > > > > > > > > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De > > > la part de Allyn Romanow (allyn) > > > Envoy=E9 : jeudi 12 mai 2011 03:20 > > > =C0 : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > > > Cc : CLUE > > > Objet : [clue] legacy support in requirements > > > > > > > > > > > > Hi, > > > > > > You both asked to add a requirement for legacy support. > > > However, the charter says > > > > > > > > > > > > "Interoperation with SIP and related standards for audio and > > > video is required. However, backwards compatibility with existing > > > non-standards compliant telepresence systems is not required." > > > > > > > > > > > > On the basis of this, I think it would not be a good > > > requirement to add. However, there is a requirement, 10, that > > > addresses making it possible for endpoints with varying > > > capabilities to interoperate in a telepresence conference. > > > > > > > > > > > > Regards, > > > > > > Allyn > > > > > > > = From stewe@stewe.org Tue May 17 06:17:37 2011 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 453B5E0769 for ; Tue, 17 May 2011 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 GWOB9dIWSl-K for ; Tue, 17 May 2011 06:17:36 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id B8104E073E for ; Tue, 17 May 2011 06:17:35 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1986-1743317 for multiple; Tue, 17 May 2011 15:17:33 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 17 May 2011 06:17:27 +0200 From: Stephan Wenger To: "Charles Eckel (eckelcu)" , CLUE Message-ID: Thread-Topic: [clue] Definitions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions 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, 17 May 2011 13:17:37 -0000 Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote == endpoint >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >> >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > From pkyzivat@cisco.com Tue May 17 06:55:45 2011 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 9ED72E076D for ; Tue, 17 May 2011 06:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 KO5lFhzryQNi for ; Tue, 17 May 2011 06:55:45 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id ECA2FE073E for ; Tue, 17 May 2011 06:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4355; q=dns/txt; s=iport; t=1305640544; x=1306850144; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=YNxTUPl7iR5fg5bW+JNdK9x8TKb/w4naOlh/MZCqpN8=; b=hi6Jch3Eq3F/lH+zRNEKIX+SVspgRffGHUGifQ0gGGl8kQ6URPusXxVg vMPgyphMzyWGKVLRcApzDes8FWph4YNcQVpEeEPpFA9MQGjjA78Gl9jMA 59FuPLKpWRbjUF2MfEKq9VWf4Kcrc8guFpMoPrKesDFPnMfsYVmj2CCU0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAA5+0k2rRDoG/2dsb2JhbACXTY5Md4hwoS6eIoYZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="358710856" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 17 May 2011 13:55:44 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4HDticG013473 for ; Tue, 17 May 2011 13:55:44 GMT Message-ID: <4DD27E5F.6070200@cisco.com> Date: Tue, 17 May 2011 09:55:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> In-Reply-To: <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 13:55:45 -0000 On 5/17/2011 2:24 AM, Roni Even wrote: > Hi Allyn, > > When the offer includes parameters that the answerer does not understand > there are two options, he can ignore the unknown parameters or reject > the offer. Rejecting the offer in that case is not really kosher. You are required to ignore parameters you do not understand. If you reject something because you don't like the parameters it contains, then that is an implicit statement that you understand those parameters well enough to decide to reject them. Thanks, Paul > If the answerer ignores the SDP parameters that he does not > understand the remaining parameters should allow him to establish a > media connection that will use the media stream that the offerer wants > to be used in this case. One example is using potential configurations > as specified in the MMUSIC media capability negotiation draft. > > Roni > > *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] > *Sent:* Monday, May 16, 2011 9:54 PM > *To:* bruno.chatras@orange-ftgroup.com; > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > *Cc:* clue@ietf.org > *Subject:* RE: [clue] legacy support in requirements > > HI Bruno and other folks interested in saying something about legacy in > the requirements doc- > > Thanks for pointing out the distinction between proprietary extensions > versus standard SIP compliant solutions. Also, I agree with you that Req > #10 is aimed at CLUEful players, not devices that do not understand CLUE. > > Could you be a bit more specific about what you feel should be included > in “legacy support”? > > Roni suggested, > > I am also missing a requirement for "legacy" system support like the > solution MUST enable a system that does not support the mechanism to > select the best set of streams to render (audio + video). > > I don’t quite get this in that a system that doesn’t support the CLUE > mechanism cannot select streams, that’s the issue. I would assume that > the interaction between a non-CLUE and a CLUE system would be the same > as between 2 non-CLUE systems – they don’t interwork, but CLUE shouldn’t > make the situation any worse. > > It would be great if you could suggest some wording that you would like > to have added. > > Thanks, > > Allyn > > *From:*bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > *Sent:* Wednesday, May 11, 2011 11:50 PM > *To:* Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; > Even.roni@huawei.com > *Cc:* clue@ietf.org > *Subject:* RE: [clue] legacy support in requirements > > Hi, > > From previous discussions on the mailing list and at IETF#80 I > understood that « non-standards compliant » was referring to solutions > that make use of proprietary extensions (e.g. proprietary extensions to > SDP or RTCP) while “legacy support” was referring to standard compliant > solutions that do not understand the extensions that CLUE will specify > (or request other groups to specify). The charter does not exclude the > second case and Req# 10 is not specific enough. From the current text, > one could understand that Req#10 applies to clue-compliant devices (i.e. > devices that understand clue-defined extensions) with different > capabilities, not to devices that do not understand clue extensions... > > BC > > *De :*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *De la part > de* Allyn Romanow (allyn) > *Envoyé :* jeudi 12 mai 2011 03:20 > *À :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > *Cc :* CLUE > *Objet :* [clue] legacy support in requirements > > Hi, > > You both asked to add a requirement for legacy support. However, the > charter says > > “Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing > non-standards compliant telepresence systems is not required.” > > On the basis of this, I think it would not be a good requirement to add. > However, there is a requirement, 10, that addresses making it possible > for endpoints with varying capabilities to interoperate in a > telepresence conference. > > Regards, > > Allyn > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From hmmr@cisco.com Tue May 17 07:16:11 2011 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 470D5E081C for ; Tue, 17 May 2011 07:16:11 -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 o43IXH9v9RXq for ; Tue, 17 May 2011 07:16:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 62B24E0665 for ; Tue, 17 May 2011 07:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=4971; q=dns/txt; s=iport; t=1305641770; x=1306851370; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=urQExkUVOVl/stJKFmJLqYVhY36ErxkwHy/eRnMZxTc=; b=ZZOb0DF+YYWGNiNevIcO7QUnwJpTOKYzvaP5LlqDkg4QQtFTRXfTaHwN EqE5jS3gBOYyicERwpa3rkYymIOkj89PbZpayEfPTX3MryeTNPm5T2/4v Bws/c+1XWkNimP7ChS9G/cSGibNtJ7UTwRAHfHHLNSCcZsgDQaNW6dPs0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAMOC0k2tJXG//2dsb2JhbACXTY5Md4hwoRCeIoYZBIZQjXmKWw X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="358732476" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-2.cisco.com with ESMTP; 17 May 2011 14:16:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4HEG9gL019630 for ; Tue, 17 May 2011 14:16:09 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 09:16:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 May 2011 09:16:08 -0500 Message-ID: In-Reply-To: <4DD27E5F.6070200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwUmi9c6LByWDqDT4arZb493YXdggAAqKLQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 17 May 2011 14:16:09.0286 (UTC) FILETIME=[F7DDBE60:01CC149C] Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 14:16:11 -0000 Paul, Sometimes protocols allow parameters to be marked mandatory, such that = if you don't know them, you reject the transaction. If marked option, then yeah, toss them and move on. Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Paul Kyzivat (pkyzivat) Sent: Tuesday, May 17, 2011 9:56 AM To: clue@ietf.org Subject: Re: [clue] legacy support in requirements On 5/17/2011 2:24 AM, Roni Even wrote: > Hi Allyn, > > When the offer includes parameters that the answerer does not = understand > there are two options, he can ignore the unknown parameters or reject > the offer. Rejecting the offer in that case is not really kosher. You are required to ignore parameters you do not understand. If you reject something because you don't like the parameters it=20 contains, then that is an implicit statement that you understand those=20 parameters well enough to decide to reject them. Thanks, Paul > If the answerer ignores the SDP parameters that he does not > understand the remaining parameters should allow him to establish a > media connection that will use the media stream that the offerer wants > to be used in this case. One example is using potential configurations > as specified in the MMUSIC media capability negotiation draft. > > Roni > > *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] > *Sent:* Monday, May 16, 2011 9:54 PM > *To:* bruno.chatras@orange-ftgroup.com; > stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com > *Cc:* clue@ietf.org > *Subject:* RE: [clue] legacy support in requirements > > HI Bruno and other folks interested in saying something about legacy = in > the requirements doc- > > Thanks for pointing out the distinction between proprietary extensions > versus standard SIP compliant solutions. Also, I agree with you that = Req > #10 is aimed at CLUEful players, not devices that do not understand = CLUE. > > Could you be a bit more specific about what you feel should be = included > in "legacy support"? > > Roni suggested, > > I am also missing a requirement for "legacy" system support like the > solution MUST enable a system that does not support the mechanism to > select the best set of streams to render (audio + video). > > I don't quite get this in that a system that doesn't support the CLUE > mechanism cannot select streams, that's the issue. I would assume that > the interaction between a non-CLUE and a CLUE system would be the same > as between 2 non-CLUE systems - they don't interwork, but CLUE = shouldn't > make the situation any worse. > > It would be great if you could suggest some wording that you would = like > to have added. > > Thanks, > > Allyn > > *From:*bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > *Sent:* Wednesday, May 11, 2011 11:50 PM > *To:* Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; > Even.roni@huawei.com > *Cc:* clue@ietf.org > *Subject:* RE: [clue] legacy support in requirements > > Hi, > > From previous discussions on the mailing list and at IETF#80 I > understood that =AB non-standards compliant =BB was referring to = solutions > that make use of proprietary extensions (e.g. proprietary extensions = to > SDP or RTCP) while "legacy support" was referring to standard = compliant > solutions that do not understand the extensions that CLUE will specify > (or request other groups to specify). The charter does not exclude the > second case and Req# 10 is not specific enough. From the current text, > one could understand that Req#10 applies to clue-compliant devices = (i.e. > devices that understand clue-defined extensions) with different > capabilities, not to devices that do not understand clue extensions... > > BC > > *De :*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *De la part > de* Allyn Romanow (allyn) > *Envoy=E9 :* jeudi 12 mai 2011 03:20 > *=C0 :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even > *Cc :* CLUE > *Objet :* [clue] legacy support in requirements > > Hi, > > You both asked to add a requirement for legacy support. However, the > charter says > > "Interoperation with SIP and related standards for audio and video is > required. However, backwards compatibility with existing > non-standards compliant telepresence systems is not required." > > On the basis of this, I think it would not be a good requirement to = add. > However, there is a requirement, 10, that addresses making it possible > for endpoints with varying capabilities to interoperate in a > telepresence conference. > > Regards, > > Allyn > > > > _______________________________________________ > 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 stephen.botzko@gmail.com Tue May 17 07:34:57 2011 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 AAFF2E081F for ; Tue, 17 May 2011 07:34:57 -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 HRWcoUgmebH0 for ; Tue, 17 May 2011 07:34:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 588A7E0658 for ; Tue, 17 May 2011 07:34:56 -0700 (PDT) Received: by vxg33 with SMTP id 33so456322vxg.31 for ; Tue, 17 May 2011 07:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a/189j4qKBpENwQYE+J8DIIdNrlBQEdgRsM6K5mviQA=; b=W+QEiDDCjUizf0KdhquYkepc5+e0YkCsBVIvd/cWXZDhnbYL46/xvlAYVmgP3DZige LxNkVANT/n0aQ3s2wl4w7Y7LxK7mU0FFkevQUtxKdqDg11skhqRsNTYgAJagJQjdV+qc ZJFdC+yjBcJqobwHjuMJP7U5q0PFDEYvP9bAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xwwFw27uctzOCcgtrfYg8QysLAZosFoFhL/HCRSDUwRiIOvoiDRCb4uCwFqykgn6vr izEFlPmZAFe+PAnIrkdK/N+sAWdt3QpUr7jxZ4xoQ8y0UfxxwggIVtRrenSlJHuNFGvb TqPefp/8LI5BYP+xNwwvHyIe9n+PR+bE2wXX8= MIME-Version: 1.0 Received: by 10.52.106.232 with SMTP id gx8mr931995vdb.236.1305642895549; Tue, 17 May 2011 07:34:55 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Tue, 17 May 2011 07:34:55 -0700 (PDT) In-Reply-To: <4DD27E5F.6070200@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> Date: Tue, 17 May 2011 10:34:55 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec547ca33fe24f504a379ac1e Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 14:34:57 -0000 --bcaec547ca33fe24f504a379ac1e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, May 17, 2011 at 9:55 AM, Paul Kyzivat wrote: > > > On 5/17/2011 2:24 AM, Roni Even wrote: > >> Hi Allyn, >> >> When the offer includes parameters that the answerer does not understand >> there are two options, he can ignore the unknown parameters or reject >> the offer. >> > > Rejecting the offer in that case is not really kosher. > You are required to ignore parameters you do not understand. > > If you reject something because you don't like the parameters it contains= , > then that is an implicit statement that you understand those parameters w= ell > enough to decide to reject them. > As far as I know, you are always free to reject offers, and it doesn't really imply anything when you do that.. Whether it is wise is perhaps a different question. Stephen Botzko > > Thanks, > Paul > > If the answerer ignores the SDP parameters that he does not >> understand the remaining parameters should allow him to establish a >> media connection that will use the media stream that the offerer wants >> to be used in this case. One example is using potential configurations >> as specified in the MMUSIC media capability negotiation draft. >> >> Roni >> >> *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> *Sent:* Monday, May 16, 2011 9:54 PM >> *To:* bruno.chatras@orange-ftgroup.com; >> stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com >> *Cc:* clue@ietf.org >> *Subject:* RE: [clue] legacy support in requirements >> >> HI Bruno and other folks interested in saying something about legacy in >> the requirements doc- >> >> Thanks for pointing out the distinction between proprietary extensions >> versus standard SIP compliant solutions. Also, I agree with you that Req >> #10 is aimed at CLUEful players, not devices that do not understand CLUE= . >> >> Could you be a bit more specific about what you feel should be included >> in =93legacy support=94? >> >> Roni suggested, >> >> I am also missing a requirement for "legacy" system support like the >> solution MUST enable a system that does not support the mechanism to >> select the best set of streams to render (audio + video). >> >> I don=92t quite get this in that a system that doesn=92t support the CLU= E >> mechanism cannot select streams, that=92s the issue. I would assume that >> the interaction between a non-CLUE and a CLUE system would be the same >> as between 2 non-CLUE systems =96 they don=92t interwork, but CLUE shoul= dn=92t >> make the situation any worse. >> >> It would be great if you could suggest some wording that you would like >> to have added. >> >> Thanks, >> >> Allyn >> >> *From:*bruno.chatras@orange-ftgroup.com >> [mailto:bruno.chatras@orange-ftgroup.com] >> *Sent:* Wednesday, May 11, 2011 11:50 PM >> *To:* Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; >> Even.roni@huawei.com >> *Cc:* clue@ietf.org >> *Subject:* RE: [clue] legacy support in requirements >> >> Hi, >> >> From previous discussions on the mailing list and at IETF#80 I >> understood that =AB non-standards compliant =BB was referring to solutio= ns >> that make use of proprietary extensions (e.g. proprietary extensions to >> SDP or RTCP) while =93legacy support=94 was referring to standard compli= ant >> solutions that do not understand the extensions that CLUE will specify >> (or request other groups to specify). The charter does not exclude the >> second case and Req# 10 is not specific enough. From the current text, >> one could understand that Req#10 applies to clue-compliant devices (i.e. >> devices that understand clue-defined extensions) with different >> capabilities, not to devices that do not understand clue extensions... >> >> BC >> >> *De :*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *De la part >> de* Allyn Romanow (allyn) >> *Envoy=E9 :* jeudi 12 mai 2011 03:20 >> *=C0 :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even >> *Cc :* CLUE >> *Objet :* [clue] legacy support in requirements >> >> Hi, >> >> You both asked to add a requirement for legacy support. However, the >> charter says >> >> =93Interoperation with SIP and related standards for audio and video is >> required. However, backwards compatibility with existing >> non-standards compliant telepresence systems is not required.=94 >> >> On the basis of this, I think it would not be a good requirement to add. >> However, there is a requirement, 10, that addresses making it possible >> for endpoints with varying capabilities to interoperate in a >> telepresence conference. >> >> Regards, >> >> Allyn >> >> >> >> _______________________________________________ >> 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 > --bcaec547ca33fe24f504a379ac1e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2011 at 9:55 AM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:


On 5/17/2011 2:24 AM, Roni Even wrote:
Hi Allyn,

When the offer includes parameters that the answerer does not understand there are two options, he can ignore the unknown parameters or reject
the offer.

Rejecting the offer in that case is not really kosher.
You are required to ignore parameters you do not understand.

If you reject something because you don't like the parameters it contai= ns, then that is an implicit statement that you understand those parameters= well enough to decide to reject them.

As far as I= know, you are always free to reject offers, and it doesn't really impl= y anything when you do that..=A0 Whether it is wise is perhaps a different = question.
Stephen Botzko
=A0

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

If the answerer ignores the SDP parameters that he does not
understand the remaining parameters should allow him to establish a
media connection that will use the media stream that the offerer wants
to be used in this case. One example is using potential configurations
as specified in the MMUSIC media capability negotiation draft.

Roni

*From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com]
*Sent:* Monday, May 16, 2011 9:54 PM
*To:* bruno.chatras@orange-ftgroup.com;
st= ephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com
*Cc:* clue@ietf.org<= br> *Subject:* RE: [clue] legacy support in requirements

HI Bruno and other folks interested in saying something about legacy in
the requirements doc-

Thanks for pointing out the distinction between proprietary extensions
versus standard SIP compliant solutions. Also, I agree with you that Req #10 is aimed at CLUEful players, not devices that do not understand CLUE.
Could you be a bit more specific about what you feel should be included
in =93legacy support=94?

Roni suggested,

I am also missing a requirement for "legacy" system support like = the
solution MUST enable a system that does not support the mechanism to
select the best set of streams to render (audio + video).

I don=92t quite get this in that a system that doesn=92t support the CLUE mechanism cannot select streams, that=92s the issue. I would assume that the interaction between a non-CLUE and a CLUE system would be the same
as between 2 non-CLUE systems =96 they don=92t interwork, but CLUE shouldn= =92t
make the situation any worse.

It would be great if you could suggest some wording that you would like
to have added.

Thanks,

Allyn

*From:*bruno.chatras@orange-ftgroup.com
[mailto:bruno.chatras@orange-ftgroup.com]
*Sent:* Wednesday, May 11, 2011 11:50 PM
*To:* Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com;
Even.roni@huawei.= com
*Cc:* clue@ietf.org<= br> *Subject:* RE: [clue] legacy support in requirements

Hi,

=A0From previous discussions on the mailing list and at IETF#80 I
understood that =AB non-standards compliant =BB was referring to solutions<= br> that make use of proprietary extensions (e.g. proprietary extensions to
SDP or RTCP) while =93legacy support=94 was referring to standard compliant=
solutions that do not understand the extensions that CLUE will specify
(or request other groups to specify). The charter does not exclude the
second case and Req# 10 is not specific enough. From the current text,
one could understand that Req#10 applies to clue-compliant devices (i.e. devices that understand clue-defined extensions) with different
capabilities, not to devices that do not understand clue extensions...

BC

*De :*clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] *De la part
de* Allyn Romanow (allyn)
*Envoy=E9 :* jeudi 12 mai 2011 03:20
*=C0 :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
*Cc :* CLUE
*Objet :* [clue] legacy support in requirements

Hi,

You both asked to add a requirement for legacy support. However, the
charter says

=93Interoperation with SIP and related standards for audio and video is
required. However, backwards compatibility with existing
non-standards compliant telepresence systems is not required.=94

On the basis of this, I think it would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible
for endpoints with varying capabilities to interoperate in a
telepresence conference.

Regards,

Allyn



_______________________________________________
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

--bcaec547ca33fe24f504a379ac1e-- From pkyzivat@cisco.com Tue May 17 08:11:30 2011 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 CD062E0778 for ; Tue, 17 May 2011 08:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 efEs2PDtVsNw for ; Tue, 17 May 2011 08:11:30 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id F2E6AE0842 for ; Tue, 17 May 2011 08:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1532; q=dns/txt; s=iport; t=1305645089; x=1306854689; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZBGGqJ1n7zE/EYCkBURLxd9iw0g4JwiU+tKkY6gwHaM=; b=VCRqLxov1mfiVaRT0u9DW3qOdLbzVHdF7wWlrT/lC+h8N/CJyj2MaSiz 0gnQyLBLekW/pDgNiG6KYtbahYfHGQ9kQxfSzE71JAPVOMEKqimFPGdAd 9r9qq0U4y3NHLn6YeFGP1mBNmPWB9w3H8sVz2l4RjWbAiSMHhpojOfzLN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL6O0k2tJXHB/2dsb2JhbACmGXeIcKFNniGGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="285280217" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 17 May 2011 15:11:27 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4HFBRHo010981; Tue, 17 May 2011 15:11:27 GMT Message-ID: <4DD2901F.2000906@cisco.com> Date: Tue, 17 May 2011 11:11:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Botzko References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 15:11:30 -0000 On 5/17/2011 10:34 AM, Stephen Botzko wrote: > On 5/17/2011 2:24 AM, Roni Even wrote: > When the offer includes parameters that the answerer does not > understand > there are two options, he can ignore the unknown parameters or > reject > the offer. > Rejecting the offer in that case is not really kosher. > You are required to ignore parameters you do not understand. > > If you reject something because you don't like the parameters it > contains, then that is an implicit statement that you understand > those parameters well enough to decide to reject them. > > As far as I know, you are always free to reject offers, and it doesn't > really imply anything when you do that.. Whether it is wise is perhaps > a different question. > Stephen Botzko Certainly you are always free to reject an offer. In general I don't know for certain the reason why, and so if I give you the benefit of the doubt I will assume you have a valid reason - perhaps just policy. But if the reason you reject the offer is based on your violating a spec, then you are non-conforming, whether I can determine you are non-conforming or not. Whether being non-conforming is just un-wise, or something stronger, is a separate discussion. The IETF does not levy any penalties for violating its specs. But sometimes the market does. (And sometimes not.) But we don't need to endorse non-conforming behavior in our documents. Thanks, Paul From pkyzivat@cisco.com Tue May 17 08:18:19 2011 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 8C504E0665 for ; Tue, 17 May 2011 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 MsyByx-ICNDY for ; Tue, 17 May 2011 08:18:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6B958E0658 for ; Tue, 17 May 2011 08:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5086; q=dns/txt; s=iport; t=1305645498; x=1306855098; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=DitIZyiLzPMBUb27R2N8hsQjCl6bEB/j0gEiHd4KEAQ=; b=CuLPmAQhmi2tlwrgd80Rp8NFvcE+b/pF3buOh475Hc6pMmz19ChX1YzL AkjnXG1hRUhIuOoaxEQlqMGvVwb8uJRBlbjXupG8JBcvI7mUywy3Y0SbT oM5JrUI0uc91s96rKP9p618iHYVzA/DjBiZMZpSeuWIQ5lrejfXCrVbpo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAIqR0k2tJXG9/2dsb2JhbACXTY5Md6owniKGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="317590237" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 17 May 2011 15:18:06 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4HFI5Jm019275 for ; Tue, 17 May 2011 15:18:05 GMT Message-ID: <4DD291AD.1070300@cisco.com> Date: Tue, 17 May 2011 11:18:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> In-Reply-To: <4DD27E5F.6070200@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 15:18:19 -0000 In my response below I made an assumption that "unknown parameters" was actually talking about "unknown a-lines". In the case of unknown parameters within other sorts of lines, or even unknown parameters *within* a particular a-line that is otherwise known, the situation may be different. In such cases, what to do needs to be specified as part of the definition of that particular kind of line. Thanks, Paul On 5/17/2011 9:55 AM, Paul Kyzivat wrote: > > > On 5/17/2011 2:24 AM, Roni Even wrote: >> Hi Allyn, >> >> When the offer includes parameters that the answerer does not understand >> there are two options, he can ignore the unknown parameters or reject >> the offer. > > Rejecting the offer in that case is not really kosher. > You are required to ignore parameters you do not understand. > > If you reject something because you don't like the parameters it > contains, then that is an implicit statement that you understand those > parameters well enough to decide to reject them. > > Thanks, > Paul > >> If the answerer ignores the SDP parameters that he does not >> understand the remaining parameters should allow him to establish a >> media connection that will use the media stream that the offerer wants >> to be used in this case. One example is using potential configurations >> as specified in the MMUSIC media capability negotiation draft. >> >> Roni >> >> *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> *Sent:* Monday, May 16, 2011 9:54 PM >> *To:* bruno.chatras@orange-ftgroup.com; >> stephane.cazeaux@orange-ftgroup.com; Even.roni@huawei.com >> *Cc:* clue@ietf.org >> *Subject:* RE: [clue] legacy support in requirements >> >> HI Bruno and other folks interested in saying something about legacy in >> the requirements doc- >> >> Thanks for pointing out the distinction between proprietary extensions >> versus standard SIP compliant solutions. Also, I agree with you that Req >> #10 is aimed at CLUEful players, not devices that do not understand CLUE. >> >> Could you be a bit more specific about what you feel should be included >> in “legacy support”? >> >> Roni suggested, >> >> I am also missing a requirement for "legacy" system support like the >> solution MUST enable a system that does not support the mechanism to >> select the best set of streams to render (audio + video). >> >> I don’t quite get this in that a system that doesn’t support the CLUE >> mechanism cannot select streams, that’s the issue. I would assume that >> the interaction between a non-CLUE and a CLUE system would be the same >> as between 2 non-CLUE systems – they don’t interwork, but CLUE shouldn’t >> make the situation any worse. >> >> It would be great if you could suggest some wording that you would like >> to have added. >> >> Thanks, >> >> Allyn >> >> *From:*bruno.chatras@orange-ftgroup.com >> [mailto:bruno.chatras@orange-ftgroup.com] >> *Sent:* Wednesday, May 11, 2011 11:50 PM >> *To:* Allyn Romanow (allyn); stephane.cazeaux@orange-ftgroup.com; >> Even.roni@huawei.com >> *Cc:* clue@ietf.org >> *Subject:* RE: [clue] legacy support in requirements >> >> Hi, >> >> From previous discussions on the mailing list and at IETF#80 I >> understood that « non-standards compliant » was referring to solutions >> that make use of proprietary extensions (e.g. proprietary extensions to >> SDP or RTCP) while “legacy support” was referring to standard compliant >> solutions that do not understand the extensions that CLUE will specify >> (or request other groups to specify). The charter does not exclude the >> second case and Req# 10 is not specific enough. From the current text, >> one could understand that Req#10 applies to clue-compliant devices (i.e. >> devices that understand clue-defined extensions) with different >> capabilities, not to devices that do not understand clue extensions... >> >> BC >> >> *De :*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *De la part >> de* Allyn Romanow (allyn) >> *Envoyé :* jeudi 12 mai 2011 03:20 >> *À :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even >> *Cc :* CLUE >> *Objet :* [clue] legacy support in requirements >> >> Hi, >> >> You both asked to add a requirement for legacy support. However, the >> charter says >> >> “Interoperation with SIP and related standards for audio and video is >> required. However, backwards compatibility with existing >> non-standards compliant telepresence systems is not required.” >> >> On the basis of this, I think it would not be a good requirement to add. >> However, there is a requirement, 10, that addresses making it possible >> for endpoints with varying capabilities to interoperate in a >> telepresence conference. >> >> Regards, >> >> Allyn >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Even.roni@huawei.com Tue May 17 14:22:38 2011 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 68CFBE06DB for ; Tue, 17 May 2011 14:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqF-X9MfVB0f for ; Tue, 17 May 2011 14:22:37 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 23341E06C1 for ; Tue, 17 May 2011 14:22:36 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLC006THZDKWR@szxga04-in.huawei.com> for clue@ietf.org; Wed, 18 May 2011 05:22:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLC005N8ZDKGA@szxga04-in.huawei.com> for clue@ietf.org; Wed, 18 May 2011 05:22:32 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-18-153.red.bezeqint.net [79.181.18.153]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLC00EY4ZDBR0@szxml12-in.huawei.com>; Wed, 18 May 2011 05:22:32 +0800 (CST) Date: Wed, 18 May 2011 00:20:51 +0300 From: Roni Even In-reply-to: <4DD2901F.2000906@cisco.com> To: 'Paul Kyzivat' , 'Stephen Botzko' Message-id: <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwUpQYEWTmP8OU3Rlq5R2lVthLRVgAMy9EQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 21:22:38 -0000 Paul, Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, May 17, 2011 6:11 PM > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > On 5/17/2011 2:24 AM, Roni Even wrote: > > > When the offer includes parameters that the answerer does not > > understand > > there are two options, he can ignore the unknown parameters > or > > reject > > the offer. > > Rejecting the offer in that case is not really kosher. > > You are required to ignore parameters you do not understand. > > > > If you reject something because you don't like the parameters it > > contains, then that is an implicit statement that you understand > > those parameters well enough to decide to reject them. > > > > As far as I know, you are always free to reject offers, and it > doesn't > > really imply anything when you do that.. Whether it is wise is > perhaps > > a different question. > > Stephen Botzko > > Certainly you are always free to reject an offer. > In general I don't know for certain the reason why, and so if I give > you > the benefit of the doubt I will assume you have a valid reason - > perhaps > just policy. > > But if the reason you reject the offer is based on your violating a > spec, then you are non-conforming, whether I can determine you are > non-conforming or not. Whether being non-conforming is just un-wise, or > something stronger, is a separate discussion. The IETF does not levy > any > penalties for violating its specs. But sometimes the market does. (And > sometimes not.) But we don't need to endorse non-conforming behavior in > our documents. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Tue May 17 14:37:16 2011 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 989EBE06B1 for ; Tue, 17 May 2011 14:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 90utjz0QMGXo for ; Tue, 17 May 2011 14:37:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE3E0674 for ; Tue, 17 May 2011 14:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2637; q=dns/txt; s=iport; t=1305668236; x=1306877836; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FnrPAJ7A8JCAAyoi0iCg160Kq3GvnwnrEcIG9UonDRo=; b=DpiZ4+STOatqHPPn5kvNu6I9gs1ER92mYRf8ufUammbP5xwrK+30PY3C mUB0KPwvfLT2dJ/0uNx4A27NmbVx3CqysC9aGM4epkA7aRMiMMugYlhh/ c+tJEIJpvXcISGrgS3sHG26LI33QsdYw3gAZFSM+ArABwLsBI95gf4Xph c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBABvq0k2tJV2c/2dsb2JhbACXSI5Md6lIkB+NY4YZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,227,1304294400"; d="scan'208";a="356412495" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 17 May 2011 21:37:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4HLbEOA021142; Tue, 17 May 2011 21:37:15 GMT Message-ID: <4DD2EA8A.7070407@cisco.com> Date: Tue, 17 May 2011 17:37:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> In-Reply-To: <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 21:37:16 -0000 On 5/17/2011 5:20 PM, Roni Even wrote: > Paul, > Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example > Roni OK, I looked. It is consistent with what I said. Either a=group: is understood, or not. If not, its ignored, and not put in the answer. Same with a=mid: If a=group: *is* understood, but some parameter within it is not, there are explicit rules for what to do. AFAICT there are no examples in this document where failure to understand an a-line in total (or even in part) results in rejecting the offer. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, May 17, 2011 6:11 PM >> To: Stephen Botzko >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >> >>> On 5/17/2011 2:24 AM, Roni Even wrote: >> >>> When the offer includes parameters that the answerer does not >>> understand >>> there are two options, he can ignore the unknown parameters >> or >>> reject >>> the offer. >>> Rejecting the offer in that case is not really kosher. >>> You are required to ignore parameters you do not understand. >>> >>> If you reject something because you don't like the parameters it >>> contains, then that is an implicit statement that you understand >>> those parameters well enough to decide to reject them. >>> >>> As far as I know, you are always free to reject offers, and it >> doesn't >>> really imply anything when you do that.. Whether it is wise is >> perhaps >>> a different question. >>> Stephen Botzko >> >> Certainly you are always free to reject an offer. >> In general I don't know for certain the reason why, and so if I give >> you >> the benefit of the doubt I will assume you have a valid reason - >> perhaps >> just policy. >> >> But if the reason you reject the offer is based on your violating a >> spec, then you are non-conforming, whether I can determine you are >> non-conforming or not. Whether being non-conforming is just un-wise, or >> something stronger, is a separate discussion. The IETF does not levy >> any >> penalties for violating its specs. But sometimes the market does. (And >> sometimes not.) But we don't need to endorse non-conforming behavior in >> our documents. >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From Even.roni@huawei.com Tue May 17 15:07:18 2011 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 CF742E079E for ; Tue, 17 May 2011 15:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.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 6fv7pXkTH4Nu for ; Tue, 17 May 2011 15:07:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C5232E079C for ; Tue, 17 May 2011 15:07:17 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD0021M1G3NR@szxga05-in.huawei.com> for clue@ietf.org; Wed, 18 May 2011 06:07:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD00BMX1G271@szxga05-in.huawei.com> for clue@ietf.org; Wed, 18 May 2011 06:07:15 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-18-153.red.bezeqint.net [79.181.18.153]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLD00EH61FWR0@szxml12-in.huawei.com>; Wed, 18 May 2011 06:07:14 +0800 (CST) Date: Wed, 18 May 2011 01:05:37 +0300 From: Roni Even In-reply-to: <4DD2EA8A.7070407@cisco.com> To: 'Paul Kyzivat' Message-id: <01b501cc14de$9127c660$b3775320$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwU2po8oX13GU/mTFmfFDPhUPA/5gAAv/PQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 22:07:18 -0000 Paul, I think we read it differently. If the answerer does not support the group attribute and the offer had the fid semantics it may look to the answerer as an offer with multiple m-lines of the same media tyoe. In this case an implementation might also decide to refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable), because it contains several "m" lines of the same media type. This is very relevant to the multiple streams case and we should look if we state this behavior or we will look at providing an approach that will allow the answerer to choose one m-line that the offerer prefers even of it does not understand CLUE. Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 12:37 AM > To: Roni Even > Cc: 'Stephen Botzko'; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 5:20 PM, Roni Even wrote: > > Paul, > > Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example > > Roni > > OK, I looked. It is consistent with what I said. > Either a=group: is understood, or not. If not, its ignored, and not put > in the answer. Same with a=mid: > > If a=group: *is* understood, but some parameter within it is not, there > are explicit rules for what to do. > > AFAICT there are no examples in this document where failure to > understand an a-line in total (or even in part) results in rejecting > the > offer. > > Thanks, > Paul > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> Paul Kyzivat > >> Sent: Tuesday, May 17, 2011 6:11 PM > >> To: Stephen Botzko > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >> > >>> On 5/17/2011 2:24 AM, Roni Even wrote: > >> > >>> When the offer includes parameters that the answerer does > not > >>> understand > >>> there are two options, he can ignore the unknown > parameters > >> or > >>> reject > >>> the offer. > >>> Rejecting the offer in that case is not really kosher. > >>> You are required to ignore parameters you do not understand. > >>> > >>> If you reject something because you don't like the parameters > it > >>> contains, then that is an implicit statement that you > understand > >>> those parameters well enough to decide to reject them. > >>> > >>> As far as I know, you are always free to reject offers, and it > >> doesn't > >>> really imply anything when you do that.. Whether it is wise is > >> perhaps > >>> a different question. > >>> Stephen Botzko > >> > >> Certainly you are always free to reject an offer. > >> In general I don't know for certain the reason why, and so if I give > >> you > >> the benefit of the doubt I will assume you have a valid reason - > >> perhaps > >> just policy. > >> > >> But if the reason you reject the offer is based on your violating a > >> spec, then you are non-conforming, whether I can determine you are > >> non-conforming or not. Whether being non-conforming is just un-wise, > or > >> something stronger, is a separate discussion. The IETF does not levy > >> any > >> penalties for violating its specs. But sometimes the market does. > (And > >> sometimes not.) But we don't need to endorse non-conforming behavior > in > >> our documents. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From allyn@cisco.com Tue May 17 15:39:23 2011 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 17609E06F8 for ; Tue, 17 May 2011 15:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Xqt80fxJdKU1 for ; Tue, 17 May 2011 15:39:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id EA74FE06F3 for ; Tue, 17 May 2011 15:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4856; q=dns/txt; s=iport; t=1305671961; x=1306881561; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kEvN01HYB9yqqEwAKKNUf749SJK8EDTRH7qLAfLEsa8=; b=WPi7Osr0y8AZYL1UIw11AGqP2YADwb9M6zw0vH1CRuMatomYVMpW0feo LfwsmFfECn/FQcUd6WAX/4z0DqJ3n4O9Xt1BtKkfm5xMIB+OsnjL2qZRR YdstpQZjkGvJTrxv/APwyVbz6yRL/AZHHt5+tjmHGuxFcslh/YeTSUisr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAPb30k2rRDoI/2dsb2JhbACXSo5Md6l3kB+NZ4YZBIZQjXmKXQ X-IronPort-AV: E=Sophos;i="4.65,227,1304294400"; d="scan'208";a="699083957" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 17 May 2011 22:39:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4HMdLKO011368; Tue, 17 May 2011 22:39:21 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 15:39:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AM5p B8vV CA9N CcJC DRPx D70q E9VY Fguo HsMa Ia8E I6yf KAyp LWJs PFZh RIFz VGq+; 2; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAdgBlAG4ALgByAG8AbgBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {DC77B515-CDE4-4042-85B7-996E7105078A}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 17 May 2011 22:39:13 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAGwAZQBnAGEAYwB5ACAAcwB1AHAAcABvAHIAdAAgAGkAbgAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {DC77B515-CDE4-4042-85B7-996E7105078A} Content-class: urn:content-classes:message Date: Tue, 17 May 2011 15:39:13 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04655F49@xmb-sjc-221.amer.cisco.com> In-Reply-To: <01b501cc14de$9127c660$b3775320$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU2po8oX13GU/mTFmfFDPhUPA/5gAAv/PQAAFTgtA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 17 May 2011 22:39:21.0483 (UTC) FILETIME=[43D165B0:01CC14E3] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 22:39:23 -0000 I thought that we had agreed during the interim, and in meetings and conversations before the interim, that the requirements is not about particular protocols that may or may not be use to implement the solution. At first I thought you meant "offerer" "answerer" in some generic sense, but it looks like you mean more specifically to SDP. AFAIK, we aren't talking in the requirements about SDP in particular. Thanks, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Tuesday, May 17, 2011 3:06 PM > To: Paul Kyzivat (pkyzivat) > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Paul, > I think we read it differently. > If the answerer does not support the group attribute and the offer had > the > fid semantics it may look to the answerer as an offer with multiple m- > lines > of the same media tyoe. In this case an implementation might also > decide to > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > Acceptable), > because it contains several "m" lines of the same media type. > This is very relevant to the multiple streams case and we should look > if we > state this behavior or we will look at providing an approach that will > allow > the answerer to choose one m-line that the offerer prefers even of it > does > not understand CLUE. >=20 > Roni >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, May 18, 2011 12:37 AM > > To: Roni Even > > Cc: 'Stephen Botzko'; clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/17/2011 5:20 PM, Roni Even wrote: > > > Paul, > > > Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example > > > Roni > > > > OK, I looked. It is consistent with what I said. > > Either a=3Dgroup: is understood, or not. If not, its ignored, and = not > put > > in the answer. Same with a=3Dmid: > > > > If a=3Dgroup: *is* understood, but some parameter within it is not, > there > > are explicit rules for what to do. > > > > AFAICT there are no examples in this document where failure to > > understand an a-line in total (or even in part) results in rejecting > > the > > offer. > > > > Thanks, > > Paul > > > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 6:11 PM > > >> To: Stephen Botzko > > >> Cc: clue@ietf.org > > >> Subject: Re: [clue] legacy support in requirements > > >> > > >> > > >> > > >> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > >> > > >>> On 5/17/2011 2:24 AM, Roni Even wrote: > > >> > > >>> When the offer includes parameters that the answerer > does > > not > > >>> understand > > >>> there are two options, he can ignore the unknown > > parameters > > >> or > > >>> reject > > >>> the offer. > > >>> Rejecting the offer in that case is not really kosher. > > >>> You are required to ignore parameters you do not understand. > > >>> > > >>> If you reject something because you don't like the > parameters > > it > > >>> contains, then that is an implicit statement that you > > understand > > >>> those parameters well enough to decide to reject them. > > >>> > > >>> As far as I know, you are always free to reject offers, and it > > >> doesn't > > >>> really imply anything when you do that.. Whether it is wise is > > >> perhaps > > >>> a different question. > > >>> Stephen Botzko > > >> > > >> Certainly you are always free to reject an offer. > > >> In general I don't know for certain the reason why, and so if I > give > > >> you > > >> the benefit of the doubt I will assume you have a valid reason - > > >> perhaps > > >> just policy. > > >> > > >> But if the reason you reject the offer is based on your violating > a > > >> spec, then you are non-conforming, whether I can determine you are > > >> non-conforming or not. Whether being non-conforming is just un- > wise, > > or > > >> something stronger, is a separate discussion. The IETF does not > levy > > >> any > > >> penalties for violating its specs. But sometimes the market does. > > (And > > >> sometimes not.) But we don't need to endorse non-conforming > behavior > > in > > >> our documents. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Tue May 17 16:44:39 2011 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 86C76E06C1 for ; Tue, 17 May 2011 16:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 N7XGuQkVH1gl for ; Tue, 17 May 2011 16:44:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3D4E068E for ; Tue, 17 May 2011 16:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4840; q=dns/txt; s=iport; t=1305675878; x=1306885478; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dvJpQRImR+ZGzf+C5L4dJmjsQTe9YfsTWyu+jXwnHrI=; b=fNRHp9AhFM2FhpsxHmjSS14BLtnyEzBs/hcnP0GL9NsAUihTb5/W1O/O MPBxkRfPpDOqOxJQrbMURMv2szBkwDivNPLnjI4YtNFti7oPJmQsZNpHD FzD3LUegBhv/aMoqzjfKNnbFBCV4tNewFrXeZuIHJxLV/UtIZ8f9wPF+R U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBADwH002rRDoG/2dsb2JhbACXSo5Md4hwoFWQH41mhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,228,1304294400"; d="scan'208";a="359109894" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 17 May 2011 23:44:38 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4HNibJw009571; Tue, 17 May 2011 23:44:37 GMT Message-ID: <4DD30865.90103@cisco.com> Date: Tue, 17 May 2011 19:44:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> In-Reply-To: <01b501cc14de$9127c660$b3775320$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 23:44:39 -0000 On 5/17/2011 6:05 PM, Roni Even wrote: > Paul, > I think we read it differently. > If the answerer does not support the group attribute and the offer had the > fid semantics it may look to the answerer as an offer with multiple m-lines > of the same media tyoe. In this case an implementation might also decide to > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable), > because it contains several "m" lines of the same media type. That is a slightly different story. Then the reason for rejection is not because it saw an attribute it didn't understand - its because it didn't like something it *did* understand. > This is very relevant to the multiple streams case and we should look if we > state this behavior or we will look at providing an approach that will allow > the answerer to choose one m-line that the offerer prefers even of it does > not understand CLUE. IMO (lets see if others differ), if a UA receives an offer with at least one m-line it is happy with, then it should not reject the call because there are others that it does not "understand". Here "understand" means something different - presumably it does understand the direct meaning of the additional m-line, it just doesn't understand the *significance* or use of it. I see little difference to getting to audio m-lines and only wanting one, and getting one audio and one video and only supporting audio. In general you should not reject an audio/video call just because you only support audio. I think it will behoove clue to strongly recommend that the m-lines in an offer be arranged so the first ones are the ones it most wants used if not all are. Thanks, Paul > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, May 18, 2011 12:37 AM >> To: Roni Even >> Cc: 'Stephen Botzko'; clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 5:20 PM, Roni Even wrote: >>> Paul, >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example >>> Roni >> >> OK, I looked. It is consistent with what I said. >> Either a=group: is understood, or not. If not, its ignored, and not put >> in the answer. Same with a=mid: >> >> If a=group: *is* understood, but some parameter within it is not, there >> are explicit rules for what to do. >> >> AFAICT there are no examples in this document where failure to >> understand an a-line in total (or even in part) results in rejecting >> the >> offer. >> >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>>> Paul Kyzivat >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>> To: Stephen Botzko >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>> >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>> >>>>> When the offer includes parameters that the answerer does >> not >>>>> understand >>>>> there are two options, he can ignore the unknown >> parameters >>>> or >>>>> reject >>>>> the offer. >>>>> Rejecting the offer in that case is not really kosher. >>>>> You are required to ignore parameters you do not understand. >>>>> >>>>> If you reject something because you don't like the parameters >> it >>>>> contains, then that is an implicit statement that you >> understand >>>>> those parameters well enough to decide to reject them. >>>>> >>>>> As far as I know, you are always free to reject offers, and it >>>> doesn't >>>>> really imply anything when you do that.. Whether it is wise is >>>> perhaps >>>>> a different question. >>>>> Stephen Botzko >>>> >>>> Certainly you are always free to reject an offer. >>>> In general I don't know for certain the reason why, and so if I give >>>> you >>>> the benefit of the doubt I will assume you have a valid reason - >>>> perhaps >>>> just policy. >>>> >>>> But if the reason you reject the offer is based on your violating a >>>> spec, then you are non-conforming, whether I can determine you are >>>> non-conforming or not. Whether being non-conforming is just un-wise, >> or >>>> something stronger, is a separate discussion. The IETF does not levy >>>> any >>>> penalties for violating its specs. But sometimes the market does. >> (And >>>> sometimes not.) But we don't need to endorse non-conforming behavior >> in >>>> our documents. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> > > From pkyzivat@cisco.com Tue May 17 16:48:23 2011 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 50249E06C1 for ; Tue, 17 May 2011 16:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3afHOZVn9GoE for ; Tue, 17 May 2011 16:48:22 -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 C3F28E068E for ; Tue, 17 May 2011 16:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5310; q=dns/txt; s=iport; t=1305676101; x=1306885701; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=R5tfgfvjCs3oMAqYxvispeAAuCnKZqAphHo8C9LJ9AM=; b=Z8C3voUeXqIjto1i+ituAMgZKQA/EmWCrayDNSJ20EDFFxwytx/VEYiY RLrZvf8S7tIndPb8tKmzsdTPDCba0wFiXPMfSl7OfmAAj3SOQC81Y3Qzo 3VupXKwK9Mfs9EGOD2A/pR2hbLNalbpxYka5XWbwNh6rLiisl0ArP28Ss U=; X-IronPort-AV: E=Sophos;i="4.65,228,1304294400"; d="scan'208";a="30754828" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 17 May 2011 23:48:19 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4HNmH8W002928; Tue, 17 May 2011 23:48:17 GMT Message-ID: <4DD30940.2020304@cisco.com> Date: Tue, 17 May 2011 19:48:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04655F49@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04655F49@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 17 May 2011 23:48:23 -0000 On 5/17/2011 6:39 PM, Allyn Romanow (allyn) wrote: > I thought that we had agreed during the interim, and in meetings and > conversations before the interim, that the requirements is not about > particular protocols that may or may not be use to implement the > solution. > > At first I thought you meant "offerer" "answerer" in some generic sense, > but it looks like you mean more specifically to SDP. > AFAIK, we aren't talking in the requirements about SDP in particular. Its hard to talk about interoperation with vanilla sip devices without saying *something* about how offer/answer will play into it. I realize something other than SDP may be used for negotiating the clue-specific goodies, but at the end of the day there will need to be an INVITE and an SDP offer/answer exchange. (Unless you want to propose reviving SDPng :-) Thanks, Paul > Thanks, > Allyn > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Roni Even >> Sent: Tuesday, May 17, 2011 3:06 PM >> To: Paul Kyzivat (pkyzivat) >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> Paul, >> I think we read it differently. >> If the answerer does not support the group attribute and the offer had >> the >> fid semantics it may look to the answerer as an offer with multiple m- >> lines >> of the same media tyoe. In this case an implementation might also >> decide to >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >> Acceptable), >> because it contains several "m" lines of the same media type. >> This is very relevant to the multiple streams case and we should look >> if we >> state this behavior or we will look at providing an approach that will >> allow >> the answerer to choose one m-line that the offerer prefers even of it >> does >> not understand CLUE. >> >> Roni >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, May 18, 2011 12:37 AM >>> To: Roni Even >>> Cc: 'Stephen Botzko'; clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>> Paul, >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >> example >>>> Roni >>> >>> OK, I looked. It is consistent with what I said. >>> Either a=group: is understood, or not. If not, its ignored, and not >> put >>> in the answer. Same with a=mid: >>> >>> If a=group: *is* understood, but some parameter within it is not, >> there >>> are explicit rules for what to do. >>> >>> AFAICT there are no examples in this document where failure to >>> understand an a-line in total (or even in part) results in rejecting >>> the >>> offer. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> To: Stephen Botzko >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>> >>>>>> When the offer includes parameters that the answerer >> does >>> not >>>>>> understand >>>>>> there are two options, he can ignore the unknown >>> parameters >>>>> or >>>>>> reject >>>>>> the offer. >>>>>> Rejecting the offer in that case is not really kosher. >>>>>> You are required to ignore parameters you do not > understand. >>>>>> >>>>>> If you reject something because you don't like the >> parameters >>> it >>>>>> contains, then that is an implicit statement that you >>> understand >>>>>> those parameters well enough to decide to reject them. >>>>>> >>>>>> As far as I know, you are always free to reject offers, and it >>>>> doesn't >>>>>> really imply anything when you do that.. Whether it is wise is >>>>> perhaps >>>>>> a different question. >>>>>> Stephen Botzko >>>>> >>>>> Certainly you are always free to reject an offer. >>>>> In general I don't know for certain the reason why, and so if I >> give >>>>> you >>>>> the benefit of the doubt I will assume you have a valid reason - >>>>> perhaps >>>>> just policy. >>>>> >>>>> But if the reason you reject the offer is based on your violating >> a >>>>> spec, then you are non-conforming, whether I can determine you > are >>>>> non-conforming or not. Whether being non-conforming is just un- >> wise, >>> or >>>>> something stronger, is a separate discussion. The IETF does not >> levy >>>>> any >>>>> penalties for violating its specs. But sometimes the market does. >>> (And >>>>> sometimes not.) But we don't need to endorse non-conforming >> behavior >>> in >>>>> our documents. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Tue May 17 22:55:01 2011 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 7E487E069D for ; Tue, 17 May 2011 22:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcIW3iKUbHkY for ; Tue, 17 May 2011 22:55:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4716FE067C for ; Tue, 17 May 2011 22:54:59 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-ce-4dd35f3123ca Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.A3.30428.13F53DD4; Wed, 18 May 2011 07:54:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 18 May 2011 07:54:57 +0200 From: Christer Holmberg To: Paul Kyzivat , Roni Even Date: Wed, 18 May 2011 07:54:56 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7GZ/Rnxcff9yQQKroYPvoAT9YgALtTyw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E185BC9@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> In-Reply-To: <4DD30865.90103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 05:55:01 -0000 Hi, I agree with Paul. However, we need to remember that, using feature tags, the OPTIONS method e= tc, it is possible to figure out what capabilities entities support, before= sending SDP offers etc to them. Regards, Christer =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 18. toukokuuta 2011 2:45 > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 >=20 >=20 > On 5/17/2011 6:05 PM, Roni Even wrote: > > Paul, > > I think we read it differently. > > If the answerer does not support the group attribute and=20 > the offer had=20 > > the fid semantics it may look to the answerer as an offer with=20 > > multiple m-lines of the same media tyoe. In this case an=20 > > implementation might also decide to refuse the request=20 > (e.g., 488 Not=20 > > Acceptable Here, or 606 Not Acceptable), because it=20 > contains several "m" lines of the same media type. >=20 > That is a slightly different story. >=20 > Then the reason for rejection is not because it saw an=20 > attribute it didn't understand - its because it didn't like=20 > something it *did* understand. >=20 > > This is very relevant to the multiple streams case and we=20 > should look=20 > > if we state this behavior or we will look at providing an approach=20 > > that will allow the answerer to choose one m-line that the offerer=20 > > prefers even of it does not understand CLUE. >=20 > IMO (lets see if others differ), if a UA receives an offer=20 > with at least one m-line it is happy with, then it should not=20 > reject the call because there are others that it does not=20 > "understand". >=20 > Here "understand" means something different - presumably it=20 > does understand the direct meaning of the additional m-line,=20 > it just doesn't understand the *significance* or use of it. >=20 > I see little difference to getting to audio m-lines and only=20 > wanting one, and getting one audio and one video and only=20 > supporting audio. In general you should not reject an=20 > audio/video call just because you only support audio. >=20 > I think it will behoove clue to strongly recommend that the=20 > m-lines in an offer be arranged so the first ones are the=20 > ones it most wants used if not all are. >=20 > Thanks, > Paul >=20 > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, May 18, 2011 12:37 AM > >> To: Roni Even > >> Cc: 'Stephen Botzko'; clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> Paul, > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2=20 > for example=20 > >>> Roni > >> > >> OK, I looked. It is consistent with what I said. > >> Either a=3Dgroup: is understood, or not. If not, its=20 > ignored, and not=20 > >> put in the answer. Same with a=3Dmid: > >> > >> If a=3Dgroup: *is* understood, but some parameter within it is not,=20 > >> there are explicit rules for what to do. > >> > >> AFAICT there are no examples in this document where failure to=20 > >> understand an a-line in total (or even in part) results in=20 > rejecting=20 > >> the offer. > >> > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >>>> Behalf > >> Of > >>>> Paul Kyzivat > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>> To: Stephen Botzko > >>>> Cc: clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>>> > >>>> > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>> > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>> > >>>>> When the offer includes parameters that the answerer=20 > >>>>> does > >> not > >>>>> understand > >>>>> there are two options, he can ignore the unknown > >> parameters > >>>> or > >>>>> reject > >>>>> the offer. > >>>>> Rejecting the offer in that case is not really kosher. > >>>>> You are required to ignore parameters you do not=20 > understand. > >>>>> > >>>>> If you reject something because you don't like the=20 > >>>>> parameters > >> it > >>>>> contains, then that is an implicit statement that you > >> understand > >>>>> those parameters well enough to decide to reject them. > >>>>> > >>>>> As far as I know, you are always free to reject offers, and it > >>>> doesn't > >>>>> really imply anything when you do that.. Whether it is wise is > >>>> perhaps > >>>>> a different question. > >>>>> Stephen Botzko > >>>> > >>>> Certainly you are always free to reject an offer. > >>>> In general I don't know for certain the reason why, and so if I=20 > >>>> give you the benefit of the doubt I will assume you have a valid=20 > >>>> reason - perhaps just policy. > >>>> > >>>> But if the reason you reject the offer is based on your=20 > violating a=20 > >>>> spec, then you are non-conforming, whether I can=20 > determine you are=20 > >>>> non-conforming or not. Whether being non-conforming is just=20 > >>>> un-wise, > >> or > >>>> something stronger, is a separate discussion. The IETF does not=20 > >>>> levy any penalties for violating its specs. But sometimes the=20 > >>>> market does. > >> (And > >>>> sometimes not.) But we don't need to endorse non-conforming=20 > >>>> behavior > >> in > >>>> our documents. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From christer.holmberg@ericsson.com Tue May 17 23:20:35 2011 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 37019E069D for ; Tue, 17 May 2011 23:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciKj9GGLM64Z for ; Tue, 17 May 2011 23:20:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79A80E067C for ; Tue, 17 May 2011 23:20:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c86ae000000b90-a4-4dd36530d55f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 61.5D.02960.03563DD4; Wed, 18 May 2011 08:20:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 18 May 2011 08:20:32 +0200 From: Christer Holmberg To: Stephan Wenger , CLUE Date: Wed, 18 May 2011 08:20:32 +0200 Thread-Topic: Definitions Thread-Index: AcwRTUgjWTR2QLxJQ46VPyDzRMaFEAD1jg6A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E185BE3@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Definitions 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, 18 May 2011 06:20:35 -0000 Hi, =20 Regarding "Session - RTP session". I think we need to be explicit when we t= alk about sessions, because we are also most likely going to talk about SIP= sessions. Regards, Christer ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of St= ephan Wenger Sent: 13. toukokuuta 2011 21:08 To: CLUE Subject: [clue] Definitions =09 =09 Hi folks, Here a VERY rough initial draft. Addressing typos, sorting to alphabetica= l, and other cleanup tasks will have to wait for the my return to the offic= e next week. I will submit officially only after the most embarrassing bug= s are sorted out. No need to comment on typos, but if you have substantial= issues then send them now, and I can address them immediately. Stephan From john.elwell@siemens-enterprise.com Tue May 17 23:25:54 2011 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 6A20AE06B2 for ; Tue, 17 May 2011 23:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ETQXMtq8DyoR for ; Tue, 17 May 2011 23:25:53 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 24A8AE067C for ; Tue, 17 May 2011 23:25:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1305699951!6287655!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 30789 invoked from network); 18 May 2011 06:25:51 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-182.messagelabs.com with SMTP; 18 May 2011 06:25:51 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id A619323F03E6; Wed, 18 May 2011 08:25:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 18 May 2011 08:25:51 +0200 From: "Elwell, John" To: Paul Kyzivat , Roni Even Date: Wed, 18 May 2011 08:25:50 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7GVFhA+6weSOQ22Fc2TuYu9BJQAN//Rg Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> In-Reply-To: <4DD30865.90103@cisco.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 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 06:25:54 -0000 I agree with Paul's interpretation. John=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 18 May 2011 00:45 > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 >=20 >=20 > On 5/17/2011 6:05 PM, Roni Even wrote: > > Paul, > > I think we read it differently. > > If the answerer does not support the group attribute and=20 > the offer had the > > fid semantics it may look to the answerer as an offer with=20 > multiple m-lines > > of the same media tyoe. In this case an implementation=20 > might also decide to > > refuse the request (e.g., 488 Not Acceptable Here, or 606=20 > Not Acceptable), > > because it contains several "m" lines of the same media type. >=20 > That is a slightly different story. >=20 > Then the reason for rejection is not because it saw an attribute it=20 > didn't understand - its because it didn't like something it *did*=20 > understand. >=20 > > This is very relevant to the multiple streams case and we=20 > should look if we > > state this behavior or we will look at providing an=20 > approach that will allow > > the answerer to choose one m-line that the offerer prefers=20 > even of it does > > not understand CLUE. >=20 > IMO (lets see if others differ), if a UA receives an offer=20 > with at least=20 > one m-line it is happy with, then it should not reject the=20 > call because=20 > there are others that it does not "understand". >=20 > Here "understand" means something different - presumably it does=20 > understand the direct meaning of the additional m-line, it=20 > just doesn't=20 > understand the *significance* or use of it. >=20 > I see little difference to getting to audio m-lines and only wanting=20 > one, and getting one audio and one video and only supporting=20 > audio. In=20 > general you should not reject an audio/video call just=20 > because you only=20 > support audio. >=20 > I think it will behoove clue to strongly recommend that the=20 > m-lines in=20 > an offer be arranged so the first ones are the ones it most=20 > wants used=20 > if not all are. >=20 > Thanks, > Paul >=20 > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, May 18, 2011 12:37 AM > >> To: Roni Even > >> Cc: 'Stephen Botzko'; clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> Paul, > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2=20 > for example > >>> Roni > >> > >> OK, I looked. It is consistent with what I said. > >> Either a=3Dgroup: is understood, or not. If not, its=20 > ignored, and not put > >> in the answer. Same with a=3Dmid: > >> > >> If a=3Dgroup: *is* understood, but some parameter within it=20 > is not, there > >> are explicit rules for what to do. > >> > >> AFAICT there are no examples in this document where failure to > >> understand an a-line in total (or even in part) results in=20 > rejecting > >> the > >> offer. > >> > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > >> Of > >>>> Paul Kyzivat > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>> To: Stephen Botzko > >>>> Cc: clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>>> > >>>> > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>> > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>> > >>>>> When the offer includes parameters that the=20 > answerer does > >> not > >>>>> understand > >>>>> there are two options, he can ignore the unknown > >> parameters > >>>> or > >>>>> reject > >>>>> the offer. > >>>>> Rejecting the offer in that case is not really kosher. > >>>>> You are required to ignore parameters you do not=20 > understand. > >>>>> > >>>>> If you reject something because you don't like=20 > the parameters > >> it > >>>>> contains, then that is an implicit statement that you > >> understand > >>>>> those parameters well enough to decide to reject them. > >>>>> > >>>>> As far as I know, you are always free to reject offers, and it > >>>> doesn't > >>>>> really imply anything when you do that.. Whether it is wise is > >>>> perhaps > >>>>> a different question. > >>>>> Stephen Botzko > >>>> > >>>> Certainly you are always free to reject an offer. > >>>> In general I don't know for certain the reason why, and=20 > so if I give > >>>> you > >>>> the benefit of the doubt I will assume you have a valid reason - > >>>> perhaps > >>>> just policy. > >>>> > >>>> But if the reason you reject the offer is based on your=20 > violating a > >>>> spec, then you are non-conforming, whether I can=20 > determine you are > >>>> non-conforming or not. Whether being non-conforming is=20 > just un-wise, > >> or > >>>> something stronger, is a separate discussion. The IETF=20 > does not levy > >>>> any > >>>> penalties for violating its specs. But sometimes the market does. > >> (And > >>>> sometimes not.) But we don't need to endorse=20 > non-conforming behavior > >> in > >>>> our documents. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From espeberg@cisco.com Wed May 18 01:40:27 2011 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 BC176E07A8 for ; Wed, 18 May 2011 01:40:27 -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 f0jqSzQrVp11 for ; Wed, 18 May 2011 01:40:21 -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 7C839E069E for ; Wed, 18 May 2011 01:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4486; q=dns/txt; s=iport; t=1305708021; x=1306917621; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=s70133CSpGUdJzMr1TgpAg3x8dHBO9MeIGlE7p3s+ZI=; b=jWCRFZ77uE8zS1p624tIwvmqF/XGndOvoyB/TSnNLvYGcb6x70xQlJVw aY6y+HLOnAu94XIrdO30Jv8dd6VleqCkCZF2BhKbb7Tw6JgWlsxHDTnHz YM1lSpx+z5MJPm4uTKjY6J7+YRQv91tiQFrQzXZgR3m0rE97CvEWrMeFJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAALOF002Q/khNgWdsb2JhbACXTI5MFAEBFiYliHChFp4KhhkElEmKPw X-IronPort-AV: E=Sophos;i="4.65,230,1304294400"; d="scan'208";a="30843978" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 May 2011 08:40:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4I8eK8H022717; Wed, 18 May 2011 08:40:20 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 10:40:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 10:40:19 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E64564C@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions Thread-Index: AcwUlNO6aR+SpJqaSNe0MlOM+ltgDgAm3S3w References: From: "Espen Berger (espeberg)" To: "Stephan Wenger" , "Charles Eckel (eckelcu)" , "CLUE" X-OriginalArrivalTime: 18 May 2011 08:40:20.0409 (UTC) FILETIME=[389CDA90:01CC1537] Subject: Re: [clue] Definitions 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, 18 May 2011 08:40:27 -0000 I think we should keep both endpoints and MCUs in the definition document.=20 One difference between endpoints and MCUs are how they handle media. An endpoint usually send media representing itself and MCUs send media on behalf of others remote endpoint connected.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 17. mai 2011 06:17 To: Charles Eckel (eckelcu); CLUE Subject: Re: [clue] Definitions Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D = endpoint >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. >=20 > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >>=20 >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephane.cazeaux@orange-ftgroup.com Wed May 18 03:46:40 2011 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 4E276E0714 for ; Wed, 18 May 2011 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 fUoVRCZrxDOs for ; Wed, 18 May 2011 03:46:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 449A6E06C9 for ; Wed, 18 May 2011 03:46:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9665C8D0002; Wed, 18 May 2011 12:47:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8B44E8D0001; Wed, 18 May 2011 12:47:16 +0200 (CEST) Received: from ftrdhub1.rd.francetelecom.fr ([10.193.109.193]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 12:46:37 +0200 Received: from FTRDCH02.rd.francetelecom.fr (10.194.32.13) by ftrdhub1.rd.francetelecom.fr (10.193.109.193) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 12:46:36 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Wed, 18 May 2011 12:46:36 +0200 From: To: , , , Thread-Topic: [clue] Definitions Thread-Index: AcwUlNO6146t/LGk30ms//XJA7T93AAm3S3wAAME7UA= Date: Wed, 18 May 2011 10:46:35 +0000 Message-ID: References: <92DF9533227FC14F946C7321074B8C9E64564C@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E64564C@XMB-AMS-214.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 May 2011 10:46:37.0898 (UTC) FILETIME=[DD25EAA0:01CC1548] Subject: Re: [clue] Definitions 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, 18 May 2011 10:46:40 -0000 I don't think that we want to limit the "endpoint" definition to entities f= acing a user. We could have entities not facing a user (e.g. an automata), = but which are sending/receiving media, and which need to understand charact= eristics of the remote, and could maybe have also some characteristics. I d= on't think we want to exclude such cases. Relying on the "participant" definition of RFC4353, a telepresence conferen= ce will be composed of "participants", where a participant is connected to = the conference through an "endpoint". In telepresence, the participant will= have to be aware of the endpoint, in particular when the participant needs= to inform the remote of the characteristics of its endpoint. Thus my proposition is to clarify that "endpoint" defines the entity throug= h which a participant (we do not limit to entity facing a user) is connecte= d to a telepresence conference. In the same manner, we could also use the "mixer" word instead of "MCU". Most of requirements should then apply on the participant or mixer (typical= ly, a participant will describe characteristics of its endpoint). Regards, Stephane. -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de E= spen Berger (espeberg) Envoy=E9=A0: mercredi 18 mai 2011 10:40 =C0=A0: Stephan Wenger; Charles Eckel (eckelcu); CLUE Objet=A0: Re: [clue] Definitions I think we should keep both endpoints and MCUs in the definition document.=20 One difference between endpoints and MCUs are how they handle media. An endpoint usually send media representing itself and MCUs send media on behalf of others remote endpoint connected.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 17. mai 2011 06:17 To: Charles Eckel (eckelcu); CLUE Subject: Re: [clue] Definitions Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoin= t >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. >=20 > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >>=20 >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Wed May 18 05:36:59 2011 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 1BAD7E06EA for ; Wed, 18 May 2011 05:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yyLL34jbQkKq for ; Wed, 18 May 2011 05:36:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B009BE0689 for ; Wed, 18 May 2011 05:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6375; q=dns/txt; s=iport; t=1305722217; x=1306931817; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=A7Gx6/HnUnQrH/XUCNNfVhQyxGSU9YUYY46XmZzo9U4=; b=nGK5TwcMsViUeEpul/YrQDX5ZkCpPtoc2HQU1P0ZtCsJfswDZqJUxp5u Yf/Y8k7qExUyuXWedqojFK7t181iu3sMotdTqPpweawSA1pL3iUpyXYJe C+PuD3SYDS2qV/03lsnwt8XDgLA4tALfQBvpBLcZm2mt9MIBM+kwhZ2Ir g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAMi8002tJV2Z/2dsb2JhbACXTI5Ld4hwoHKQH41whhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,231,1304294400"; d="scan'208";a="359483540" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 18 May 2011 12:36:57 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4ICauXV018183; Wed, 18 May 2011 12:36:56 GMT Message-ID: <4DD3BD68.9020700@cisco.com> Date: Wed, 18 May 2011 08:36:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E185BC9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E185BC9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 12:36:59 -0000 On 5/18/2011 1:54 AM, Christer Holmberg wrote: > > Hi, > > I agree with Paul. > > However, we need to remember that, using feature tags, the OPTIONS method etc, it is possible to figure out what capabilities entities support, before sending SDP offers etc to them. That can work in some cases, but its difficult to use in general. Forking or otherwise routing calls to different UAs can make it problematic to poll a device before calling it. And it can just be inconvenient to the point that callers won't want to do it. IMO one should strive to arrange so that the call works the first time, with possibly some negotiation after to reach the most optimal configuration of that call. Thanks, Paul > Regards, > > Christer > > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 18. toukokuuta 2011 2:45 >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 6:05 PM, Roni Even wrote: >>> Paul, >>> I think we read it differently. >>> If the answerer does not support the group attribute and >> the offer had >>> the fid semantics it may look to the answerer as an offer with >>> multiple m-lines of the same media tyoe. In this case an >>> implementation might also decide to refuse the request >> (e.g., 488 Not >>> Acceptable Here, or 606 Not Acceptable), because it >> contains several "m" lines of the same media type. >> >> That is a slightly different story. >> >> Then the reason for rejection is not because it saw an >> attribute it didn't understand - its because it didn't like >> something it *did* understand. >> >>> This is very relevant to the multiple streams case and we >> should look >>> if we state this behavior or we will look at providing an approach >>> that will allow the answerer to choose one m-line that the offerer >>> prefers even of it does not understand CLUE. >> >> IMO (lets see if others differ), if a UA receives an offer >> with at least one m-line it is happy with, then it should not >> reject the call because there are others that it does not >> "understand". >> >> Here "understand" means something different - presumably it >> does understand the direct meaning of the additional m-line, >> it just doesn't understand the *significance* or use of it. >> >> I see little difference to getting to audio m-lines and only >> wanting one, and getting one audio and one video and only >> supporting audio. In general you should not reject an >> audio/video call just because you only support audio. >> >> I think it will behoove clue to strongly recommend that the >> m-lines in an offer be arranged so the first ones are the >> ones it most wants used if not all are. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>> To: Roni Even >>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> Paul, >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 >> for example >>>>> Roni >>>> >>>> OK, I looked. It is consistent with what I said. >>>> Either a=group: is understood, or not. If not, its >> ignored, and not >>>> put in the answer. Same with a=mid: >>>> >>>> If a=group: *is* understood, but some parameter within it is not, >>>> there are explicit rules for what to do. >>>> >>>> AFAICT there are no examples in this document where failure to >>>> understand an a-line in total (or even in part) results in >> rejecting >>>> the offer. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> To: Stephen Botzko >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>> >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>> >>>>>>> When the offer includes parameters that the answerer >>>>>>> does >>>> not >>>>>>> understand >>>>>>> there are two options, he can ignore the unknown >>>> parameters >>>>>> or >>>>>>> reject >>>>>>> the offer. >>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>> You are required to ignore parameters you do not >> understand. >>>>>>> >>>>>>> If you reject something because you don't like the >>>>>>> parameters >>>> it >>>>>>> contains, then that is an implicit statement that you >>>> understand >>>>>>> those parameters well enough to decide to reject them. >>>>>>> >>>>>>> As far as I know, you are always free to reject offers, and it >>>>>> doesn't >>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>> perhaps >>>>>>> a different question. >>>>>>> Stephen Botzko >>>>>> >>>>>> Certainly you are always free to reject an offer. >>>>>> In general I don't know for certain the reason why, and so if I >>>>>> give you the benefit of the doubt I will assume you have a valid >>>>>> reason - perhaps just policy. >>>>>> >>>>>> But if the reason you reject the offer is based on your >> violating a >>>>>> spec, then you are non-conforming, whether I can >> determine you are >>>>>> non-conforming or not. Whether being non-conforming is just >>>>>> un-wise, >>>> or >>>>>> something stronger, is a separate discussion. The IETF does not >>>>>> levy any penalties for violating its specs. But sometimes the >>>>>> market does. >>>> (And >>>>>> sometimes not.) But we don't need to endorse non-conforming >>>>>> behavior >>>> in >>>>>> our documents. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> From christer.holmberg@ericsson.com Wed May 18 05:50:46 2011 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 9DD37E071F for ; Wed, 18 May 2011 05:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSyk0sMk8xxN for ; Wed, 18 May 2011 05:50:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA14E06FA for ; Wed, 18 May 2011 05:50:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f1-4dd3c0a31068 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 80.3F.09774.3A0C3DD4; Wed, 18 May 2011 14:50:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 18 May 2011 14:50:43 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 18 May 2011 14:50:42 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwVWEh0bObb2fFOThCjbskTa2pTXgAAUoZg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E1D4893@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E185BC9@ESESSCMS0356.eemea.ericsson.se> <4DD3BD68.9020700@cisco.com> In-Reply-To: <4DD3BD68.9020700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 12:50:46 -0000 Hi,=20 >>>I agree with Paul. >>> >>>However, we need to remember that, using feature tags, the=20 >>>OPTIONS method etc, it is possible to figure out what=20 >>>capabilities entities support, before sending SDP offers etc to them. >>=20 >>That can work in some cases, but its difficult to use in general. >Forking or otherwise routing calls to different UAs can make=20 >it problematic to poll a device before calling it. I have presented a solution to handle forking and routing calls to differen= t UAs :) >And it can just be inconvenient to the point that callers won't want to do= it. Sure. But, in scenarios with intermediaries they can also take care of it. >IMO one should strive to arrange so that the call works the=20 >first time, with possibly some negotiation after to reach the=20 >most optimal configuration of that call. I agree. I do have a feeling it may not work, though. Because, it's not onl= y about the number of m- lines etc, it is also about usage of multiplexing = etc WITHIN an m- line. Regards, Christer > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 > On Behalf=20 > >> Of Paul Kyzivat > >> Sent: 18. toukokuuta 2011 2:45 > >> To: Roni Even > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 6:05 PM, Roni Even wrote: > >>> Paul, > >>> I think we read it differently. > >>> If the answerer does not support the group attribute and > >> the offer had > >>> the fid semantics it may look to the answerer as an offer with=20 > >>> multiple m-lines of the same media tyoe. In this case an=20 > >>> implementation might also decide to refuse the request > >> (e.g., 488 Not > >>> Acceptable Here, or 606 Not Acceptable), because it > >> contains several "m" lines of the same media type. > >> > >> That is a slightly different story. > >> > >> Then the reason for rejection is not because it saw an=20 > attribute it=20 > >> didn't understand - its because it didn't like something it *did*=20 > >> understand. > >> > >>> This is very relevant to the multiple streams case and we > >> should look > >>> if we state this behavior or we will look at providing an=20 > approach=20 > >>> that will allow the answerer to choose one m-line that=20 > the offerer=20 > >>> prefers even of it does not understand CLUE. > >> > >> IMO (lets see if others differ), if a UA receives an offer with at=20 > >> least one m-line it is happy with, then it should not=20 > reject the call=20 > >> because there are others that it does not "understand". > >> > >> Here "understand" means something different - presumably it does=20 > >> understand the direct meaning of the additional m-line, it just=20 > >> doesn't understand the *significance* or use of it. > >> > >> I see little difference to getting to audio m-lines and=20 > only wanting=20 > >> one, and getting one audio and one video and only=20 > supporting audio.=20 > >> In general you should not reject an audio/video call just=20 > because you=20 > >> only support audio. > >> > >> I think it will behoove clue to strongly recommend that=20 > the m-lines=20 > >> in an offer be arranged so the first ones are the ones it=20 > most wants=20 > >> used if not all are. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Wednesday, May 18, 2011 12:37 AM > >>>> To: Roni Even > >>>> Cc: 'Stephen Botzko'; clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>>> > >>>> > >>>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>>> Paul, > >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 > >> for example > >>>>> Roni > >>>> > >>>> OK, I looked. It is consistent with what I said. > >>>> Either a=3Dgroup: is understood, or not. If not, its > >> ignored, and not > >>>> put in the answer. Same with a=3Dmid: > >>>> > >>>> If a=3Dgroup: *is* understood, but some parameter within=20 > it is not,=20 > >>>> there are explicit rules for what to do. > >>>> > >>>> AFAICT there are no examples in this document where failure to=20 > >>>> understand an a-line in total (or even in part) results in > >> rejecting > >>>> the offer. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >>>>>> Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>>> To: Stephen Botzko > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>>> > >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>>> > >>>>>>> When the offer includes parameters that=20 > the answerer=20 > >>>>>>> does > >>>> not > >>>>>>> understand > >>>>>>> there are two options, he can ignore the unknown > >>>> parameters > >>>>>> or > >>>>>>> reject > >>>>>>> the offer. > >>>>>>> Rejecting the offer in that case is not really kosher. > >>>>>>> You are required to ignore parameters you do not > >> understand. > >>>>>>> > >>>>>>> If you reject something because you don't like the=20 > >>>>>>> parameters > >>>> it > >>>>>>> contains, then that is an implicit statement that you > >>>> understand > >>>>>>> those parameters well enough to decide to reject them. > >>>>>>> > >>>>>>> As far as I know, you are always free to reject offers, and it > >>>>>> doesn't > >>>>>>> really imply anything when you do that.. Whether it=20 > is wise is > >>>>>> perhaps > >>>>>>> a different question. > >>>>>>> Stephen Botzko > >>>>>> > >>>>>> Certainly you are always free to reject an offer. > >>>>>> In general I don't know for certain the reason why,=20 > and so if I=20 > >>>>>> give you the benefit of the doubt I will assume you=20 > have a valid=20 > >>>>>> reason - perhaps just policy. > >>>>>> > >>>>>> But if the reason you reject the offer is based on your > >> violating a > >>>>>> spec, then you are non-conforming, whether I can > >> determine you are > >>>>>> non-conforming or not. Whether being non-conforming is just=20 > >>>>>> un-wise, > >>>> or > >>>>>> something stronger, is a separate discussion. The IETF=20 > does not=20 > >>>>>> levy any penalties for violating its specs. But sometimes the=20 > >>>>>> market does. > >>>> (And > >>>>>> sometimes not.) But we don't need to endorse non-conforming=20 > >>>>>> behavior > >>>> in > >>>>>> our documents. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>> > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > = From hmmr@cisco.com Wed May 18 06:41:14 2011 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 8180FE06C5 for ; Wed, 18 May 2011 06:41:14 -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 EzLjw+xfZsRX for ; Wed, 18 May 2011 06:41:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 94C22E06A8 for ; Wed, 18 May 2011 06:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=5686; q=dns/txt; s=iport; t=1305726073; x=1306935673; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bw1DZpaUsAoKnDxgrohcuSjcsi+1OnsMVU4iX8Rp1Ts=; b=Pq7vKzcbEgVpgokGSQYEYpnvodfUuFjl0pT9bQAv07kgJHuUT3M4loug oZsmXxjfrLEzNhrurzmADXEiVvb+QIsk0BDO1nl9uSz1t7dEwgL9Q2Bxv 7mVS6cLo+2d5nJDF4/i00jH0239AhIJqcBeT3PF1GiTo/6lpYjQygIala o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAE3M002tJV2d/2dsb2JhbACXTI5Md4hwoHqQH41qhhkEhlCNeYpb Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 18 May 2011 13:41:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4IDf7Bh002295; Wed, 18 May 2011 13:41:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 08:41:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 08:41:05 -0500 Message-ID: In-Reply-To: <4DD30865.90103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" , "Roni Even" X-OriginalArrivalTime: 18 May 2011 13:41:06.0922 (UTC) FILETIME=[3D2C34A0:01CC1561] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 13:41:14 -0000 Paul, I would agree that if the offer-answer model semantic is that here are several options and any subset of options is acceptable. However, if there is any grouping involved such that you need to have a video and audio feed integrated to make sense then watch out. For example, I wouldn't want to end up with the result of a man's video paired with a woman's voice. That could be rather comical. Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, May 17, 2011 7:45 PM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements On 5/17/2011 6:05 PM, Roni Even wrote: > Paul, > I think we read it differently. > If the answerer does not support the group attribute and the offer had the > fid semantics it may look to the answerer as an offer with multiple m-lines > of the same media tyoe. In this case an implementation might also decide to > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable), > because it contains several "m" lines of the same media type. That is a slightly different story. Then the reason for rejection is not because it saw an attribute it=20 didn't understand - its because it didn't like something it *did*=20 understand. > This is very relevant to the multiple streams case and we should look if we > state this behavior or we will look at providing an approach that will allow > the answerer to choose one m-line that the offerer prefers even of it does > not understand CLUE. IMO (lets see if others differ), if a UA receives an offer with at least one m-line it is happy with, then it should not reject the call because=20 there are others that it does not "understand". Here "understand" means something different - presumably it does=20 understand the direct meaning of the additional m-line, it just doesn't=20 understand the *significance* or use of it. I see little difference to getting to audio m-lines and only wanting=20 one, and getting one audio and one video and only supporting audio. In=20 general you should not reject an audio/video call just because you only=20 support audio. I think it will behoove clue to strongly recommend that the m-lines in=20 an offer be arranged so the first ones are the ones it most wants used=20 if not all are. Thanks, Paul > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, May 18, 2011 12:37 AM >> To: Roni Even >> Cc: 'Stephen Botzko'; clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 5:20 PM, Roni Even wrote: >>> Paul, >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example >>> Roni >> >> OK, I looked. It is consistent with what I said. >> Either a=3Dgroup: is understood, or not. If not, its ignored, and not put >> in the answer. Same with a=3Dmid: >> >> If a=3Dgroup: *is* understood, but some parameter within it is not, there >> are explicit rules for what to do. >> >> AFAICT there are no examples in this document where failure to >> understand an a-line in total (or even in part) results in rejecting >> the >> offer. >> >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>>> Paul Kyzivat >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>> To: Stephen Botzko >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>> >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>> >>>>> When the offer includes parameters that the answerer does >> not >>>>> understand >>>>> there are two options, he can ignore the unknown >> parameters >>>> or >>>>> reject >>>>> the offer. >>>>> Rejecting the offer in that case is not really kosher. >>>>> You are required to ignore parameters you do not understand. >>>>> >>>>> If you reject something because you don't like the parameters >> it >>>>> contains, then that is an implicit statement that you >> understand >>>>> those parameters well enough to decide to reject them. >>>>> >>>>> As far as I know, you are always free to reject offers, and it >>>> doesn't >>>>> really imply anything when you do that.. Whether it is wise is >>>> perhaps >>>>> a different question. >>>>> Stephen Botzko >>>> >>>> Certainly you are always free to reject an offer. >>>> In general I don't know for certain the reason why, and so if I give >>>> you >>>> the benefit of the doubt I will assume you have a valid reason - >>>> perhaps >>>> just policy. >>>> >>>> But if the reason you reject the offer is based on your violating a >>>> spec, then you are non-conforming, whether I can determine you are >>>> non-conforming or not. Whether being non-conforming is just un-wise, >> or >>>> something stronger, is a separate discussion. The IETF does not levy >>>> any >>>> penalties for violating its specs. But sometimes the market does. >> (And >>>> sometimes not.) But we don't need to endorse non-conforming behavior >> in >>>> our documents. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Wed May 18 08:00:09 2011 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 ED40AE075D for ; Wed, 18 May 2011 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_QP_LONG_LINE=1.396] 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 Ven+BWr+kJtQ for ; Wed, 18 May 2011 08:00:08 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1AE075C for ; Wed, 18 May 2011 08:00:06 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2382-1743317 for multiple; Wed, 18 May 2011 17:00:05 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 18 May 2011 07:59:57 +0200 From: Stephan Wenger To: , , , Message-ID: Thread-Topic: [clue] Definitions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions 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, 18 May 2011 15:00:10 -0000 Hi Stephane, Very good point. Quoting from RFC 4353 [...] =20 Participant: The software element that connects a user or automata to a conference. It implements, at a minimum, a SIP user agent, but may also implement non-SIP-specific mechanisms for additional functionality. [...] My understanding of "endpoint" is that an endpoint encompasses ALL equipment in a telepresence room. I believe that there are cases where we can have multiple SIP user agents (Uas) in one room. Think of a bunch of codec boxes in a rack, all having their own UA. Is this the common understanding of the group? To ask the question differently, do we have an agreement that there is a single SIP UA in one room? Guidance, please. Thanks, Stephan On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" wrote: >I don't think that we want to limit the "endpoint" definition to entities >facing a user. We could have entities not facing a user (e.g. an >automata), but which are sending/receiving media, and which need to >understand characteristics of the remote, and could maybe have also some >characteristics. I don't think we want to exclude such cases. > >Relying on the "participant" definition of RFC4353, a telepresence >conference will be composed of "participants", where a participant is >connected to the conference through an "endpoint". In telepresence, the >participant will have to be aware of the endpoint, in particular when the >participant needs to inform the remote of the characteristics of its >endpoint. > >Thus my proposition is to clarify that "endpoint" defines the entity >through which a participant (we do not limit to entity facing a user) is >connected to a telepresence conference. > >In the same manner, we could also use the "mixer" word instead of "MCU". > >Most of requirements should then apply on the participant or mixer >(typically, a participant will describe characteristics of its endpoint). > > >Regards, >Stephane. > > >-----Message d'origine----- >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >Espen Berger (espeberg) >Envoy=E9 : mercredi 18 mai 2011 10:40 >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE >Objet : Re: [clue] Definitions > >I think we should keep both endpoints and MCUs in the definition >document.=20 > >One difference between endpoints and MCUs are how they handle media. An >endpoint usually send media representing itself and MCUs send media on >behalf of others remote endpoint connected. > >Cheers=20 > >-Espen=20 > > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Stephan Wenger >Sent: 17. mai 2011 06:17 >To: Charles Eckel (eckelcu); CLUE >Subject: Re: [clue] Definitions > >Hi Charles, >Please see inline. >In summary, I'm not convinced there is need for a change, though there >may >be need for more explanatory text. >Stephan > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" >wrote: > >>Hi Stephan, >> >>This is a great start. I do not know if you volunteered to update as >>well as provide the initial version of this document. In any case, here >>are some comments. >> >>> Endpoint - The logical point of final termination through >>> receiving, decoding and rendering, and/or initiation through >>> capturing, encoding, and sending of media streams. An endpoint >>> consists of one or more physical devices which source and sink >>> media streams. In contrast to an endpoint, a middle box, such >>> as an MCU, may also send and receive media streams, but it is >>> not the initiator nor the final terminator. >> >>I am not sure we should differentiate between endpoint and MCU. The >>distinction blurs in that an MCU generates and send media streams that >>are not necessarily equivalent to those it received, and it receives >>input from other endpoints. I think trying to distinguish them simply >>makes more work and add complexity. I also think we will find that the >>majority of "MCUs" are really more "endpoints" than "MCUs". >>You introduced the concept of remote. I am proposing remote =3D=3D endpoint >>and remove MCU. > >Not sure here. >What "endpoint" attempts to express is that it is the logical entity >facing the user--the room including microphones loudspeakers, screens, >cameras, and some technical stuff that sends and receives RTP streams >and >implements signaling. We need such a definition certainly in the >requirement spec but also in the use cases. There is also a "local" >endpoint, which prohibits the use of "remote". >I think we should leave this definition alone. > >> >>> Media - Any data that, after suitable encoding, can be conveyed >>> over RTP, including audio, video or timed text. >> >>I think this is too general, but I am not able to suggest a good way to >>improve it. > >Again, not sure why this is too general. > >> >>> Session - RTP session. An association among a set of >>> participants communicating with RTP. The distinguishing feature >>> of an RTP session is that each maintains a full, separate space >>> of SSRC identifiers. [RFC3550] >> >>In this case, do we also need a term for the collection of RTP sessions >>the contains the complete set media exchanged between two endpoints? > >Perhaps, though I don't think we have seen that need yet. >Pm the media plane, there is really no such thing as "bundling" of media >transmission channels. There is a logical connection between multiple >sessions, but only in the signaling. > >>=20 >> >>"Layouts" vs. "Spatial Relations", what is the difference? > >A Layout is the aggregation of all spatial relations of all >capture/renderer devices at a given point in time? >"Left speaker is left from right speaker" is a spatial relation. >"Left microphone is co-located with left camera" is a spatial relation. >"Audio channel 1 is left, audio channel 2 is right, and there is only >one >center camera" is a layout. > >> >>Cheers, >>Charles >> >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>Of Stephan Wenger >>> Sent: Friday, May 13, 2011 11:08 AM >>> To: CLUE >>> Subject: [clue] Definitions >>>=20 >>> Hi folks, >>> Here a VERY rough initial draft. Addressing typos, sorting to >>alphabetical, and other cleanup tasks >>> will have to wait for the my return to the office next week. I will >>submit officially only after the >>> most embarrassing bugs are sorted out. No need to comment on typos, >>but if you have substantial >>> issues then send them now, and I can address them immediately. >>> Stephan >> > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Wed May 18 08:01:02 2011 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 06FB7E075C for ; Wed, 18 May 2011 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 MDvYkl1ioiBt for ; Wed, 18 May 2011 08:01:00 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C69DE06FB for ; Wed, 18 May 2011 08:01:00 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2384-1743317 for multiple; Wed, 18 May 2011 17:00:59 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 18 May 2011 08:00:44 +0200 From: Stephan Wenger To: Christer Holmberg , CLUE Message-ID: Thread-Topic: Definitions In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E185BE3@ESESSCMS0356.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions 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, 18 May 2011 15:01:02 -0000 Agreed. Will remove "session" definition, and rely on documents copy-pasting from the definitions to make this important distinction. Stephan On 5.18.2011 08:20 , "Christer Holmberg" wrote: >Hi, > >Regarding "Session - RTP session". I think we need to be explicit when we >talk about sessions, because we are also most likely going to talk about >SIP sessions. > >Regards, > >Christer > > >________________________________ > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Stephan Wenger > Sent: 13. toukokuuta 2011 21:08 > To: CLUE > Subject: [clue] Definitions > > > Hi folks, > Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks will have to wait for the my return >to the office next week. I will submit officially only after the most >embarrassing bugs are sorted out. No need to comment on typos, but if >you have substantial issues then send them now, and I can address them >immediately. > Stephan > > From stephen.botzko@gmail.com Wed May 18 08:16:38 2011 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 A7709E06B8 for ; Wed, 18 May 2011 08:16:38 -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 paPzsMqckiLw for ; Wed, 18 May 2011 08:16:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF46E074B for ; Wed, 18 May 2011 08:16:37 -0700 (PDT) Received: by vws12 with SMTP id 12so1411802vws.31 for ; Wed, 18 May 2011 08:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dH6iZjvJWs1DCtDMS2oy2Mu9lAVUY3jh1ynWGToyCRg=; b=GFVa3599URhxegOSnM9ss5xUeU2NMI31Da8K5I0g//X0mvqEb5MLyppjpEpSU+7/Fb HHnQ1ALOqpvVy5GDrxmg41KXmht5rvCUjj/NYxWhySqZRAhgDe2vABSGIDpYP1sXHB0D O53SRaIyoHTurGDwftn98VKhObKYSs2DtBMs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cegkgYXTbVJ6jxSi1XQDECO81xtia10mQBk7gCHFJuueyJC4qwQtEecjFt2+DGYnFe moqLa/GIpa2l31is5GLsQa+V5OUpeuAusis7qjxKhK6HmqzuZjiMzAM3M85Pkj7uwoAb KDK/KbCo4pPKt/45yR+GjrB8Tv9zcXXinssE4= MIME-Version: 1.0 Received: by 10.52.116.42 with SMTP id jt10mr2879629vdb.36.1305731796769; Wed, 18 May 2011 08:16:36 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 08:16:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 11:16:36 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=bcaec548a79feb1d5c04a38e5f70 Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 15:16:38 -0000 --bcaec548a79feb1d5c04a38e5f70 Content-Type: text/plain; charset=ISO-8859-1 In-line - Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there may > be need for more explanatory text. > Stephan > > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: > > >Hi Stephan, > > > >This is a great start. I do not know if you volunteered to update as > >well as provide the initial version of this document. In any case, here > >are some comments. > > > >> Endpoint - The logical point of final termination through > >> receiving, decoding and rendering, and/or initiation through > >> capturing, encoding, and sending of media streams. An endpoint > >> consists of one or more physical devices which source and sink > >> media streams. In contrast to an endpoint, a middle box, such > >> as an MCU, may also send and receive media streams, but it is > >> not the initiator nor the final terminator. > > > >I am not sure we should differentiate between endpoint and MCU. The > >distinction blurs in that an MCU generates and send media streams that > >are not necessarily equivalent to those it received, and it receives > >input from other endpoints. I think trying to distinguish them simply > >makes more work and add complexity. I also think we will find that the > >majority of "MCUs" are really more "endpoints" than "MCUs". > >You introduced the concept of remote. I am proposing remote == endpoint > >and remove MCU. > > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. > > > > >> Media - Any data that, after suitable encoding, can be conveyed > >> over RTP, including audio, video or timed text. > > > >I think this is too general, but I am not able to suggest a good way to > >improve it. > > Again, not sure why this is too general. > > > > >> Session - RTP session. An association among a set of > >> participants communicating with RTP. The distinguishing feature > >> of an RTP session is that each maintains a full, separate space > >> of SSRC identifiers. [RFC3550] > > > >In this case, do we also need a term for the collection of RTP sessions > >the contains the complete set media exchanged between two endpoints? > > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. > > > > > > >"Layouts" vs. "Spatial Relations", what is the difference? > > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. > > Although these are all examples of spatial relations, I think we need to be very careful to distinguish microphones and audio channels (and cameras /video channels). Lots of audio systems use microphone arrays and beam forming to get pickup in various parts of the room, and in principle you could use similar techniques for video. So in practice, I think it is essential that we describe relationships of streams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or that it shows participants on the left? I think the latter is the intent, and that it needs to be clear. Another reason perhaps to avoid talking about camera placement. > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >Of Stephan Wenger > >> Sent: Friday, May 13, 2011 11:08 AM > >> To: CLUE > >> Subject: [clue] Definitions > >> > >> Hi folks, > >> Here a VERY rough initial draft. Addressing typos, sorting to > >alphabetical, and other cleanup tasks > >> will have to wait for the my return to the office next week. I will > >submit officially only after the > >> most embarrassing bugs are sorted out. No need to comment on typos, > >but if you have substantial > >> issues then send them now, and I can address them immediately. > >> Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec548a79feb1d5c04a38e5f70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-line -
Stephen Botzko

On Tue, May = 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:<= br>
Hi Charles,
Please see inline.
In summary, I'm not convinced there is need for a change, though there = may
be need for more explanatory text.
Stephan

On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:
>Hi Stephan,
>
>This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point of final termination through
>> receiving, decoding and rendering, and/or initiation through
>> capturing, encoding, and sending of media streams. =A0An endpoint<= br> >> consists of one or more physical devices which source and sink
>> media streams. =A0In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is
>> not the initiator nor the final terminator.
>
>I am not sure we should differentiate between endpoint and MCU. The
>distinction blurs in that an MCU generates and send media streams that<= br> >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the<= br> >majority of "MCUs" are really more "endpoints" than= "MCUs".
>You introduced the concept of remote. I am proposing remote =3D=3D endp= oint
>and remove MCU.

Not sure here.
What "endpoint" attempts to express is that it is the logical ent= ity
facing the user--the room including microphones loudspeakers, screens,
cameras, and some technical stuff that sends and receives RTP streams and implements signaling. =A0We need such a definition certainly in the
requirement spec but also in the use cases. =A0There is also a "local&= quot;
endpoint, which prohibits the use of "remote".
I think we should leave this definition alone.

>
>> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text.
>
>I think this is too general, but I am not able to suggest a good way to=
>improve it.

Again, not sure why this is too general.

>
>> Session - RTP session. =A0An association among a set of
>> participants communicating with RTP. =A0The distinguishing feature=
>> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. =A0[RFC3550]
>
>In this case, do we also need a term for the collection of RTP sessions=
>the contains the complete set media exchanged between two endpoints?
Perhaps, though I don't think we have seen that need yet.
Pm the media plane, there is really no such thing as "bundling" o= f media
transmission channels. =A0There is a logical connection between multiple sessions, but only in the signaling.

>
>
>"Layouts" vs. "Spatial Relations", what is the diff= erence?

A Layout is the aggregation of all spatial relations of all
capture/renderer devices at a given point in time?
"Left speaker is left from right speaker" is a spatial relation.<= br> "Left microphone is co-located with left camera" is a spatial rel= ation.
"Audio channel 1 is left, audio channel 2 is right, and there is only = one
center camera" is a layout.

Although these are a= ll examples of spatial relations, I think we need to be very careful to dis= tinguish microphones and audio channels (and cameras /video channels).=A0 L= ots of audio systems use microphone arrays and beam forming to get pickup i= n various parts of the room, and in principle you could use similar techniq= ues for video.

So in practice, I think it is essential that we describe relationships = of streams, and not capture/render devices.

Also, do we mean the &qu= ot;left camera" is physically located on the left, or that it shows pa= rticipants on the left?=A0 I think the latter is the intent, and that it ne= eds to be clear.=A0 Another reason perhaps to avoid talking about camera pl= acement.
=A0
>
>Cheers,
>Charles
>
>
>> -----Original Message-----
>> From: c= lue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
>> To: CLUE
>> Subject: [clue] Definitions
>>
>> Hi folks,
>> Here a VERY rough initial draft. =A0Addressing typos, sorting to >alphabetical, and other cleanup tasks
>> will have to wait for the my return to the office next week. =A0I = will
>submit officially only after the
>> most embarrassing bugs are sorted out. =A0No need to comment on ty= pos,
>but if you have substantial
>> issues then send them now, and I can address them immediately.
>> Stephan
>


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

--bcaec548a79feb1d5c04a38e5f70-- From mark.gorzynski@hp.com Wed May 18 09:02:05 2011 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 9F7D1E06CB for ; Wed, 18 May 2011 09:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RP+LFqxozN3T for ; Wed, 18 May 2011 09:02:01 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF88E06E0 for ; Wed, 18 May 2011 09:02:01 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id EE9001C9B2 for ; Wed, 18 May 2011 16:02:00 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 16:00:40 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Wed, 18 May 2011 16:00:39 +0000 From: "Gorzynski, Mark E (The Right One)" To: CLUE Date: Wed, 18 May 2011 16:00:37 +0000 Thread-Topic: [clue] Definitions Thread-Index: AcwVbpbM4Pd+a2nQT8e5MiZ+lK2RYAABAsQg Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions 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, 18 May 2011 16:02:05 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * Agree with the point (Botzko) that "spatial relations" should refe= r to streams not devices. * Also agree with the point (stated in several places) that left-rig= ht should be clear and be defined with respect to a user facing the display= s. This will of course require being careful about maintaining this conven= tion when a stream is received. At a sender, a stream may be thus defined = as from the right-most display. But when it is received and rendered on a = display, that final destination will use the receiver's point of view. Thu= s a stream at Sender A may be labeled A-Right and then sent to receiver B f= or output to display B-Left. I would not re-label the stream from A to mat= ch the receiver convention. Thus streams might be labeled with respect to = the sender convention. * We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spati= al relationship. Using left-right or -2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when "right" begins. T= his is not always true. For example a system with an even number of displa= ys and a camera above each display. Thus it may be most efficient to use t= he sense of "left" to create a beginning of a spatial relationship and orde= r streams from that beginning, 0,1,2,... Thus we may label a stream from t= he right-most display of a sender A as coming from A.2 If that stream is s= ent to a receiver for output on a left most display, that left most display= destination may be B.0. Regards Mark Gorzynski From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: Wednesday, May 18, 2011 8:17 AM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] Definitions In-line - Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger > wrote: Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoin= t >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. Although these are all examples of spatial relations, I think we need to be= very careful to distinguish microphones and audio channels (and cameras /v= ideo channels). Lots of audio systems use microphone arrays and beam formi= ng to get pickup in various parts of the room, and in principle you could u= se similar techniques for video. So in practice, I think it is essential that we describe relationships of s= treams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or th= at it shows participants on the left? I think the latter is the intent, an= d that it needs to be clear. Another reason perhaps to avoid talking about= camera placement. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >> >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

· &nb= sp;      Agr= ee with the point (Botzko) that “spatial relations” should refe= r to streams not devices. 

=  

· &nbs= p;      Also= agree with the point (stated in several places) that left-right should be = clear and be defined with respect to a user facing the displays.  This= will of course require being careful about maintaining this convention whe= n a stream is received.  At a sender, a stream may be thus defined as = from the right-most display.  But when it is received and rendered on = a display, that final destination will use the receiver’s point of vi= ew.  Thus a stream at Sender A may be labeled A-Right and then sent to= receiver B for output to display B-Left.  I would not re-label the st= ream from A to match the receiver convention.  Thus streams might be l= abeled with respect to the sender convention.

 

·        We also should be careful when considering spatial relationsh= ips to not make the system specific to odd or even numbers of streams in a = spatial relationship.  Using left-right or
-2,-1,0,1,2 or such thi= ngs may assume a centered system where one stream is on a center axis or th= at there is a clear sense of when “right” begins.  This is= not always true.  For example a system with an even number of display= s and a camera above each display.  Thus it may be most efficient to u= se the sense of “left” to create a beginning of a spatial relat= ionship and order streams from that beginning, 0,1,2,…  Thus we = may label a stream from the right-most display of a sender A as coming from= A.2  If that stream is sent to a receiver for output on a left most d= isplay, that left most display destination may be B.0.

 

Regards

M= ark Gorzynski

 

 

 

 

<= p class=3DMsoNormal>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 201= 1 8:17 AM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] Definitions

&nb= sp;

In-line - =
Stephen Botzko

On Tue, May 17, = 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced th= ere is need for a change, though there may
be need for more explanatory = text.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" &= lt;eckelcu@cisco.com= > wrote:

>Hi Stephan,
>
>This is a great start= . I do not know if you volunteered to update as
>well as provide the = initial version of this document. In any case, here
>are some comment= s.
>
>> Endpoint - The logical point of final termination th= rough
>> receiving, decoding and rendering, and/or initiation thro= ugh
>> capturing, encoding, and sending of media streams.  An= endpoint
>> consists of one or more physical devices which source= and sink
>> media streams.  In contrast to an endpoint, a mi= ddle box, such
>> as an MCU, may also send and receive media strea= ms, but it is
>> not the initiator nor the final terminator.
&g= t;
>I am not sure we should differentiate between endpoint and MCU. T= he
>distinction blurs in that an MCU generates and send media streams= that
>are not necessarily equivalent to those it received, and it re= ceives
>input from other endpoints. I think trying to distinguish the= m simply
>makes more work and add complexity. I also think we will fi= nd that the
>majority of "MCUs" are really more "endpo= ints" than "MCUs".
>You introduced the concept of remo= te. I am proposing remote =3D=3D endpoint
>and remove MCU.=

Not sure here.
What "endpoint" = attempts to express is that it is the logical entity
facing the user--th= e room including microphones loudspeakers, screens,
cameras, and some te= chnical stuff that sends and receives RTP streams and
implements signali= ng.  We need such a definition certainly in the
requirement spec bu= t also in the use cases.  There is also a "local"
endpoin= t, which prohibits the use of "remote".
I think we should leav= e this definition alone.


>
>> Media - Any data that, after suit= able encoding, can be conveyed
>> over RTP, including audio, video= or timed text.
>
>I think this is too general, but I am not ab= le to suggest a good way to
>improve it.

Again, not sure why this is too general.


>
>> Sess= ion - RTP session.  An association among a set of
>> particip= ants communicating with RTP.  The distinguishing feature
>> o= f an RTP session is that each maintains a full, separate space
>> = of SSRC identifiers.  [RFC3550]
>
>In this case, do we als= o need a term for the collection of RTP sessions
>the contains the co= mplete set media exchanged between two endpoints?

Perhaps, though I don't think we have seen that need yet.Pm the media plane, there is really no such thing as "bundling"= of media
transmission channels.  There is a logical connection bet= ween multiple
sessions, but only in the signaling.


>
>
>&= quot;Layouts" vs. "Spatial Relations", what is the differenc= e?

A Layout is the aggregation of = all spatial relations of all
capture/renderer devices at a given point i= n time?
"Left speaker is left from right speaker" is a spatial= relation.
"Left microphone is co-located with left camera" is= a spatial relation.
"Audio channel 1 is left, audio channel 2 is r= ight, and there is only one
center camera" is a layout.<= /p>

 

Although these are all examples of spatial relations, I t= hink we need to be very careful to distinguish microphones and audio channe= ls (and cameras /video channels).  Lots of audio systems use microphon= e arrays and beam forming to get pickup in various parts of the room, and i= n principle you could use similar techniques for video.

So in practi= ce, I think it is essential that we describe relationships of streams, and = not capture/render devices.

Also, do we mean the "left camera&q= uot; is physically located on the left, or that it shows participants on th= e left?  I think the latter is the intent, and that it needs to be cle= ar.  Another reason perhaps to avoid talking about camera placement. 

>
>Cheers,
>Charles
= >
>
>> -----Original Message-----
>> From: clue-bounces@ietf.org= [mailto:clu= e-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent= : Friday, May 13, 2011 11:08 AM
>> To: CLUE
>> Subject: [= clue] Definitions
>>
>> Hi folks,
>> Here a VERY= rough initial draft.  Addressing typos, sorting to
>alphabetica= l, and other cleanup tasks
>> will have to wait for the my return = to the office next week.  I will
>submit officially only after t= he
>> most embarrassing bugs are sorted out.  No need to comm= ent on typos,
>but if you have substantial
>> issues then se= nd them now, and I can address them immediately.
>> Stephan
>= ;


_______________________________________________
clue mailin= g list
clue@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/clue

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3GVW1096EXBame_-- From stewe@stewe.org Wed May 18 09:06:25 2011 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 169F7E0728 for ; Wed, 18 May 2011 09:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ii3+nhQpyWOG for ; Wed, 18 May 2011 09:06:20 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA57E0737 for ; Wed, 18 May 2011 09:06:19 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2399-1743317 for multiple; Wed, 18 May 2011 18:06:18 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 18 May 2011 09:06:08 +0200 From: Stephan Wenger To: "Gorzynski, Mark E (The Right One)" , CLUE Message-ID: Thread-Topic: [clue] Definitions In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388554377_10304379" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions 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, 18 May 2011 16:06:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388554377_10304379 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Inline. Stephan From: "Gorzynski, Mark E (The Right One)" Date: Wed, 18 May 2011 16:00:37 +0000 To: CLUE Subject: Re: [clue] Definitions =B7 Agree with the point (Botzko) that =B3spatial relations=B2 should refe= r to streams not devices. =20 Got it. =20 =B7 Also agree with the point (stated in several places) that left-right should be clear and be defined with respect to a user facing the displays. This will of course require being careful about maintaining this convention when a stream is received. At a sender, a stream may be thus defined as from the right-most display. But when it is received and rendered on a display, that final destination will use the receiver=B9s point of view. Thus a stream at Sender A may be labeled A-Right and then sent to receiver B for output to display B-Left. I would not re-label the stream from A to match the receiver convention. Thus streams might be labeled wit= h respect to the sender convention. Got it. Had already private conversation with Roni on the same point, with a similar solution. Will word-smith accordingly. =20 =B7 We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spatial relationship. Using left-right or -2,-1,0,1,2 or such things may assume a centered system where one stream is on a center axis or that there is a clear sense of when =B3right=B2 begins. This is not always true. For example a system with an even number of displays and a camera above each display. Thus it may be most efficient to use the sense of =B3left=B2 to create a beginning of a spatial relationship and order streams from that beginning, 0,1,2,=8A Thus we may label a stream from the right-most display of a sender A as coming from A.2 If that stream is sent to a receiver for output on a left most display, that left most displa= y destination may be B.0. Agreed, but I don't think this is a "definitions" thing. It's more a convention that may best live in a protocol spec. Right? =20 Regards Mark Gorzynski =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, May 18, 2011 8:17 AM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] Definitions =20 In-line -=20 Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoint >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. =20 Although these are all examples of spatial relations, I think we need to be very careful to distinguish microphones and audio channels (and cameras /video channels). Lots of audio systems use microphone arrays and beam forming to get pickup in various parts of the room, and in principle you could use similar techniques for video. So in practice, I think it is essential that we describe relationships of streams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or that it shows participants on the left? I think the latter is the intent, and that it needs to be clear. Another reason perhaps to avoid talking about camera placement. =20 >=20 >> > >> >Cheers, >> >Charles >> > >> > >>> >> -----Original Message----- >>> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> >Of Stephan Wenger >>> >> Sent: Friday, May 13, 2011 11:08 AM >>> >> To: CLUE >>> >> Subject: [clue] Definitions >>> >> >>> >> Hi folks, >>> >> Here a VERY rough initial draft. Addressing typos, sorting to >> >alphabetical, and other cleanup tasks >>> >> will have to wait for the my return to the office next week. I will >> >submit officially only after the >>> >> most embarrassing bugs are sorted out. No need to comment on typos, >> >but if you have substantial >>> >> issues then send them now, and I can address them immediately. >>> >> Stephan >> > >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue =20 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --B_3388554377_10304379 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Inline.
Stephan

From: "Gorzynski, Mark= E (The Right One)" <mark.gorzynsk= i@hp.com>
Date: Wed, 18 May= 2011 16:00:37 +0000
To: CLUE <= clue@ietf.org>
Subject: Re: [clue] Definitions

<= div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-microsoft-c= om:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xmlns:m=3D"h= ttp://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR= /REC-html40">

=B7        Agree with the point (Botzko) that “spatial r= elations” should refer to streams not devices. 

 

<= /div>

G= ot it.  


=B7        Also agree with the point (stated in several p= laces) that left-right should be clear and be defined with respect to a user= facing the displays.  This will of course require being careful about = maintaining this convention when a stream is received.  At a sender, a = stream may be thus defined as from the right-most display.  But when it= is received and rendered on a display, that final destination will use the = receiver’s point of view.  Thus a stream at Sender A may be label= ed A-Right and then sent to receiver B for output to display B-Left.  I= would not re-label the stream from A to match the receiver convention. = ; Thus streams might be labeled with respect to the sender convention.


Got it.  Had already = private conversation with Roni on the same point, with a similar solution. &= nbsp;Will word-smith accordingly.

 

=B7        We also should be careful when considering= spatial relationships to not make the system specific to odd or even number= s of streams in a spatial relationship.  Using left-right or
-2,-1,= 0,1,2 or such things may assume a centered system where one stream is on a c= enter axis or that there is a clear sense of when “right” begins= .  This is not always true.  For example a system with an even num= ber of displays and a camera above each display.  Thus it may be most e= fficient to use the sense of “left” to create a beginning of a s= patial relationship and order streams from that beginning, 0,1,2,…&nbs= p; Thus we may label a stream from the right-most display of a sender A as c= oming from A.2  If that stream is sent to a receiver for output on a le= ft most display, that left most display destination may be B.0.


Agreed, but I don't think this is= a "definitions" thing.  It's more a convention that may best live in a= protocol spec.  Right?

 

Regards

Ma= rk Gorzynski

 

 =

 

&nbs= p;

From: clue-bounces@ietf.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent:<= /b> Wednesday, May 18, 2011 8:17 AM
To: Stephan Wenger
Cc: CLUE
Subject: Re: [clue] Definitions

 

In-line -
Stephen Botzko

On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

<= p class=3D"MsoNormal">Hi Charles,
Please see inline.
In summary, I'm not= convinced there is need for a change, though there may
be need for more = explanatory text.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <= ;eckelcu@cisco.com>= ; wrote:

>Hi Stephan,
>
>This is a great start. I do n= ot know if you volunteered to update as
>well as provide the initial v= ersion of this document. In any case, here
>are some comments.
>=
>> Endpoint - The logical point of final termination through
&g= t;> receiving, decoding and rendering, and/or initiation through
>&= gt; capturing, encoding, and sending of media streams.  An endpoint
= >> consists of one or more physical devices which source and sink
&= gt;> media streams.  In contrast to an endpoint, a middle box, such<= br>>> as an MCU, may also send and receive media streams, but it is>> not the initiator nor the final terminator.
>
>I am no= t sure we should differentiate between endpoint and MCU. The
>distinct= ion blurs in that an MCU generates and send media streams that
>are no= t necessarily equivalent to those it received, and it receives
>input = from other endpoints. I think trying to distinguish them simply
>makes= more work and add complexity. I also think we will find that the
>maj= ority of "MCUs" are really more "endpoints" than "MCUs".
>You introduc= ed the concept of remote. I am proposing remote =3D=3D endpoint
>and remov= e MCU.

Not sure here.
What "endp= oint" attempts to express is that it is the logical entity
facing the use= r--the room including microphones loudspeakers, screens,
cameras, and som= e technical stuff that sends and receives RTP streams and
implements sign= aling.  We need such a definition certainly in the
requirement spec = but also in the use cases.  There is also a "local"
endpoint, which = prohibits the use of "remote".
I think we should leave this definition al= one.

>
>> Media - Any data that, after suitable encoding, can be co= nveyed
>> over RTP, including audio, video or timed text.
>>I think this is too general, but I am not able to suggest a good way t= o
>improve it.

Again, not sur= e why this is too general.


>
>> Session - RTP session.  An ass= ociation among a set of
>> participants communicating with RTP. &nb= sp;The distinguishing feature
>> of an RTP session is that each mai= ntains a full, separate space
>> of SSRC identifiers.  [RFC355= 0]
>
>In this case, do we also need a term for the collection of= RTP sessions
>the contains the complete set media exchanged between t= wo endpoints?

Perhaps, though I don= 't think we have seen that need yet.
Pm the media plane, there is really = no such thing as "bundling" of media
transmission channels.  There i= s a logical connection between multiple
sessions, but only in the signali= ng.

>
>
>"Layouts" vs. "Spatial Relations", what is the differen= ce?

A Layout is the aggregation of = all spatial relations of all
capture/renderer devices at a given point in= time?
"Left speaker is left from right speaker" is a spatial relation."Left microphone is co-located with left camera" is a spatial relation."Audio channel 1 is left, audio channel 2 is right, and there is only onecenter camera" is a layout.

<= o:p> 

Although these are= all examples of spatial relations, I think we need to be very careful to di= stinguish microphones and audio channels (and cameras /video channels). = ; Lots of audio systems use microphone arrays and beam forming to get pickup= in various parts of the room, and in principle you could use similar techni= ques for video.

So in practice, I think it is essential that we descr= ibe relationships of streams, and not capture/render devices.

Also, d= o we mean the "left camera" is physically located on the left, or that it sh= ows participants on the left?  I think the latter is the intent, and th= at it needs to be clear.  Another reason perhaps to avoid talking about= camera placement.
 

>
>Cheers,
= >Charles
>
>
>> -----Original Message-----
>&g= t; From: clue-bounces= @ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> S= ent: Friday, May 13, 2011 11:08 AM
>> To: CLUE
>> Subject:= [clue] Definitions
>>
>> Hi folks,
>> Here a VER= Y rough initial draft.  Addressing typos, sorting to
>alphabetica= l, and other cleanup tasks
>> will have to wait for the my return t= o the office next week.  I will
>submit officially only after the=
>> most embarrassing bugs are sorted out.  No need to comment= on typos,
>but if you have substantial
>> issues then send t= hem now, and I can address them immediately.
>> Stephan
>
=

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

<= /div>

 

___________= ____________________________________ clue mailing list clue@ietf.org https://www.ietf.org/m= ailman/listinfo/clue --B_3388554377_10304379-- From stephen.botzko@gmail.com Wed May 18 09:06:55 2011 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 09F06E0741 for ; Wed, 18 May 2011 09:06:55 -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 7dVjfRr4v0wh for ; Wed, 18 May 2011 09:06:53 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74B57E0665 for ; Wed, 18 May 2011 09:06:53 -0700 (PDT) Received: by vws12 with SMTP id 12so1461341vws.31 for ; Wed, 18 May 2011 09:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AatOZ3S72cKFHNq2GCuGdaDKydZ2E5IWW9l784dWHXk=; b=sGIMGZK7B/Nn4O0y0OW+vdOvDWYwz2A/8q6sfm2C8uLw24/nYywhxynDZyCQlvFiJt HstTSZ+scf7rDhsNPZWgeoWDwA8W1ktP8H7TX3gd3D6lK5NyXTYwaooug3DNjV7DWsz7 K3xuHk+V2BmWgLPvKrBPOYcc+IgJQ8GRxkZkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qBAhoQItiCuyhgfZ670p0ZMwetOTz17VK2exRyhMhhHRps9C3Y61I11LFS8LfsE65v 9EbdvNWVR/jAGrgGE33ScBszoLoc2v9kDikgxW5V/BU9fwgMnBuNms8IoU5t2PIglNLU sBFsV2e8ikPwZGxinB0yWymYfDZ2onimPrFuA= MIME-Version: 1.0 Received: by 10.52.106.232 with SMTP id gx8mr2901497vdb.236.1305734812873; Wed, 18 May 2011 09:06:52 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 09:06:52 -0700 (PDT) In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> Date: Wed, 18 May 2011 12:06:52 -0400 Message-ID: From: Stephen Botzko To: "Gorzynski, Mark E (The Right One)" Content-Type: multipart/alternative; boundary=bcaec547ca33b131f204a38f13de Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 16:06:55 -0000 --bcaec547ca33b131f204a38f13de Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I note we have at least one use case where users in the same room are facin= g in different directions. Stephen Botzko On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) < mark.gorzynski@hp.com> wrote: > =B7 Agree with the point (Botzko) that =93spatial relations=94 sho= uld > refer to streams not devices. > > > > =B7 Also agree with the point (stated in several places) that > left-right should be clear and be defined with respect to a user facing t= he > displays. This will of course require being careful about maintaining th= is > convention when a stream is received. At a sender, a stream may be thus > defined as from the right-most display. But when it is received and > rendered on a display, that final destination will use the receiver=92s p= oint > of view. Thus a stream at Sender A may be labeled A-Right and then sent = to > receiver B for output to display B-Left. I would not re-label the stream > from A to match the receiver convention. Thus streams might be labeled w= ith > respect to the sender convention. > > > > =B7 We also should be careful when considering spatial relationshi= ps > to not make the system specific to odd or even numbers of streams in a > spatial relationship. Using left-right or > -2,-1,0,1,2 or such things may assume a centered system where one stream = is > on a center axis or that there is a clear sense of when =93right=94 begin= s. > This is not always true. For example a system with an even number of > displays and a camera above each display. Thus it may be most efficient = to > use the sense of =93left=94 to create a beginning of a spatial relationsh= ip and > order streams from that beginning, 0,1,2,=85 Thus we may label a stream = from > the right-most display of a sender A as coming from A.2 If that stream i= s > sent to a receiver for output on a left most display, that left most disp= lay > destination may be B.0. > > > > Regards > > Mark Gorzynski > > > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephen Botzko > *Sent:* Wednesday, May 18, 2011 8:17 AM > *To:* Stephan Wenger > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > In-line - > Stephen Botzko > > On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: > > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there ma= y > be need for more explanatory text. > Stephan > > > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: > > >Hi Stephan, > > > >This is a great start. I do not know if you volunteered to update as > >well as provide the initial version of this document. In any case, here > >are some comments. > > > >> Endpoint - The logical point of final termination through > >> receiving, decoding and rendering, and/or initiation through > >> capturing, encoding, and sending of media streams. An endpoint > >> consists of one or more physical devices which source and sink > >> media streams. In contrast to an endpoint, a middle box, such > >> as an MCU, may also send and receive media streams, but it is > >> not the initiator nor the final terminator. > > > >I am not sure we should differentiate between endpoint and MCU. The > >distinction blurs in that an MCU generates and send media streams that > >are not necessarily equivalent to those it received, and it receives > >input from other endpoints. I think trying to distinguish them simply > >makes more work and add complexity. I also think we will find that the > >majority of "MCUs" are really more "endpoints" than "MCUs". > >You introduced the concept of remote. I am proposing remote =3D=3D endpo= int > >and remove MCU. > > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. > > > > > >> Media - Any data that, after suitable encoding, can be conveyed > >> over RTP, including audio, video or timed text. > > > >I think this is too general, but I am not able to suggest a good way to > >improve it. > > Again, not sure why this is too general. > > > > > >> Session - RTP session. An association among a set of > >> participants communicating with RTP. The distinguishing feature > >> of an RTP session is that each maintains a full, separate space > >> of SSRC identifiers. [RFC3550] > > > >In this case, do we also need a term for the collection of RTP sessions > >the contains the complete set media exchanged between two endpoints? > > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. > > > > > > > >"Layouts" vs. "Spatial Relations", what is the difference? > > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. > > > > Although these are all examples of spatial relations, I think we need to = be > very careful to distinguish microphones and audio channels (and cameras > /video channels). Lots of audio systems use microphone arrays and beam > forming to get pickup in various parts of the room, and in principle you > could use similar techniques for video. > > So in practice, I think it is essential that we describe relationships of > streams, and not capture/render devices. > > Also, do we mean the "left camera" is physically located on the left, or > that it shows participants on the left? I think the latter is the intent= , > and that it needs to be clear. Another reason perhaps to avoid talking > about camera placement. > > > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >Of Stephan Wenger > >> Sent: Friday, May 13, 2011 11:08 AM > >> To: CLUE > >> Subject: [clue] Definitions > >> > >> Hi folks, > >> Here a VERY rough initial draft. Addressing typos, sorting to > >alphabetical, and other cleanup tasks > >> will have to wait for the my return to the office next week. I will > >submit officially only after the > >> most embarrassing bugs are sorted out. No need to comment on typos, > >but if you have substantial > >> issues then send them now, and I can address them immediately. > >> Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec547ca33b131f204a38f13de Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I note we have at least one use case where users in the same room are facin= g in different directions.

Stephen Botzko

On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One)= <mark.gorzyn= ski@hp.com> wrote:

=B7=A0= =A0=A0=A0=A0=A0=A0 Agree with the point (Botzko) that =93spatial relations=94 shou= ld refer to streams not devices.=A0

=A0

=B7=A0=A0= =A0=A0=A0=A0=A0 Also agree with the point (stated in several places) that left-rig= ht should be clear and be defined with respect to a user facing the display= s.=A0 This will of course require being careful about maintaining this conv= ention when a stream is received.=A0 At a sender, a stream may be thus defi= ned as from the right-most display.=A0 But when it is received and rendered= on a display, that final destination will use the receiver=92s point of vi= ew.=A0 Thus a stream at Sender A may be labeled A-Right and then sent to re= ceiver B for output to display B-Left.=A0 I would not re-label the stream f= rom A to match the receiver convention.=A0 Thus streams might be labeled wi= th respect to the sender convention.

=A0

=B7=A0=A0=A0=A0=A0=A0=A0 We also shoul= d be careful when considering spatial relationships to not make the system = specific to odd or even numbers of streams in a spatial relationship.=A0 Us= ing left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when =93right=94 begins= .=A0 This is not always true.=A0 For example a system with an even number o= f displays and a camera above each display.=A0 Thus it may be most efficien= t to use the sense of =93left=94 to create a beginning of a spatial relatio= nship and order streams from that beginning, 0,1,2,=85=A0 Thus we may label= a stream from the right-most display of a sender A as coming from A.2=A0 I= f that stream is sent to a receiver for output on a left most display, that= left most display destination may be B.0.

=A0

Regards

Mar= k Gorzynski

=A0

=A0

=A0

=A0

From: clue-bounces@ietf.org<= /a> [mailto:clue= -bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan WengerCc: CLUE
Subject: Re: [clue] Definitions

=A0

In-line -
Stephen Botzko

On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> w= rote:

Hi Charles,
Please see inline.
In summary, I&#= 39;m not convinced there is need for a change, though there may
be need = for more explanatory text.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrot= e:

>Hi Stephan,
>
>This is a great start. I do not kn= ow if you volunteered to update as
>well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point= of final termination through
>> receiving, decoding and rendering= , and/or initiation through
>> capturing, encoding, and sending of media streams. =A0An endpoint<= br>>> consists of one or more physical devices which source and sink<= br>>> media streams. =A0In contrast to an endpoint, a middle box, suc= h
>> as an MCU, may also send and receive media streams, but it is
&= gt;> not the initiator nor the final terminator.
>
>I am not= sure we should differentiate between endpoint and MCU. The
>distinct= ion blurs in that an MCU generates and send media streams that
>are not necessarily equivalent to those it received, and it receives>input from other endpoints. I think trying to distinguish them simply<= br>>makes more work and add complexity. I also think we will find that t= he
>majority of "MCUs" are really more "endpoints" than= "MCUs".
>You introduced the concept of remote. I am propos= ing remote =3D=3D endpoint
>and remove MCU.

Not sure here.
What "endpoint" attempts to express is that it = is the logical entity
facing the user--the room including microphones lo= udspeakers, screens,
cameras, and some technical stuff that sends and re= ceives RTP streams and
implements signaling. =A0We need such a definition certainly in the
requ= irement spec but also in the use cases. =A0There is also a "local"= ;
endpoint, which prohibits the use of "remote".
I think we= should leave this definition alone.


>
>= > Media - Any data that, after suitable encoding, can be conveyed
>= ;> over RTP, including audio, video or timed text.
>
>I thin= k this is too general, but I am not able to suggest a good way to
>improve it.

Again, not sure why this is= too general.


>
>> Session - RTP session. =A0An association among a set = of
>> participants communicating with RTP. =A0The distinguishing feature=
>> of an RTP session is that each maintains a full, separate spac= e
>> of SSRC identifiers. =A0[RFC3550]
>
>In this case= , do we also need a term for the collection of RTP sessions
>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have see= n that need yet.
Pm the media plane, there is really no such thing as &q= uot;bundling" of media
transmission channels. =A0There is a logical connection between multiplesessions, but only in the signaling.


>
>
>"Layouts" vs. &= quot;Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial rel= ations of all
capture/renderer devices at a given point in time?
&quo= t;Left speaker is left from right speaker" is a spatial relation.
"Left microphone is co-located with left camera" is a spatial rel= ation.
"Audio channel 1 is left, audio channel 2 is right, and ther= e is only one
center camera" is a layout.

=A0

Although these are all examp= les of spatial relations, I think we need to be very careful to distinguish= microphones and audio channels (and cameras /video channels).=A0 Lots of a= udio systems use microphone arrays and beam forming to get pickup in variou= s parts of the room, and in principle you could use similar techniques for = video.

So in practice, I think it is essential that we describe relationships = of streams, and not capture/render devices.

Also, do we mean the &qu= ot;left camera" is physically located on the left, or that it shows pa= rticipants on the left?=A0 I think the latter is the intent, and that it ne= eds to be clear.=A0 Another reason perhaps to avoid talking about camera pl= acement.
=A0

=

>
>Cheers,
>Charles
>
> >> -----Original Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.o= rg] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
&g= t;> To: CLUE
>> Subject: [clue] Definitions
>>
>= > Hi folks,
>> Here a VERY rough initial draft. =A0Addressing t= ypos, sorting to
>alphabetical, and other cleanup tasks
>> will have to wait for= the my return to the office next week. =A0I will
>submit officially = only after the
>> most embarrassing bugs are sorted out. =A0No nee= d to comment on typos,
>but if you have substantial
>> issues then send them now, and = I can address them immediately.
>> Stephan
>


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

=A0


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


--bcaec547ca33b131f204a38f13de-- From pkyzivat@cisco.com Wed May 18 10:11:34 2011 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 1791DE0761 for ; Wed, 18 May 2011 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 E-sLojEDMcNs for ; Wed, 18 May 2011 10:11:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC2E074C for ; Wed, 18 May 2011 10:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6590; q=dns/txt; s=iport; t=1305738693; x=1306948293; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3xrmakrJ3gOIxOwpmLeCHKVPzaaG1r9g/dULTEdE+rk=; b=jYoqKwkCJaMs8vDWHW+FOjHUtMaMZQfnyi6f07diQreL4WNKOVCA7H0O hUne/dGX+YAmsVAioC7FXRfiymGp7pafZjDfmV8W3IcEaxZqCwZhTc3zc jt752LXQF/bjYHfTXD+GBNgLRuAPNxKZ9GTTXMq8z5JNA+xv32KDZ35Vo Y=; X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="359689401" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 18 May 2011 17:08:31 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4IH8UTU008108; Wed, 18 May 2011 17:08:30 GMT Message-ID: <4DD3FD0E.8020503@cisco.com> Date: Wed, 18 May 2011 13:08:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.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] legacy support in requirements 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, 18 May 2011 17:11:34 -0000 On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > Paul, > > I would agree that if the offer-answer model semantic is that here are > several options and any subset of options is acceptable. > > However, if there is any grouping involved such that you need to have a > video and audio feed integrated to make sense then watch out. > > For example, I wouldn't want to end up with the result of a man's video > paired with a woman's voice. That could be rather comical. Well, SDP defines that you should ignore what you don't understand and operate on what is left. So someone constructing an SDP with grouping issues such as you define ought to keep in mind that this could happen, and set things up so that something reasonable happens. You can't expect the dumb legacy device to figure out much. For your example, the result may be far from ideal, but it still is likely to be better than no call at all. And if not, there is always the option of hanging up. But better, presumably the offer could have been constructed in a way that produced a better result. Thanks, Paul > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 17, 2011 7:45 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 6:05 PM, Roni Even wrote: >> Paul, >> I think we read it differently. >> If the answerer does not support the group attribute and the offer had > the >> fid semantics it may look to the answerer as an offer with multiple > m-lines >> of the same media tyoe. In this case an implementation might also > decide to >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > Acceptable), >> because it contains several "m" lines of the same media type. > > That is a slightly different story. > > Then the reason for rejection is not because it saw an attribute it > didn't understand - its because it didn't like something it *did* > understand. > >> This is very relevant to the multiple streams case and we should look > if we >> state this behavior or we will look at providing an approach that will > allow >> the answerer to choose one m-line that the offerer prefers even of it > does >> not understand CLUE. > > IMO (lets see if others differ), if a UA receives an offer with at least > > one m-line it is happy with, then it should not reject the call because > there are others that it does not "understand". > > Here "understand" means something different - presumably it does > understand the direct meaning of the additional m-line, it just doesn't > understand the *significance* or use of it. > > I see little difference to getting to audio m-lines and only wanting > one, and getting one audio and one video and only supporting audio. In > general you should not reject an audio/video call just because you only > support audio. > > I think it will behoove clue to strongly recommend that the m-lines in > an offer be arranged so the first ones are the ones it most wants used > if not all are. > > Thanks, > Paul > >> Roni >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, May 18, 2011 12:37 AM >>> To: Roni Even >>> Cc: 'Stephen Botzko'; clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>> Paul, >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example >>>> Roni >>> >>> OK, I looked. It is consistent with what I said. >>> Either a=group: is understood, or not. If not, its ignored, and not > put >>> in the answer. Same with a=mid: >>> >>> If a=group: *is* understood, but some parameter within it is not, > there >>> are explicit rules for what to do. >>> >>> AFAICT there are no examples in this document where failure to >>> understand an a-line in total (or even in part) results in rejecting >>> the >>> offer. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> To: Stephen Botzko >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>> >>>>>> When the offer includes parameters that the answerer > does >>> not >>>>>> understand >>>>>> there are two options, he can ignore the unknown >>> parameters >>>>> or >>>>>> reject >>>>>> the offer. >>>>>> Rejecting the offer in that case is not really kosher. >>>>>> You are required to ignore parameters you do not understand. >>>>>> >>>>>> If you reject something because you don't like the > parameters >>> it >>>>>> contains, then that is an implicit statement that you >>> understand >>>>>> those parameters well enough to decide to reject them. >>>>>> >>>>>> As far as I know, you are always free to reject offers, and it >>>>> doesn't >>>>>> really imply anything when you do that.. Whether it is wise is >>>>> perhaps >>>>>> a different question. >>>>>> Stephen Botzko >>>>> >>>>> Certainly you are always free to reject an offer. >>>>> In general I don't know for certain the reason why, and so if I > give >>>>> you >>>>> the benefit of the doubt I will assume you have a valid reason - >>>>> perhaps >>>>> just policy. >>>>> >>>>> But if the reason you reject the offer is based on your violating a >>>>> spec, then you are non-conforming, whether I can determine you are >>>>> non-conforming or not. Whether being non-conforming is just > un-wise, >>> or >>>>> something stronger, is a separate discussion. The IETF does not > levy >>>>> any >>>>> penalties for violating its specs. But sometimes the market does. >>> (And >>>>> sometimes not.) But we don't need to endorse non-conforming > behavior >>> in >>>>> our documents. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed May 18 10:26:46 2011 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 38952E0714 for ; Wed, 18 May 2011 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5uOJjft66hA for ; Wed, 18 May 2011 10:26:45 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2298FE06B9 for ; Wed, 18 May 2011 10:26:43 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::27:216a:613a:350c%13]) with mapi; Wed, 18 May 2011 10:26:43 -0700 From: "Duckworth, Mark" To: Stephan Wenger , "clue@ietf.org" Date: Wed, 18 May 2011 10:26:41 -0700 Thread-Topic: [clue] Definitions Thread-Index: AcwVbE+aMyd5LHofQKuAFgeXoSBV+gAEzhdQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Definitions 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, 18 May 2011 17:26:46 -0000 Stephan, My understanding is an endpoint has a single SIP UA. And there would be on= ly one endpoint in a room. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Wednesday, May 18, 2011 2:00 AM > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > eckelcu@cisco.com; clue@ietf.org > Subject: Re: [clue] Definitions >=20 > Hi Stephane, > Very good point. >=20 > Quoting from RFC 4353 >=20 > [...] > Participant: The software element that connects a user or automat= a to > a conference. It implements, at a minimum, a SIP user agent, but > may also implement non-SIP-specific mechanisms for additional > functionality. > [...] >=20 > My understanding of "endpoint" is that an endpoint encompasses ALL > equipment in a telepresence room. I believe that there are cases where w= e > can have multiple SIP user agents (Uas) in one room. Think of a bunch of > codec boxes in a rack, all having their own UA. Is this the common > understanding of the group? >=20 > To ask the question differently, do we have an agreement that there is a > single SIP UA in one room? >=20 > Guidance, please. >=20 > Thanks, > Stephan >=20 >=20 >=20 >=20 > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > wrote: >=20 > >I don't think that we want to limit the "endpoint" definition to > entities > >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need to > >understand characteristics of the remote, and could maybe have also > some > >characteristics. I don't think we want to exclude such cases. > > > >Relying on the "participant" definition of RFC4353, a telepresence > >conference will be composed of "participants", where a participant is > >connected to the conference through an "endpoint". In telepresence, > the > >participant will have to be aware of the endpoint, in particular when > the > >participant needs to inform the remote of the characteristics of its > >endpoint. > > > >Thus my proposition is to clarify that "endpoint" defines the entity > >through which a participant (we do not limit to entity facing a user) > is > >connected to a telepresence conference. > > > >In the same manner, we could also use the "mixer" word instead of > "MCU". > > > >Most of requirements should then apply on the participant or mixer > >(typically, a participant will describe characteristics of its > endpoint). > > > > > >Regards, > >Stephane. > > > > > >-----Message d'origine----- > >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > de > >Espen Berger (espeberg) > >Envoy=E9 : mercredi 18 mai 2011 10:40 > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > >Objet : Re: [clue] Definitions > > > >I think we should keep both endpoints and MCUs in the definition > >document. > > > >One difference between endpoints and MCUs are how they handle media. > An > >endpoint usually send media representing itself and MCUs send media on > >behalf of others remote endpoint connected. > > > >Cheers > > > >-Espen > > > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >Stephan Wenger > >Sent: 17. mai 2011 06:17 > >To: Charles Eckel (eckelcu); CLUE > >Subject: Re: [clue] Definitions > > > >Hi Charles, > >Please see inline. > >In summary, I'm not convinced there is need for a change, though there > >may > >be need for more explanatory text. > >Stephan > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > >wrote: > > > >>Hi Stephan, > >> > >>This is a great start. I do not know if you volunteered to update as > >>well as provide the initial version of this document. In any case, > here > >>are some comments. > >> > >>> Endpoint - The logical point of final termination through > >>> receiving, decoding and rendering, and/or initiation through > >>> capturing, encoding, and sending of media streams. An endpoint > >>> consists of one or more physical devices which source and sink > >>> media streams. In contrast to an endpoint, a middle box, such > >>> as an MCU, may also send and receive media streams, but it is > >>> not the initiator nor the final terminator. > >> > >>I am not sure we should differentiate between endpoint and MCU. The > >>distinction blurs in that an MCU generates and send media streams > that > >>are not necessarily equivalent to those it received, and it receives > >>input from other endpoints. I think trying to distinguish them simply > >>makes more work and add complexity. I also think we will find that > the > >>majority of "MCUs" are really more "endpoints" than "MCUs". > >>You introduced the concept of remote. I am proposing remote =3D=3D > endpoint > >>and remove MCU. > > > >Not sure here. > >What "endpoint" attempts to express is that it is the logical entity > >facing the user--the room including microphones loudspeakers, screens, > >cameras, and some technical stuff that sends and receives RTP streams > >and > >implements signaling. We need such a definition certainly in the > >requirement spec but also in the use cases. There is also a "local" > >endpoint, which prohibits the use of "remote". > >I think we should leave this definition alone. > > > >> > >>> Media - Any data that, after suitable encoding, can be conveyed > >>> over RTP, including audio, video or timed text. > >> > >>I think this is too general, but I am not able to suggest a good way > to > >>improve it. > > > >Again, not sure why this is too general. > > > >> > >>> Session - RTP session. An association among a set of > >>> participants communicating with RTP. The distinguishing feature > >>> of an RTP session is that each maintains a full, separate space > >>> of SSRC identifiers. [RFC3550] > >> > >>In this case, do we also need a term for the collection of RTP > sessions > >>the contains the complete set media exchanged between two endpoints? > > > >Perhaps, though I don't think we have seen that need yet. > >Pm the media plane, there is really no such thing as "bundling" of > media > >transmission channels. There is a logical connection between multiple > >sessions, but only in the signaling. > > > >> > >> > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > >A Layout is the aggregation of all spatial relations of all > >capture/renderer devices at a given point in time? > >"Left speaker is left from right speaker" is a spatial relation. > >"Left microphone is co-located with left camera" is a spatial > relation. > >"Audio channel 1 is left, audio channel 2 is right, and there is only > >one > >center camera" is a layout. > > > >> > >>Cheers, > >>Charles > >> > >> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>Of Stephan Wenger > >>> Sent: Friday, May 13, 2011 11:08 AM > >>> To: CLUE > >>> Subject: [clue] Definitions > >>> > >>> Hi folks, > >>> Here a VERY rough initial draft. Addressing typos, sorting to > >>alphabetical, and other cleanup tasks > >>> will have to wait for the my return to the office next week. I > will > >>submit officially only after the > >>> most embarrassing bugs are sorted out. No need to comment on > typos, > >>but if you have substantial > >>> issues then send them now, and I can address them immediately. > >>> Stephan > >> > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Wed May 18 10:31:47 2011 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 83A62E06C2 for ; Wed, 18 May 2011 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YDCWvYF6muXL for ; Wed, 18 May 2011 10:31:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3EFE06B9 for ; Wed, 18 May 2011 10:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7550; q=dns/txt; s=iport; t=1305739906; x=1306949506; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=f7hRa4IDFvkxveYLwcKe7QwEHJayWC2iCD//4E3yowY=; b=iLwlYbC9mAAU6sMXYuW8cLSRcreTt793nTPud04jiZBLWuSBsh12Txzc NgtFGCodErdjU7Nll94/2sPfQAVg63K2wk/qDyFNuIqwd4Tlty0raDXbM J6cvdkMWHcuR9QpAs4+TOmThr1RdAjdyjqiO0w/7O2Veg2Ri/gkiO4uek Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAALYB1E2rRDoH/2dsb2JhbACXT45Nd6hrngCGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="450179636" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 18 May 2011 17:31:46 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4IHVjw6003745 for ; Wed, 18 May 2011 17:31:45 GMT Message-ID: <4DD40281.2050701@cisco.com> Date: Wed, 18 May 2011 13:31:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Definitions 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, 18 May 2011 17:31:47 -0000 Regarding left/right/..., Is "theater in the round" out of scope? If not, then left and right get dicy. Thanks, Paul On 5/18/2011 12:00 PM, Gorzynski, Mark E (The Right One) wrote: > ·Agree with the point (Botzko) that “spatial relations” should refer to > streams not devices. > > ·Also agree with the point (stated in several places) that left-right > should be clear and be defined with respect to a user facing the > displays. This will of course require being careful about maintaining > this convention when a stream is received. At a sender, a stream may be > thus defined as from the right-most display. But when it is received and > rendered on a display, that final destination will use the receiver’s > point of view. Thus a stream at Sender A may be labeled A-Right and then > sent to receiver B for output to display B-Left. I would not re-label > the stream from A to match the receiver convention. Thus streams might > be labeled with respect to the sender convention. > > ·We also should be careful when considering spatial relationships to not > make the system specific to odd or even numbers of streams in a spatial > relationship. Using left-right or > -2,-1,0,1,2 or such things may assume a centered system where one stream > is on a center axis or that there is a clear sense of when “right” > begins. This is not always true. For example a system with an even > number of displays and a camera above each display. Thus it may be most > efficient to use the sense of “left” to create a beginning of a spatial > relationship and order streams from that beginning, 0,1,2,… Thus we may > label a stream from the right-most display of a sender A as coming from > A.2 If that stream is sent to a receiver for output on a left most > display, that left most display destination may be B.0. > > Regards > > Mark Gorzynski > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* Wednesday, May 18, 2011 8:17 AM > *To:* Stephan Wenger > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > In-line - > Stephen Botzko > > On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger > wrote: > > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there may > be need for more explanatory text. > Stephan > > > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > wrote: > > >Hi Stephan, > > > >This is a great start. I do not know if you volunteered to update as > >well as provide the initial version of this document. In any case, here > >are some comments. > > > >> Endpoint - The logical point of final termination through > >> receiving, decoding and rendering, and/or initiation through > >> capturing, encoding, and sending of media streams. An endpoint > >> consists of one or more physical devices which source and sink > >> media streams. In contrast to an endpoint, a middle box, such > >> as an MCU, may also send and receive media streams, but it is > >> not the initiator nor the final terminator. > > > >I am not sure we should differentiate between endpoint and MCU. The > >distinction blurs in that an MCU generates and send media streams that > >are not necessarily equivalent to those it received, and it receives > >input from other endpoints. I think trying to distinguish them simply > >makes more work and add complexity. I also think we will find that the > >majority of "MCUs" are really more "endpoints" than "MCUs". > >You introduced the concept of remote. I am proposing remote == endpoint > >and remove MCU. > > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. > > > > > >> Media - Any data that, after suitable encoding, can be conveyed > >> over RTP, including audio, video or timed text. > > > >I think this is too general, but I am not able to suggest a good way to > >improve it. > > Again, not sure why this is too general. > > > > > >> Session - RTP session. An association among a set of > >> participants communicating with RTP. The distinguishing feature > >> of an RTP session is that each maintains a full, separate space > >> of SSRC identifiers. [RFC3550] > > > >In this case, do we also need a term for the collection of RTP sessions > >the contains the complete set media exchanged between two endpoints? > > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. > > > > > > > >"Layouts" vs. "Spatial Relations", what is the difference? > > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. > > Although these are all examples of spatial relations, I think we need to > be very careful to distinguish microphones and audio channels (and > cameras /video channels). Lots of audio systems use microphone arrays > and beam forming to get pickup in various parts of the room, and in > principle you could use similar techniques for video. > > So in practice, I think it is essential that we describe relationships > of streams, and not capture/render devices. > > Also, do we mean the "left camera" is physically located on the left, or > that it shows participants on the left? I think the latter is the > intent, and that it needs to be clear. Another reason perhaps to avoid > talking about camera placement. > > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] On Behalf > >Of Stephan Wenger > >> Sent: Friday, May 13, 2011 11:08 AM > >> To: CLUE > >> Subject: [clue] Definitions > >> > >> Hi folks, > >> Here a VERY rough initial draft. Addressing typos, sorting to > >alphabetical, and other cleanup tasks > >> will have to wait for the my return to the office next week. I will > >submit officially only after the > >> most embarrassing bugs are sorted out. No need to comment on typos, > >but if you have substantial > >> issues then send them now, and I can address them immediately. > >> Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Wed May 18 10:34:05 2011 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 19670E06C3 for ; Wed, 18 May 2011 10:34:05 -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 SkT6tNIA9YXb for ; Wed, 18 May 2011 10:34:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA0E06B3 for ; Wed, 18 May 2011 10:34:03 -0700 (PDT) Received: by vws12 with SMTP id 12so1557663vws.31 for ; Wed, 18 May 2011 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FkuCmjZsfPOc2GVquuB1Mko7r5plwK3wH+9TJoNnh2E=; b=kXf928nuz0xdf42fN9pwX1tMa5VZI39IbF+YQpjhfNL3jJ/qkXDZ6wky5Q7cjGUUS+ z8vW80BuvlIm7Jg0aDxae4Ame0eVEtpvQefArTawJW9mJBchKSsqNm1XpwFuNzePEF2n R6HLfOZBj957qOswkwawK9FHyXtCzhtd9RuUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s+OautUPpKTOfQGyIyotNpklaWfWj1pRp/ncLRuoYbb9ZcqUi2R27SdezjvtJj2YRp 4j/yVv9wTvUJe8WckMwgG+nXN5BV08g/X7eZkVIOEtWCsk2SwCbt9/xeqiVxnqLfkVd9 aUqM4UXEOok0bcgSlIfZ0rJLpunT+G+NYKziw= MIME-Version: 1.0 Received: by 10.52.116.42 with SMTP id jt10mr3084241vdb.36.1305740041754; Wed, 18 May 2011 10:34:01 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 10:34:01 -0700 (PDT) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> Date: Wed, 18 May 2011 13:34:01 -0400 Message-ID: From: Stephen Botzko To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=bcaec548a79f5b9e3404a3904b11 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions 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, 18 May 2011 17:34:05 -0000 --bcaec548a79f5b9e3404a3904b11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is my understanding also. BTW, there are some interesting interoperability issues that arise if you change the single UA assumption, due to the left/right reversal. If you us= e multiple devices in the room, you can either wire the left camera and the left display to the same codec, *or* you can wire the left camera and the right display to the same codec. Both designs work, but they are not interoperable with each other. Stephen Botzko On Wed, May 18, 2011 at 1:26 PM, Duckworth, Mark wrote: > Stephan, > > My understanding is an endpoint has a single SIP UA. And there would be > only one endpoint in a room. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Stephan Wenger > > Sent: Wednesday, May 18, 2011 2:00 AM > > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > > eckelcu@cisco.com; clue@ietf.org > > Subject: Re: [clue] Definitions > > > > Hi Stephane, > > Very good point. > > > > Quoting from RFC 4353 > > > > [...] > > Participant: The software element that connects a user or > automata to > > a conference. It implements, at a minimum, a SIP user agent, b= ut > > may also implement non-SIP-specific mechanisms for additional > > functionality. > > [...] > > > > My understanding of "endpoint" is that an endpoint encompasses ALL > > equipment in a telepresence room. I believe that there are cases where > we > > can have multiple SIP user agents (Uas) in one room. Think of a bunch = of > > codec boxes in a rack, all having their own UA. Is this the common > > understanding of the group? > > > > To ask the question differently, do we have an agreement that there is = a > > single SIP UA in one room? > > > > Guidance, please. > > > > Thanks, > > Stephan > > > > > > > > > > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > > wrote: > > > > >I don't think that we want to limit the "endpoint" definition to > > entities > > >facing a user. We could have entities not facing a user (e.g. an > > >automata), but which are sending/receiving media, and which need to > > >understand characteristics of the remote, and could maybe have also > > some > > >characteristics. I don't think we want to exclude such cases. > > > > > >Relying on the "participant" definition of RFC4353, a telepresence > > >conference will be composed of "participants", where a participant is > > >connected to the conference through an "endpoint". In telepresence, > > the > > >participant will have to be aware of the endpoint, in particular when > > the > > >participant needs to inform the remote of the characteristics of its > > >endpoint. > > > > > >Thus my proposition is to clarify that "endpoint" defines the entity > > >through which a participant (we do not limit to entity facing a user) > > is > > >connected to a telepresence conference. > > > > > >In the same manner, we could also use the "mixer" word instead of > > "MCU". > > > > > >Most of requirements should then apply on the participant or mixer > > >(typically, a participant will describe characteristics of its > > endpoint). > > > > > > > > >Regards, > > >Stephane. > > > > > > > > >-----Message d'origine----- > > >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > > de > > >Espen Berger (espeberg) > > >Envoy=E9 : mercredi 18 mai 2011 10:40 > > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > > >Objet : Re: [clue] Definitions > > > > > >I think we should keep both endpoints and MCUs in the definition > > >document. > > > > > >One difference between endpoints and MCUs are how they handle media. > > An > > >endpoint usually send media representing itself and MCUs send media on > > >behalf of others remote endpoint connected. > > > > > >Cheers > > > > > >-Espen > > > > > > > > >-----Original Message----- > > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > >Stephan Wenger > > >Sent: 17. mai 2011 06:17 > > >To: Charles Eckel (eckelcu); CLUE > > >Subject: Re: [clue] Definitions > > > > > >Hi Charles, > > >Please see inline. > > >In summary, I'm not convinced there is need for a change, though there > > >may > > >be need for more explanatory text. > > >Stephan > > > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > > >wrote: > > > > > >>Hi Stephan, > > >> > > >>This is a great start. I do not know if you volunteered to update as > > >>well as provide the initial version of this document. In any case, > > here > > >>are some comments. > > >> > > >>> Endpoint - The logical point of final termination through > > >>> receiving, decoding and rendering, and/or initiation through > > >>> capturing, encoding, and sending of media streams. An endpoint > > >>> consists of one or more physical devices which source and sink > > >>> media streams. In contrast to an endpoint, a middle box, such > > >>> as an MCU, may also send and receive media streams, but it is > > >>> not the initiator nor the final terminator. > > >> > > >>I am not sure we should differentiate between endpoint and MCU. The > > >>distinction blurs in that an MCU generates and send media streams > > that > > >>are not necessarily equivalent to those it received, and it receives > > >>input from other endpoints. I think trying to distinguish them simply > > >>makes more work and add complexity. I also think we will find that > > the > > >>majority of "MCUs" are really more "endpoints" than "MCUs". > > >>You introduced the concept of remote. I am proposing remote =3D=3D > > endpoint > > >>and remove MCU. > > > > > >Not sure here. > > >What "endpoint" attempts to express is that it is the logical entity > > >facing the user--the room including microphones loudspeakers, screens, > > >cameras, and some technical stuff that sends and receives RTP streams > > >and > > >implements signaling. We need such a definition certainly in the > > >requirement spec but also in the use cases. There is also a "local" > > >endpoint, which prohibits the use of "remote". > > >I think we should leave this definition alone. > > > > > >> > > >>> Media - Any data that, after suitable encoding, can be conveyed > > >>> over RTP, including audio, video or timed text. > > >> > > >>I think this is too general, but I am not able to suggest a good way > > to > > >>improve it. > > > > > >Again, not sure why this is too general. > > > > > >> > > >>> Session - RTP session. An association among a set of > > >>> participants communicating with RTP. The distinguishing feature > > >>> of an RTP session is that each maintains a full, separate space > > >>> of SSRC identifiers. [RFC3550] > > >> > > >>In this case, do we also need a term for the collection of RTP > > sessions > > >>the contains the complete set media exchanged between two endpoints? > > > > > >Perhaps, though I don't think we have seen that need yet. > > >Pm the media plane, there is really no such thing as "bundling" of > > media > > >transmission channels. There is a logical connection between multiple > > >sessions, but only in the signaling. > > > > > >> > > >> > > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > > > >A Layout is the aggregation of all spatial relations of all > > >capture/renderer devices at a given point in time? > > >"Left speaker is left from right speaker" is a spatial relation. > > >"Left microphone is co-located with left camera" is a spatial > > relation. > > >"Audio channel 1 is left, audio channel 2 is right, and there is only > > >one > > >center camera" is a layout. > > > > > >> > > >>Cheers, > > >>Charles > > >> > > >> > > >>> -----Original Message----- > > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>Of Stephan Wenger > > >>> Sent: Friday, May 13, 2011 11:08 AM > > >>> To: CLUE > > >>> Subject: [clue] Definitions > > >>> > > >>> Hi folks, > > >>> Here a VERY rough initial draft. Addressing typos, sorting to > > >>alphabetical, and other cleanup tasks > > >>> will have to wait for the my return to the office next week. I > > will > > >>submit officially only after the > > >>> most embarrassing bugs are sorted out. No need to comment on > > typos, > > >>but if you have substantial > > >>> issues then send them now, and I can address them immediately. > > >>> Stephan > > >> > > > > > > > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec548a79f5b9e3404a3904b11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is my understanding also.

BTW, there are some interesting inter= operability issues that arise if you change the single UA assumption, due t= o the left/right reversal.=A0 If you use multiple devices in the room, you = can either wire the left camera and the left display to the same codec, = or you can wire the left camera and the right display to the same codec= .=A0 Both designs work, but they are not interoperable with each other.

Stephen Botzko

On Wed, May 18, 2011 a= t 1:26 PM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:
Stephan,

My understanding is an endpoint has a single SIP UA. =A0And there would be = only one endpoint in a room.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Stephan Wenger
> Sent: Wednesday, May 18, 2011 2:00 AM
> To: stephane.ca= zeaux@orange-ftgroup.com; espeber= g@cisco.com;
> eckelcu@cisco.com; clue@ietf.org
> Subject: Re: [clue] Definitions
>
> Hi Stephane,
> Very good point.
>
> Quoting from RFC 4353
>
> [...]
> =A0 =A0 =A0 =A0 Participant: The software element that connects a user= or automata to
> =A0 =A0 =A0 =A0 a conference. =A0It implements, at a minimum, a SIP us= er agent, but
> =A0 =A0 =A0 =A0 may also implement non-SIP-specific mechanisms for add= itional
> =A0 =A0 =A0 =A0 functionality.
> [...]
>
> My understanding of "endpoint" is that an endpoint encompass= es ALL
> equipment in a telepresence room. =A0I believe that there are cases wh= ere we
> can have multiple SIP user agents (Uas) in one room. =A0Think of a bun= ch of
> codec boxes in a rack, all having their own UA. =A0Is this the common<= br> > understanding of the group?
>
> To ask the question differently, do we have an agreement that there is= a
> single SIP UA in one room?
>
> Guidance, please.
>
> Thanks,
> Stephan
>
>
>
>
> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com"
> <stephane.ca= zeaux@orange-ftgroup.com> wrote:
>
> >I don't think that we want to limit the "endpoint" d= efinition to
> entities
> >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need t= o
> >understand characteristics of the remote, and could maybe have als= o
> some
> >characteristics. I don't think we want to exclude such cases.<= br> > >
> >Relying on the "participant" definition of RFC4353, a te= lepresence
> >conference will be composed of "participants", where a p= articipant is
> >connected to the conference through an "endpoint". In te= lepresence,
> the
> >participant will have to be aware of the endpoint, in particular w= hen
> the
> >participant needs to inform the remote of the characteristics of i= ts
> >endpoint.
> >
> >Thus my proposition is to clarify that "endpoint" define= s the entity
> >through which a participant (we do not limit to entity facing a us= er)
> is
> >connected to a telepresence conference.
> >
> >In the same manner, we could also use the "mixer" word i= nstead of
> "MCU".
> >
> >Most of requirements should then apply on the participant or mixer=
> >(typically, a participant will describe characteristics of its
> endpoint).
> >
> >
> >Regards,
> >Stephane.
> >
> >
> >-----Message d'origine-----
> >De : clue-bounces@ietf.or= g [mailto:clue-bounces@ietf.or= g] De la part
> de
> >Espen Berger (espeberg)
> >Envoy=E9 : mercredi 18 mai 2011 10:40
> >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE
> >Objet : Re: [clue] Definitions
> >
> >I think we should keep both endpoints and MCUs in the definition > >document.
> >
> >One difference between endpoints and MCUs are how they handle medi= a.
> An
> >endpoint usually send media representing itself and MCUs send medi= a on
> >behalf of others remote endpoint connected.
> >
> >Cheers
> >
> >-Espen
> >
> >
> >-----Original Message-----
> >From: clue-bounces@ietf.o= rg [mailto:clue-bounces@ietf.o= rg] On Behalf
> Of
> >Stephan Wenger
> >Sent: 17. mai 2011 06:17
> >To: Charles Eckel (eckelcu); CLUE
> >Subject: Re: [clue] Definitions
> >
> >Hi Charles,
> >Please see inline.
> >In summary, I'm not convinced there is need for a change, thou= gh there
> >may
> >be need for more explanatory text.
> >Stephan
> >
> >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> >wrote:
> >
> >>Hi Stephan,
> >>
> >>This is a great start. I do not know if you volunteered to upd= ate as
> >>well as provide the initial version of this document. In any c= ase,
> here
> >>are some comments.
> >>
> >>> Endpoint - The logical point of final termination through=
> >>> receiving, decoding and rendering, and/or initiation thro= ugh
> >>> capturing, encoding, and sending of media streams. =A0An = endpoint
> >>> consists of one or more physical devices which source and= sink
> >>> media streams. =A0In contrast to an endpoint, a middle bo= x, such
> >>> as an MCU, may also send and receive media streams, but i= t is
> >>> not the initiator nor the final terminator.
> >>
> >>I am not sure we should differentiate between endpoint and MCU= . The
> >>distinction blurs in that an MCU generates and send media stre= ams
> that
> >>are not necessarily equivalent to those it received, and it re= ceives
> >>input from other endpoints. I think trying to distinguish them= simply
> >>makes more work and add complexity. I also think we will find = that
> the
> >>majority of "MCUs" are really more "endpoints&q= uot; than "MCUs".
> >>You introduced the concept of remote. I am proposing remote = =3D=3D
> endpoint
> >>and remove MCU.
> >
> >Not sure here.
> >What "endpoint" attempts to express is that it is the lo= gical entity
> >facing the user--the room including microphones loudspeakers, scre= ens,
> >cameras, and some technical stuff that sends and receives RTP stre= ams
> >and
> >implements signaling. =A0We need such a definition certainly in th= e
> >requirement spec but also in the use cases. =A0There is also a &qu= ot;local"
> >endpoint, which prohibits the use of "remote".
> >I think we should leave this definition alone.
> >
> >>
> >>> Media - Any data that, after suitable encoding, can be co= nveyed
> >>> over RTP, including audio, video or timed text.
> >>
> >>I think this is too general, but I am not able to suggest a go= od way
> to
> >>improve it.
> >
> >Again, not sure why this is too general.
> >
> >>
> >>> Session - RTP session. =A0An association among a set of > >>> participants communicating with RTP. =A0The distinguishin= g feature
> >>> of an RTP session is that each maintains a full, separate= space
> >>> of SSRC identifiers. =A0[RFC3550]
> >>
> >>In this case, do we also need a term for the collection of RTP=
> sessions
> >>the contains the complete set media exchanged between two endp= oints?
> >
> >Perhaps, though I don't think we have seen that need yet.
> >Pm the media plane, there is really no such thing as "bundlin= g" of
> media
> >transmission channels. =A0There is a logical connection between mu= ltiple
> >sessions, but only in the signaling.
> >
> >>
> >>
> >>"Layouts" vs. "Spatial Relations", what is= the difference?
> >
> >A Layout is the aggregation of all spatial relations of all
> >capture/renderer devices at a given point in time?
> >"Left speaker is left from right speaker" is a spatial r= elation.
> >"Left microphone is co-located with left camera" is a sp= atial
> relation.
> >"Audio channel 1 is left, audio channel 2 is right, and there= is only
> >one
> >center camera" is a layout.
> >
> >>
> >>Cheers,
> >>Charles
> >>
> >>
> >>> -----Original Message-----
> >>> From: clue-bounc= es@ietf.org [mailto:clue-bounc= es@ietf.org] On
> Behalf
> >>Of Stephan Wenger
> >>> Sent: Friday, May 13, 2011 11:08 AM
> >>> To: CLUE
> >>> Subject: [clue] Definitions
> >>>
> >>> Hi folks,
> >>> Here a VERY rough initial draft. =A0Addressing typos, sor= ting to
> >>alphabetical, and other cleanup tasks
> >>> will have to wait for the my return to the office next we= ek. =A0I
> will
> >>submit officially only after the
> >>> most embarrassing bugs are sorted out. =A0No need to comm= ent on
> typos,
> >>but if you have substantial
> >>> issues then send them now, and I can address them immedia= tely.
> >>> Stephan
> >>
> >
> >
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/clue
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec548a79f5b9e3404a3904b11-- From mark.gorzynski@hp.com Wed May 18 11:11:54 2011 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 32E9BE0766 for ; Wed, 18 May 2011 11:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gnmrJNxDLlAw for ; Wed, 18 May 2011 11:11:48 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8B678E072C for ; Wed, 18 May 2011 11:11:48 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 10D4EC86F for ; Wed, 18 May 2011 18:11:48 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 18:10:47 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Wed, 18 May 2011 18:10:47 +0000 From: "Gorzynski, Mark E (The Right One)" To: CLUE Date: Wed, 18 May 2011 18:10:44 +0000 Thread-Topic: [clue] Definitions Thread-Index: AcwVdZtMkbXEA+TMSniMIGhDQW81twAEDsIA Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6C5FD28@GVW1096EXB.americas.hpqcorp.net> References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FD28GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions 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, 18 May 2011 18:11:54 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FD28GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding complex environments where users are seated in multiple direction= s or in the round, can we consider the convention direction as relative to = facing a media system like a display? Is there at least a clock-wise sense= to media acquisition and reproduction where there as a counter-clockwise m= ost element and that is first (left most)? This is still pushing the conce= pt of a single-dimension to order. >From a stream generation point of view, there may indeed be media streams w= ith no logical order / spatial relation relative to other streams generated= by the same endpoint. Can we support both ordered / spatially related and= unordered un-spatially related streams from end points? Do we need a hig= her dimensional (greater than 1 dimension) means of specifying order? Mark Gorzynski From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 18, 2011 9:07 AM To: Gorzynski, Mark E (The Right One) Cc: CLUE Subject: Re: [clue] Definitions I note we have at least one use case where users in the same room are facin= g in different directions. Stephen Botzko On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) > wrote: * Agree with the point (Botzko) that "spatial relations" should refe= r to streams not devices. * Also agree with the point (stated in several places) that left-rig= ht should be clear and be defined with respect to a user facing the display= s. This will of course require being careful about maintaining this conven= tion when a stream is received. At a sender, a stream may be thus defined = as from the right-most display. But when it is received and rendered on a = display, that final destination will use the receiver's point of view. Thu= s a stream at Sender A may be labeled A-Right and then sent to receiver B f= or output to display B-Left. I would not re-label the stream from A to mat= ch the receiver convention. Thus streams might be labeled with respect to = the sender convention. * We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spati= al relationship. Using left-right or -2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when "right" begins. T= his is not always true. For example a system with an even number of displa= ys and a camera above each display. Thus it may be most efficient to use t= he sense of "left" to create a beginning of a spatial relationship and orde= r streams from that beginning, 0,1,2,... Thus we may label a stream from t= he right-most display of a sender A as coming from A.2 If that stream is s= ent to a receiver for output on a left most display, that left most display= destination may be B.0. Regards Mark Gorzynski From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, May 18, 2011 8:17 AM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] Definitions In-line - Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger > wrote: Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoin= t >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. Although these are all examples of spatial relations, I think we need to be= very careful to distinguish microphones and audio channels (and cameras /v= ideo channels). Lots of audio systems use microphone arrays and beam formi= ng to get pickup in various parts of the room, and in principle you could u= se similar techniques for video. So in practice, I think it is essential that we describe relationships of s= treams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or th= at it shows participants on the left? I think the latter is the intent, an= d that it needs to be clear. Another reason perhaps to avoid talking about= camera placement. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >> >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FD28GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding= complex environments where users are seated in multiple directions or in t= he round, can we consider the convention direction as relative to facing a = media system like a display?  Is there at least a clock-wise sense to = media acquisition and reproduction where there as a counter-clockwise most = element and that is first (left most)?  This is still pushing the conc= ept of a single-dimension to order.

 

From a st= ream generation point of view, there may indeed be media streams with no lo= gical order / spatial relation relative to other streams generated by the s= ame endpoint.  Can we support both ordered / spatially related and uno= rdered  un-spatially related streams from end points?  Do we need= a higher dimensional (greater than 1 dimension) means of specifying order?=

 <= /p>

Mark Gorzynski

 

From: Stephen Botzko [mailto:stephen.botzko@gmail.c= om]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynsk= i, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clue] = Definitions

 

=

I note we have at least= one use case where users in the same room are facing in different directio= ns.

Stephen Botzko

On Wed, M= ay 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:

· = ;       Agree with the point (Botzko) that “spatial relation= s” should refer to streams not devices. 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

= ·  &n= bsp;     Also agree with the point (stated in several places) that left-righ= t should be clear and be defined with respect to a user facing the displays= .  This will of course require being careful about maintaining this co= nvention when a stream is received.  At a sender, a stream may be thus= defined as from the right-most display.  But when it is received and = rendered on a display, that final destination will use the receiver’s= point of view.  Thus a stream at Sender A may be labeled A-Right and = then sent to receiver B for output to display B-Left.  I would not re-= label the stream from A to match the receiver convention.  Thus stream= s might be labeled with respect to the sender convention.=

 

·  &= nbsp;     We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spati= al relationship.  Using left-right or
-2,-1,0,1,2 or such things m= ay assume a centered system where one stream is on a center axis or that th= ere is a clear sense of when “right” begins.  This is not = always true.  For example a system with an even number of displays and= a camera above each display.  Thus it may be most efficient to use th= e sense of “left” to create a beginning of a spatial relationsh= ip and order streams from that beginning, 0,1,2,…  Thus we may l= abel a stream from the right-most display of a sender A as coming from A.2&= nbsp; If that stream is sent to a receiver for output on a left most displa= y, that left most display destination may be B.0.

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Regards

Mark Gorzynski=

&nb= sp;

 

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Be= half Of Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM<= br>To: Stephan Wenger
Cc: CLUE
Subject: Re: [clu= e] Definitions

 

In-line - =
Stephen Botzko

On Tue, May 17, 201= 1 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,=
Please see inline.
In summary, I'm not convinced there is need for a= change, though there may
be need for more explanatory text.
Stephan<= o:p>


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)&= quot; <eckelcu@ci= sco.com> wrote:

>Hi Stephan,
>
>This is a grea= t start. I do not know if you volunteered to update as
>well as provi= de the initial version of this document. In any case, here
>are some = comments.
>
>> Endpoint - The logical point of final termina= tion through
>> receiving, decoding and rendering, and/or initiati= on through
>> capturing, encoding, and sending of media streams. &= nbsp;An endpoint
>> consists of one or more physical devices which= source and sink
>> media streams.  In contrast to an endpoin= t, a middle box, such
>> as an MCU, may also send and receive medi= a streams, but it is
>> not the initiator nor the final terminator= .
>
>I am not sure we should differentiate between endpoint and= MCU. The
>distinction blurs in that an MCU generates and send media = streams that
>are not necessarily equivalent to those it received, an= d it receives
>input from other endpoints. I think trying to distingu= ish them simply
>makes more work and add complexity. I also think we = will find that the
>majority of "MCUs" are really more &quo= t;endpoints" than "MCUs".
>You introduced the concept = of remote. I am proposing remote =3D=3D endpoint
>and remove MCU.

Not sure here.
What "endpoint" attempt= s to express is that it is the logical entity
facing the user--the room = including microphones loudspeakers, screens,
cameras, and some technical= stuff that sends and receives RTP streams and
implements signaling. &nb= sp;We need such a definition certainly in the
requirement spec but also = in the use cases.  There is also a "local"
endpoint, whic= h prohibits the use of "remote".
I think we should leave this = definition alone.


>
>> Media - Any data= that, after suitable encoding, can be conveyed
>> over RTP, inclu= ding audio, video or timed text.
>
>I think this is too general= , but I am not able to suggest a good way to
>improve it.<= /p>

Again, not sure why this is too general.


>
>> Session - RTP session.  An association among a = set of
>> participants communicating with RTP.  The distingui= shing feature
>> of an RTP session is that each maintains a full, = separate space
>> of SSRC identifiers.  [RFC3550]
>
= >In this case, do we also need a term for the collection of RTP sessions=
>the contains the complete set media exchanged between two endpoints= ?

Perhaps, though I don't think we have seen tha= t need yet.
Pm the media plane, there is really no such thing as "b= undling" of media
transmission channels.  There is a logical c= onnection between multiple
sessions, but only in the signaling.


>
>
>"Layouts" vs. "Spatial R= elations", what is the difference?

A Layout= is the aggregation of all spatial relations of all
capture/renderer dev= ices at a given point in time?
"Left speaker is left from right spe= aker" is a spatial relation.
"Left microphone is co-located wi= th left camera" is a spatial relation.
"Audio channel 1 is lef= t, audio channel 2 is right, and there is only one
center camera" i= s a layout.

 

Although these are all examples of spatial relations, I think = we need to be very careful to distinguish microphones and audio channels (a= nd cameras /video channels).  Lots of audio systems use microphone arr= ays and beam forming to get pickup in various parts of the room, and in pri= nciple you could use similar techniques for video.

So in practice, I= think it is essential that we describe relationships of streams, and not c= apture/render devices.

Also, do we mean the "left camera" = is physically located on the left, or that it shows participants on the lef= t?  I think the latter is the intent, and that it needs to be clear.&n= bsp; Another reason perhaps to avoid talking about camera placement.
&nb= sp;

>
>Cheers,=
>Charles
>
>
>> -----Original Message-----
&= gt;> From: cl= ue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Weng= er
>> Sent: Friday, May 13, 2011 11:08 AM
>> To: CLUE
= >> Subject: [clue] Definitions
>>
>> Hi folks,
&= gt;> Here a VERY rough initial draft.  Addressing typos, sorting to=
>alphabetical, and other cleanup tasks
>> will have to wait= for the my return to the office next week.  I will
>submit offi= cially only after the
>> most embarrassing bugs are sorted out. &n= bsp;No need to comment on typos,
>but if you have substantial
>= > issues then send them now, and I can address them immediately.
>= > Stephan
>


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

 

=


_= ______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailma= n/listinfo/clue

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FD28GVW1096EXBame_-- From Even.roni@huawei.com Wed May 18 11:15:13 2011 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 D0671E072C for ; Wed, 18 May 2011 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFzkl8ytaBx2 for ; Wed, 18 May 2011 11:15:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6C7E06C2 for ; Wed, 18 May 2011 11:15:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00LWWLD6XP@szxga04-in.huawei.com> for clue@ietf.org; Thu, 19 May 2011 02:15:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00E8ULD60I@szxga04-in.huawei.com> for clue@ietf.org; Thu, 19 May 2011 02:15:06 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-46-33.red.bezeqint.net [79.178.46.33]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLE001KTLCVWM@szxml12-in.huawei.com>; Thu, 19 May 2011 02:15:05 +0800 (CST) Date: Wed, 18 May 2011 21:13:21 +0300 From: Roni Even In-reply-to: To: "'Mike Hammer (hmmr)'" , "'Paul Kyzivat (pkyzivat)'" Message-id: <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQAAlDx0A= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 18:15:13 -0000 Hi, I think this is a good example. It is very easy to select between two different media types, like accept audio and reject video like Paul gives as an example. Once you have two or more media lines with the same media type like multiple video line you can hope that the first video line will be used by an endpoint that do not support multiple video lines but I am not aware that this behavior is defined in any document. In the case of grouping once you ignore the grouping lines you are left with a list of m-lines and I think this is why RFC 5888 say that other things may happen. Anyhow we are discussing solution while my point is that we will need as a requirement to address the case of a call from a CLUE aware endpoint to a non CLUE aware endpoint. Even if the consensus will be to have the preferred video in the first video m-line. Regards Roni > -----Original Message----- > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > Sent: Wednesday, May 18, 2011 4:41 PM > To: Paul Kyzivat (pkyzivat); Roni Even > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > Paul, > > I would agree that if the offer-answer model semantic is that here are > several options and any subset of options is acceptable. > > However, if there is any grouping involved such that you need to have a > video and audio feed integrated to make sense then watch out. > > For example, I wouldn't want to end up with the result of a man's video > paired with a woman's voice. That could be rather comical. > > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 17, 2011 7:45 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > Paul, > > I think we read it differently. > > If the answerer does not support the group attribute and the offer > had > the > > fid semantics it may look to the answerer as an offer with multiple > m-lines > > of the same media tyoe. In this case an implementation might also > decide to > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > Acceptable), > > because it contains several "m" lines of the same media type. > > That is a slightly different story. > > Then the reason for rejection is not because it saw an attribute it > didn't understand - its because it didn't like something it *did* > understand. > > > This is very relevant to the multiple streams case and we should look > if we > > state this behavior or we will look at providing an approach that > will > allow > > the answerer to choose one m-line that the offerer prefers even of it > does > > not understand CLUE. > > IMO (lets see if others differ), if a UA receives an offer with at > least > > one m-line it is happy with, then it should not reject the call because > there are others that it does not "understand". > > Here "understand" means something different - presumably it does > understand the direct meaning of the additional m-line, it just doesn't > understand the *significance* or use of it. > > I see little difference to getting to audio m-lines and only wanting > one, and getting one audio and one video and only supporting audio. In > general you should not reject an audio/video call just because you only > support audio. > > I think it will behoove clue to strongly recommend that the m-lines in > an offer be arranged so the first ones are the ones it most wants used > if not all are. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, May 18, 2011 12:37 AM > >> To: Roni Even > >> Cc: 'Stephen Botzko'; clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> Paul, > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example > >>> Roni > >> > >> OK, I looked. It is consistent with what I said. > >> Either a=group: is understood, or not. If not, its ignored, and not > put > >> in the answer. Same with a=mid: > >> > >> If a=group: *is* understood, but some parameter within it is not, > there > >> are explicit rules for what to do. > >> > >> AFAICT there are no examples in this document where failure to > >> understand an a-line in total (or even in part) results in rejecting > >> the > >> offer. > >> > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> Of > >>>> Paul Kyzivat > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>> To: Stephen Botzko > >>>> Cc: clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>>> > >>>> > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>> > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>> > >>>>> When the offer includes parameters that the answerer > does > >> not > >>>>> understand > >>>>> there are two options, he can ignore the unknown > >> parameters > >>>> or > >>>>> reject > >>>>> the offer. > >>>>> Rejecting the offer in that case is not really kosher. > >>>>> You are required to ignore parameters you do not > understand. > >>>>> > >>>>> If you reject something because you don't like the > parameters > >> it > >>>>> contains, then that is an implicit statement that you > >> understand > >>>>> those parameters well enough to decide to reject them. > >>>>> > >>>>> As far as I know, you are always free to reject offers, and it > >>>> doesn't > >>>>> really imply anything when you do that.. Whether it is wise is > >>>> perhaps > >>>>> a different question. > >>>>> Stephen Botzko > >>>> > >>>> Certainly you are always free to reject an offer. > >>>> In general I don't know for certain the reason why, and so if I > give > >>>> you > >>>> the benefit of the doubt I will assume you have a valid reason - > >>>> perhaps > >>>> just policy. > >>>> > >>>> But if the reason you reject the offer is based on your violating > a > >>>> spec, then you are non-conforming, whether I can determine you are > >>>> non-conforming or not. Whether being non-conforming is just > un-wise, > >> or > >>>> something stronger, is a separate discussion. The IETF does not > levy > >>>> any > >>>> penalties for violating its specs. But sometimes the market does. > >> (And > >>>> sometimes not.) But we don't need to endorse non-conforming > behavior > >> in > >>>> our documents. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Wed May 18 11:17:19 2011 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 6BC14E076B for ; Wed, 18 May 2011 11:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TTZ-E5cLxVp for ; Wed, 18 May 2011 11:17:18 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 68599E06C2 for ; Wed, 18 May 2011 11:17:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00M6TLGI5G@szxga04-in.huawei.com> for clue@ietf.org; Thu, 19 May 2011 02:17:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00LKJLGI39@szxga04-in.huawei.com> for clue@ietf.org; Thu, 19 May 2011 02:17:06 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-46-33.red.bezeqint.net [79.178.46.33]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLE001N9LG8WM@szxml12-in.huawei.com>; Thu, 19 May 2011 02:17:06 +0800 (CST) Date: Wed, 18 May 2011 21:15:23 +0300 From: Roni Even In-reply-to: <4DD3FD0E.8020503@cisco.com> To: 'Paul Kyzivat' , "'Mike Hammer (hmmr)'" Message-id: <023701cc1587$93dc0520$bb940f60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwVfqSwdlWR7YKiTAyWfDIWg9T7zwACMcKg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 18:17:19 -0000 Paul, I am not saying you are wrong, I am just saying that RFC 5888 says that you may also encounter a case where the answerer will reject the call. Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 8:09 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > > Paul, > > > > I would agree that if the offer-answer model semantic is that here > are > > several options and any subset of options is acceptable. > > > > However, if there is any grouping involved such that you need to have > a > > video and audio feed integrated to make sense then watch out. > > > > For example, I wouldn't want to end up with the result of a man's > video > > paired with a woman's voice. That could be rather comical. > > Well, SDP defines that you should ignore what you don't understand and > operate on what is left. > > So someone constructing an SDP with grouping issues such as you define > ought to keep in mind that this could happen, and set things up so that > something reasonable happens. You can't expect the dumb legacy device > to > figure out much. > > For your example, the result may be far from ideal, but it still is > likely to be better than no call at all. And if not, there is always > the > option of hanging up. But better, presumably the offer could have been > constructed in a way that produced a better result. > > Thanks, > Paul > > > Mike > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat (pkyzivat) > > Sent: Tuesday, May 17, 2011 7:45 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >> Paul, > >> I think we read it differently. > >> If the answerer does not support the group attribute and the offer > had > > the > >> fid semantics it may look to the answerer as an offer with multiple > > m-lines > >> of the same media tyoe. In this case an implementation might also > > decide to > >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > Acceptable), > >> because it contains several "m" lines of the same media type. > > > > That is a slightly different story. > > > > Then the reason for rejection is not because it saw an attribute it > > didn't understand - its because it didn't like something it *did* > > understand. > > > >> This is very relevant to the multiple streams case and we should > look > > if we > >> state this behavior or we will look at providing an approach that > will > > allow > >> the answerer to choose one m-line that the offerer prefers even of > it > > does > >> not understand CLUE. > > > > IMO (lets see if others differ), if a UA receives an offer with at > least > > > > one m-line it is happy with, then it should not reject the call > because > > there are others that it does not "understand". > > > > Here "understand" means something different - presumably it does > > understand the direct meaning of the additional m-line, it just > doesn't > > understand the *significance* or use of it. > > > > I see little difference to getting to audio m-lines and only wanting > > one, and getting one audio and one video and only supporting audio. > In > > general you should not reject an audio/video call just because you > only > > support audio. > > > > I think it will behoove clue to strongly recommend that the m-lines > in > > an offer be arranged so the first ones are the ones it most wants > used > > if not all are. > > > > Thanks, > > Paul > > > >> Roni > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Wednesday, May 18, 2011 12:37 AM > >>> To: Roni Even > >>> Cc: 'Stephen Botzko'; clue@ietf.org > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> > >>> > >>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>> Paul, > >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example > >>>> Roni > >>> > >>> OK, I looked. It is consistent with what I said. > >>> Either a=group: is understood, or not. If not, its ignored, and not > > put > >>> in the answer. Same with a=mid: > >>> > >>> If a=group: *is* understood, but some parameter within it is not, > > there > >>> are explicit rules for what to do. > >>> > >>> AFAICT there are no examples in this document where failure to > >>> understand an a-line in total (or even in part) results in > rejecting > >>> the > >>> offer. > >>> > >>> Thanks, > >>> Paul > >>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > >>> Of > >>>>> Paul Kyzivat > >>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>> To: Stephen Botzko > >>>>> Cc: clue@ietf.org > >>>>> Subject: Re: [clue] legacy support in requirements > >>>>> > >>>>> > >>>>> > >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>> > >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>> > >>>>>> When the offer includes parameters that the answerer > > does > >>> not > >>>>>> understand > >>>>>> there are two options, he can ignore the unknown > >>> parameters > >>>>> or > >>>>>> reject > >>>>>> the offer. > >>>>>> Rejecting the offer in that case is not really kosher. > >>>>>> You are required to ignore parameters you do not > understand. > >>>>>> > >>>>>> If you reject something because you don't like the > > parameters > >>> it > >>>>>> contains, then that is an implicit statement that you > >>> understand > >>>>>> those parameters well enough to decide to reject them. > >>>>>> > >>>>>> As far as I know, you are always free to reject offers, and it > >>>>> doesn't > >>>>>> really imply anything when you do that.. Whether it is wise is > >>>>> perhaps > >>>>>> a different question. > >>>>>> Stephen Botzko > >>>>> > >>>>> Certainly you are always free to reject an offer. > >>>>> In general I don't know for certain the reason why, and so if I > > give > >>>>> you > >>>>> the benefit of the doubt I will assume you have a valid reason - > >>>>> perhaps > >>>>> just policy. > >>>>> > >>>>> But if the reason you reject the offer is based on your violating > a > >>>>> spec, then you are non-conforming, whether I can determine you > are > >>>>> non-conforming or not. Whether being non-conforming is just > > un-wise, > >>> or > >>>>> something stronger, is a separate discussion. The IETF does not > > levy > >>>>> any > >>>>> penalties for violating its specs. But sometimes the market does. > >>> (And > >>>>> sometimes not.) But we don't need to endorse non-conforming > > behavior > >>> in > >>>>> our documents. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> > >> > >> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > From christer.holmberg@ericsson.com Wed May 18 11:27:12 2011 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 ACA2DE06B1 for ; Wed, 18 May 2011 11:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khLjUIadWFV7 for ; Wed, 18 May 2011 11:27:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAAE06CF for ; Wed, 18 May 2011 11:27:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-22-4dd40f7c547e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.F5.20773.C7F04DD4; Wed, 18 May 2011 20:27:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 18 May 2011 20:27:08 +0200 From: Christer Holmberg To: 'Roni Even' , 'Paul Kyzivat' , "'Mike Hammer (hmmr)'" Date: Wed, 18 May 2011 20:27:07 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwVfqSwdlWR7YKiTAyWfDIWg9T7zwACMcKgAABTNrA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C836@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <023701cc1587$93dc0520$bb940f60$%roni@huawei.com> In-Reply-To: <023701cc1587$93dc0520$bb940f60$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 18:27:12 -0000 Hi Roni,=20 >I am not saying you are wrong, I am just saying that RFC 5888 says that yo= u may also encounter a case where the answerer will reject the call. In my opinion the call would be rejected even without the presence of the d= o-not-understand elements, because the rejection decission is based on what= IS understood. (Of course, some implementiations may reject things based on the presence o= f do-not-understand elements, but that is not standardized behavior.) If you want to mandate someone to understand something, you need to place a= n associated option-tag in the Require header field. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 8:09 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 >=20 >=20 > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > > Paul, > > > > I would agree that if the offer-answer model semantic is that here > are > > several options and any subset of options is acceptable. > > > > However, if there is any grouping involved such that you need to=20 > > have > a > > video and audio feed integrated to make sense then watch out. > > > > For example, I wouldn't want to end up with the result of a man's > video > > paired with a woman's voice. That could be rather comical. >=20 > Well, SDP defines that you should ignore what you don't understand and=20 > operate on what is left. >=20 > So someone constructing an SDP with grouping issues such as you define=20 > ought to keep in mind that this could happen, and set things up so=20 > that something reasonable happens. You can't expect the dumb legacy=20 > device to figure out much. >=20 > For your example, the result may be far from ideal, but it still is=20 > likely to be better than no call at all. And if not, there is always=20 > the option of hanging up. But better, presumably the offer could have=20 > been constructed in a way that produced a better result. >=20 > Thanks, > Paul >=20 > > Mike > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat (pkyzivat) > > Sent: Tuesday, May 17, 2011 7:45 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >> Paul, > >> I think we read it differently. > >> If the answerer does not support the group attribute and the offer > had > > the > >> fid semantics it may look to the answerer as an offer with multiple > > m-lines > >> of the same media tyoe. In this case an implementation might also > > decide to > >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > Acceptable), > >> because it contains several "m" lines of the same media type. > > > > That is a slightly different story. > > > > Then the reason for rejection is not because it saw an attribute it=20 > > didn't understand - its because it didn't like something it *did*=20 > > understand. > > > >> This is very relevant to the multiple streams case and we should > look > > if we > >> state this behavior or we will look at providing an approach that > will > > allow > >> the answerer to choose one m-line that the offerer prefers even of > it > > does > >> not understand CLUE. > > > > IMO (lets see if others differ), if a UA receives an offer with at > least > > > > one m-line it is happy with, then it should not reject the call > because > > there are others that it does not "understand". > > > > Here "understand" means something different - presumably it does=20 > > understand the direct meaning of the additional m-line, it just > doesn't > > understand the *significance* or use of it. > > > > I see little difference to getting to audio m-lines and only wanting=20 > > one, and getting one audio and one video and only supporting audio. > In > > general you should not reject an audio/video call just because you > only > > support audio. > > > > I think it will behoove clue to strongly recommend that the m-lines > in > > an offer be arranged so the first ones are the ones it most wants > used > > if not all are. > > > > Thanks, > > Paul > > > >> Roni > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Wednesday, May 18, 2011 12:37 AM > >>> To: Roni Even > >>> Cc: 'Stephen Botzko'; clue@ietf.org > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> > >>> > >>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>> Paul, > >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example > >>>> Roni > >>> > >>> OK, I looked. It is consistent with what I said. > >>> Either a=3Dgroup: is understood, or not. If not, its ignored, and=20 > >>> not > > put > >>> in the answer. Same with a=3Dmid: > >>> > >>> If a=3Dgroup: *is* understood, but some parameter within it is not, > > there > >>> are explicit rules for what to do. > >>> > >>> AFAICT there are no examples in this document where failure to=20 > >>> understand an a-line in total (or even in part) results in > rejecting > >>> the > >>> offer. > >>> > >>> Thanks, > >>> Paul > >>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > >>> Of > >>>>> Paul Kyzivat > >>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>> To: Stephen Botzko > >>>>> Cc: clue@ietf.org > >>>>> Subject: Re: [clue] legacy support in requirements > >>>>> > >>>>> > >>>>> > >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>> > >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>> > >>>>>> When the offer includes parameters that the answerer > > does > >>> not > >>>>>> understand > >>>>>> there are two options, he can ignore the unknown > >>> parameters > >>>>> or > >>>>>> reject > >>>>>> the offer. > >>>>>> Rejecting the offer in that case is not really kosher. > >>>>>> You are required to ignore parameters you do not > understand. > >>>>>> > >>>>>> If you reject something because you don't like the > > parameters > >>> it > >>>>>> contains, then that is an implicit statement that you > >>> understand > >>>>>> those parameters well enough to decide to reject them. > >>>>>> > >>>>>> As far as I know, you are always free to reject offers, and it > >>>>> doesn't > >>>>>> really imply anything when you do that.. Whether it is wise is > >>>>> perhaps > >>>>>> a different question. > >>>>>> Stephen Botzko > >>>>> > >>>>> Certainly you are always free to reject an offer. > >>>>> In general I don't know for certain the reason why, and so if I > > give > >>>>> you > >>>>> the benefit of the doubt I will assume you have a valid reason -=20 > >>>>> perhaps just policy. > >>>>> > >>>>> But if the reason you reject the offer is based on your=20 > >>>>> violating > a > >>>>> spec, then you are non-conforming, whether I can determine you > are > >>>>> non-conforming or not. Whether being non-conforming is just > > un-wise, > >>> or > >>>>> something stronger, is a separate discussion. The IETF does not > > levy > >>>>> any > >>>>> penalties for violating its specs. But sometimes the market does. > >>> (And > >>>>> sometimes not.) But we don't need to endorse non-conforming > > behavior > >>> in > >>>>> our documents. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> > >> > >> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Wed May 18 11:32:24 2011 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 C1D19E06C8 for ; Wed, 18 May 2011 11:32: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=[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 KgPvLx2TN9OG for ; Wed, 18 May 2011 11:32:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C280EE06B1 for ; Wed, 18 May 2011 11:32:22 -0700 (PDT) Received: by vxg33 with SMTP id 33so1585386vxg.31 for ; Wed, 18 May 2011 11:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=40fK452n3XaTd7oLvPw9jVweaPRFlti4x95DkTXG7oM=; b=gYlnJLVeRAwZ/d/cwZJ2xuwzPJCGCj3ARCzyHJ2u5KVjEiq6c7h+3YhVzhvhTXcDP2 sNBIog7ZQrDESxxAmF09cCmXmxmxxe8vOEe8plqOR5BkJJhr/tDJcy6Lpht0iWR/BR8V WGVq0ddnPOc0Uyj+eoobcPTbgFkND3ZPnIGnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Okt3XbPhPG53ktCrZ2j6lAEbWV3K83oGaCCQ2shBnE99g26awMjOL63MmglyVam/ZS nL734nhm6fIsFgRWwQ9YTWsFeIYZ37uds27jrt4I3nbcnPdkfCMtchQJ5qggOjnPRizf MdE6jr9gafhsYzZtXSjVpzOP1ovklwrv8WJ/Q= MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr223730vdb.116.1305743542017; Wed, 18 May 2011 11:32:22 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 11:32:21 -0700 (PDT) In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B6C5FD28@GVW1096EXB.americas.hpqcorp.net> References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> <4168915E16BA9E47972F4A4B4EE3228276B6C5FD28@GVW1096EXB.americas.hpqcorp.net> Date: Wed, 18 May 2011 14:32:21 -0400 Message-ID: From: Stephen Botzko To: "Gorzynski, Mark E (The Right One)" Content-Type: multipart/alternative; boundary=20cf307cfdd4fd5f9604a3911b09 Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 18:32:24 -0000 --20cf307cfdd4fd5f9604a3911b09 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am wondering if the correct way to think about this is that the spatial relationships identify the proper rendering. That is, the left stream is intended to appear to the immediate left of the center stream. That would b= e similar to your suggestion (though the "display" word isn't explicit). Alternatively, we could use the "stage left" theatrical convention (treatin= g the displays as the stage). That defines the streams from the perspective of the sender. The left stream appears on the audience's right, but is sourced from the left side of the sending system. That has the benefit of being a well established term. The educational use case (which is one where the professor and the class ar= e facing each other in the same room) is essentially un-ordered as written. Though it could be made partially ordered, by having multiple video streams cover the local classroom and also substituting a panel discussion for the professor. Stephen Botzko. On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) < mark.gorzynski@hp.com> wrote: > Regarding complex environments where users are seated in multiple > directions or in the round, can we consider the convention direction as > relative to facing a media system like a display? Is there at least a > clock-wise sense to media acquisition and reproduction where there as a > counter-clockwise most element and that is first (left most)? This is st= ill > pushing the concept of a single-dimension to order. > > > > From a stream generation point of view, there may indeed be media streams > with no logical order / spatial relation relative to other streams genera= ted > by the same endpoint. Can we support both ordered / spatially related an= d > unordered un-spatially related streams from end points? Do we need a > higher dimensional (greater than 1 dimension) means of specifying order? > > > > Mark Gorzynski > > > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, May 18, 2011 9:07 AM > *To:* Gorzynski, Mark E (The Right One) > > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > I note we have at least one use case where users in the same room are > facing in different directions. > > Stephen Botzko > > On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) < > mark.gorzynski@hp.com> wrote: > > =B7 Agree with the point (Botzko) that =93spatial relations=94 sho= uld > refer to streams not devices. > > > > =B7 Also agree with the point (stated in several places) that > left-right should be clear and be defined with respect to a user facing t= he > displays. This will of course require being careful about maintaining th= is > convention when a stream is received. At a sender, a stream may be thus > defined as from the right-most display. But when it is received and > rendered on a display, that final destination will use the receiver=92s p= oint > of view. Thus a stream at Sender A may be labeled A-Right and then sent = to > receiver B for output to display B-Left. I would not re-label the stream > from A to match the receiver convention. Thus streams might be labeled w= ith > respect to the sender convention. > > > > =B7 We also should be careful when considering spatial relationshi= ps > to not make the system specific to odd or even numbers of streams in a > spatial relationship. Using left-right or > -2,-1,0,1,2 or such things may assume a centered system where one stream = is > on a center axis or that there is a clear sense of when =93right=94 begin= s. > This is not always true. For example a system with an even number of > displays and a camera above each display. Thus it may be most efficient = to > use the sense of =93left=94 to create a beginning of a spatial relationsh= ip and > order streams from that beginning, 0,1,2,=85 Thus we may label a stream = from > the right-most display of a sender A as coming from A.2 If that stream i= s > sent to a receiver for output on a left most display, that left most disp= lay > destination may be B.0. > > > > Regards > > Mark Gorzynski > > > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephen Botzko > *Sent:* Wednesday, May 18, 2011 8:17 AM > *To:* Stephan Wenger > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > In-line - > Stephen Botzko > > On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: > > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there ma= y > be need for more explanatory text. > Stephan > > > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: > > >Hi Stephan, > > > >This is a great start. I do not know if you volunteered to update as > >well as provide the initial version of this document. In any case, here > >are some comments. > > > >> Endpoint - The logical point of final termination through > >> receiving, decoding and rendering, and/or initiation through > >> capturing, encoding, and sending of media streams. An endpoint > >> consists of one or more physical devices which source and sink > >> media streams. In contrast to an endpoint, a middle box, such > >> as an MCU, may also send and receive media streams, but it is > >> not the initiator nor the final terminator. > > > >I am not sure we should differentiate between endpoint and MCU. The > >distinction blurs in that an MCU generates and send media streams that > >are not necessarily equivalent to those it received, and it receives > >input from other endpoints. I think trying to distinguish them simply > >makes more work and add complexity. I also think we will find that the > >majority of "MCUs" are really more "endpoints" than "MCUs". > >You introduced the concept of remote. I am proposing remote =3D=3D endpo= int > >and remove MCU. > > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. > > > > > >> Media - Any data that, after suitable encoding, can be conveyed > >> over RTP, including audio, video or timed text. > > > >I think this is too general, but I am not able to suggest a good way to > >improve it. > > Again, not sure why this is too general. > > > > > >> Session - RTP session. An association among a set of > >> participants communicating with RTP. The distinguishing feature > >> of an RTP session is that each maintains a full, separate space > >> of SSRC identifiers. [RFC3550] > > > >In this case, do we also need a term for the collection of RTP sessions > >the contains the complete set media exchanged between two endpoints? > > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. > > > > > > > >"Layouts" vs. "Spatial Relations", what is the difference? > > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. > > > > Although these are all examples of spatial relations, I think we need to = be > very careful to distinguish microphones and audio channels (and cameras > /video channels). Lots of audio systems use microphone arrays and beam > forming to get pickup in various parts of the room, and in principle you > could use similar techniques for video. > > So in practice, I think it is essential that we describe relationships of > streams, and not capture/render devices. > > Also, do we mean the "left camera" is physically located on the left, or > that it shows participants on the left? I think the latter is the intent= , > and that it needs to be clear. Another reason perhaps to avoid talking > about camera placement. > > > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >Of Stephan Wenger > >> Sent: Friday, May 13, 2011 11:08 AM > >> To: CLUE > >> Subject: [clue] Definitions > >> > >> Hi folks, > >> Here a VERY rough initial draft. Addressing typos, sorting to > >alphabetical, and other cleanup tasks > >> will have to wait for the my return to the office next week. I will > >submit officially only after the > >> most embarrassing bugs are sorted out. No need to comment on typos, > >but if you have substantial > >> issues then send them now, and I can address them immediately. > >> Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307cfdd4fd5f9604a3911b09 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am wondering if the correct way to think about this is that the spatial r= elationships identify the proper rendering.=A0 That is, the left stream is = intended to appear to the immediate left of the center stream. That would b= e similar to your suggestion (though the "display" word isn't= explicit).=A0=A0

Alternatively, we could use the "stage left" theatrical conve= ntion (treating the displays as the stage).=A0 That defines the streams fro= m the perspective of the sender. The left stream appears on the audience= 9;s right, but is sourced from the left side of the sending system.=A0 That= has the benefit of being a well established term.

The educational use case (which is one where the professor and the clas= s are facing each other in the same room) is essentially un-ordered as writ= ten.=A0 Though it could be made partially ordered, by having multiple video= streams cover the local classroom and also substituting a panel discussion= for the professor.

Stephen Botzko.

On Wed, May 18, 2011 = at 2:10 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrot= e:

Regarding complex environments where users are seated in multiple d= irections or in the round, can we consider the convention direction as rela= tive to facing a media system like a display?=A0 Is there at least a clock-= wise sense to media acquisition and reproduction where there as a counter-c= lockwise most element and that is first (left most)?=A0 This is still pushi= ng the concept of a single-dimension to order.

=A0

From a stream generation point of view, there may indeed be media strea= ms with no logical order / spatial relation relative to other streams gener= ated by the same endpoint.=A0 Can we support both ordered / spatially relat= ed and unordered =A0un-spatially related streams from end points?=A0 Do we = need a higher dimensional (greater than 1 dimension) means of specifying or= der?

=A0

Mark Gorzynski

=A0

From:= Stephen Botzko [mailto:stephen.botzko@gmail.com] <= br>Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)


Cc: CLUE
Subject: Re: [clue] Definitions=

=A0

I note we have at lea= st one use case where users in the same room are facing in different direct= ions.

Stephen Botzko

On Wed, May 18, = 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote= :

=B7=A0=A0=A0=A0=A0= =A0=A0 Agree with the= point (Botzko) that =93spatial relations=94 should refer to streams not de= vices.=A0

=A0

=B7=A0=A0=A0=A0=A0= =A0=A0 Also agree wit= h the point (stated in several places) that left-right should be clear and = be defined with respect to a user facing the displays.=A0 This will of cour= se require being careful about maintaining this convention when a stream is= received.=A0 At a sender, a stream may be thus defined as from the right-m= ost display.=A0 But when it is received and rendered on a display, that fin= al destination will use the receiver=92s point of view.=A0 Thus a stream at= Sender A may be labeled A-Right and then sent to receiver B for output to = display B-Left.=A0 I would not re-label the stream from A to match the rece= iver convention.=A0 Thus streams might be labeled with respect to the sende= r convention.

=A0

=B7=A0=A0=A0=A0=A0=A0=A0 We also should be careful when cons= idering spatial relationships to not make the system specific to odd or eve= n numbers of streams in a spatial relationship.=A0 Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when =93right=94 begins= .=A0 This is not always true.=A0 For example a system with an even number o= f displays and a camera above each display.=A0 Thus it may be most efficien= t to use the sense of =93left=94 to create a beginning of a spatial relatio= nship and order streams from that beginning, 0,1,2,=85=A0 Thus we may label= a stream from the right-most display of a sender A as coming from A.2=A0 I= f that stream is sent to a receiver for output on a left most display, that= left most display destination may be B.0.

=A0

Regards

Mar= k Gorzynski

=A0

=A0

=A0

=A0

From: clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzk= o
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan WengerCc: CLUE
Subject: Re: [clue] Definitions

=A0

In-line -
Stephen Botzko

On Tu= e, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced ther= e is need for a change, though there may
be need for more explanatory te= xt.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrot= e:

>Hi Stephan,
>
>This is a great start. I do not kn= ow if you volunteered to update as
>well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point= of final termination through
>> receiving, decoding and rendering= , and/or initiation through
>> capturing, encoding, and sending of media streams. =A0An endpoint<= br>>> consists of one or more physical devices which source and sink<= br>>> media streams. =A0In contrast to an endpoint, a middle box, suc= h
>> as an MCU, may also send and receive media streams, but it is
&= gt;> not the initiator nor the final terminator.
>
>I am not= sure we should differentiate between endpoint and MCU. The
>distinct= ion blurs in that an MCU generates and send media streams that
>are not necessarily equivalent to those it received, and it receives>input from other endpoints. I think trying to distinguish them simply<= br>>makes more work and add complexity. I also think we will find that t= he
>majority of "MCUs" are really more "endpoints" than= "MCUs".
>You introduced the concept of remote. I am propos= ing remote =3D=3D endpoint
>and remove MCU.

Not sure here.
What "endpoint" attempts to express is that it = is the logical entity
facing the user--the room including microphones lo= udspeakers, screens,
cameras, and some technical stuff that sends and re= ceives RTP streams and
implements signaling. =A0We need such a definition certainly in the
requ= irement spec but also in the use cases. =A0There is also a "local"= ;
endpoint, which prohibits the use of "remote".
I think we= should leave this definition alone.


>
>= > Media - Any data that, after suitable encoding, can be conveyed
>= ;> over RTP, including audio, video or timed text.
>
>I thin= k this is too general, but I am not able to suggest a good way to
>improve it.

Again, not sure why this is= too general.


>
>> Session - RTP session. =A0An association among a set = of
>> participants communicating with RTP. =A0The distinguishing feature=
>> of an RTP session is that each maintains a full, separate spac= e
>> of SSRC identifiers. =A0[RFC3550]
>
>In this case= , do we also need a term for the collection of RTP sessions
>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have see= n that need yet.
Pm the media plane, there is really no such thing as &q= uot;bundling" of media
transmission channels. =A0There is a logical connection between multiplesessions, but only in the signaling.


>
>
>"Layouts" vs. &= quot;Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial rel= ations of all
capture/renderer devices at a given point in time?
&quo= t;Left speaker is left from right speaker" is a spatial relation.
"Left microphone is co-located with left camera" is a spatial rel= ation.
"Audio channel 1 is left, audio channel 2 is right, and ther= e is only one
center camera" is a layout.

=A0

Although these are all examp= les of spatial relations, I think we need to be very careful to distinguish= microphones and audio channels (and cameras /video channels).=A0 Lots of a= udio systems use microphone arrays and beam forming to get pickup in variou= s parts of the room, and in principle you could use similar techniques for = video.

So in practice, I think it is essential that we describe relationships = of streams, and not capture/render devices.

Also, do we mean the &qu= ot;left camera" is physically located on the left, or that it shows pa= rticipants on the left?=A0 I think the latter is the intent, and that it ne= eds to be clear.=A0 Another reason perhaps to avoid talking about camera pl= acement.
=A0

>
>Che= ers,
>Charles
>
>
>> -----Original Message-----
>&= gt; From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
&g= t;> To: CLUE
>> Subject: [clue] Definitions
>>
>= > Hi folks,
>> Here a VERY rough initial draft. =A0Addressing t= ypos, sorting to
>alphabetical, and other cleanup tasks
>> will have to wait for= the my return to the office next week. =A0I will
>submit officially = only after the
>> most embarrassing bugs are sorted out. =A0No nee= d to comment on typos,
>but if you have substantial
>> issues then send them now, and = I can address them immediately.
>> Stephan
>


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

=A0


_______________________________________________
clue mailing listclue@ietf.org
http= s://www.ietf.org/mailman/listinfo/clue

=A0


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


--20cf307cfdd4fd5f9604a3911b09-- From stewe@stewe.org Wed May 18 12:20:12 2011 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 6EE3AE06C3 for ; Wed, 18 May 2011 12:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Y1ZTrQNCFOZM for ; Wed, 18 May 2011 12:20:07 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0CE06B1 for ; Wed, 18 May 2011 12:20:05 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2460-1743317 for multiple; Wed, 18 May 2011 21:20:03 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 18 May 2011 12:19:54 +0200 From: Stephan Wenger To: Stephen Botzko , "Gorzynski, Mark E (The Right One)" Message-ID: Thread-Topic: [clue] Definitions In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388566002_11000118" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 19:20:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388566002_11000118 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Of these alternatives, I'm in favor of "stage left". I don't like a protocol expressing something (like a "to be rendered left" property) over which the protocol has no control. Let me also forget to ignore the edu use case for now. We are talking abou= t definitions to be used throughout a set of documents. If one of the definitions happens to be inapplicable, the spec can always phrase around. Stephan From: Stephen Botzko Date: Wed, 18 May 2011 14:32:21 -0400 To: "Gorzynski, Mark E (The Right One)" Cc: CLUE Subject: Re: [clue] Definitions I am wondering if the correct way to think about this is that the spatial relationships identify the proper rendering. That is, the left stream is intended to appear to the immediate left of the center stream. That would b= e similar to your suggestion (though the "display" word isn't explicit). Alternatively, we could use the "stage left" theatrical convention (treatin= g the displays as the stage). That defines the streams from the perspective of the sender. The left stream appears on the audience's right, but is sourced from the left side of the sending system. That has the benefit of being a well established term. The educational use case (which is one where the professor and the class ar= e facing each other in the same room) is essentially un-ordered as written. Though it could be made partially ordered, by having multiple video streams cover the local classroom and also substituting a panel discussion for the professor. Stephen Botzko. On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) wrote: > Regarding complex environments where users are seated in multiple directi= ons > or in the round, can we consider the convention direction as relative to > facing a media system like a display? Is there at least a clock-wise sen= se to > media acquisition and reproduction where there as a counter-clockwise mos= t > element and that is first (left most)? This is still pushing the concept= of a > single-dimension to order. > =20 > From a stream generation point of view, there may indeed be media streams= with > no logical order / spatial relation relative to other streams generated b= y the > same endpoint. Can we support both ordered / spatially related and unord= ered > un-spatially related streams from end points? Do we need a higher dimens= ional > (greater than 1 dimension) means of specifying order? > =20 > Mark Gorzynski > =20 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, May 18, 2011 9:07 AM > To: Gorzynski, Mark E (The Right One) >=20 >=20 > Cc: CLUE > Subject: Re: [clue] Definitions > =20 > I note we have at least one use case where users in the same room are fac= ing > in different directions. >=20 > Stephen Botzko >=20 > On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) > wrote: >=20 > =B7 Agree with the point (Botzko) that =B3spatial relations=B2 should re= fer > to streams not devices. >=20 > =20 > =B7 Also agree with the point (stated in several places) that left-r= ight > should be clear and be defined with respect to a user facing the displays= . > This will of course require being careful about maintaining this conventi= on > when a stream is received. At a sender, a stream may be thus defined as = from > the right-most display. But when it is received and rendered on a displa= y, > that final destination will use the receiver=B9s point of view. Thus a str= eam > at Sender A may be labeled A-Right and then sent to receiver B for output= to > display B-Left. I would not re-label the stream from A to match the rece= iver > convention. Thus streams might be labeled with respect to the sender > convention. >=20 > =20 >=20 > =B7 We also should be careful when considering spatial relationships= to > not make the system specific to odd or even numbers of streams in a spati= al > relationship. Using left-right or > -2,-1,0,1,2 or such things may assume a centered system where one stream = is on > a center axis or that there is a clear sense of when =B3right=B2 begins. Thi= s is > not always true. For example a system with an even number of displays an= d a > camera above each display. Thus it may be most efficient to use the sens= e of > =B3left=B2 to create a beginning of a spatial relationship and order streams = from > that beginning, 0,1,2,=8A Thus we may label a stream from the right-most > display of a sender A as coming from A.2 If that stream is sent to a rec= eiver > for output on a left most display, that left most display destination may= be > B.0. >=20 > =20 >=20 > Regards > Mark Gorzynski > =20 >=20 > =20 > =20 > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephen Botzko > Sent: Wednesday, May 18, 2011 8:17 AM > To: Stephan Wenger > Cc: CLUE > Subject: Re: [clue] Definitions > =20 > In-line -=20 > Stephen Botzko >=20 > On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there ma= y > be need for more explanatory text. > Stephan >=20 >=20 > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: >=20 >> >Hi Stephan, >> > >> >This is a great start. I do not know if you volunteered to update as >> >well as provide the initial version of this document. In any case, here >> >are some comments. >> > >>> >> Endpoint - The logical point of final termination through >>> >> receiving, decoding and rendering, and/or initiation through >>> >> capturing, encoding, and sending of media streams. An endpoint >>> >> consists of one or more physical devices which source and sink >>> >> media streams. In contrast to an endpoint, a middle box, such >>> >> as an MCU, may also send and receive media streams, but it is >>> >> not the initiator nor the final terminator. >> > >> >I am not sure we should differentiate between endpoint and MCU. The >> >distinction blurs in that an MCU generates and send media streams that >> >are not necessarily equivalent to those it received, and it receives >> >input from other endpoints. I think trying to distinguish them simply >> >makes more work and add complexity. I also think we will find that the >> >majority of "MCUs" are really more "endpoints" than "MCUs". >> >You introduced the concept of remote. I am proposing remote =3D=3D endpoint >> >and remove MCU. > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. >=20 >=20 >> > >>> >> Media - Any data that, after suitable encoding, can be conveyed >>> >> over RTP, including audio, video or timed text. >> > >> >I think this is too general, but I am not able to suggest a good way to >> >improve it. > Again, not sure why this is too general. >=20 >=20 >> > >>> >> Session - RTP session. An association among a set of >>> >> participants communicating with RTP. The distinguishing feature >>> >> of an RTP session is that each maintains a full, separate space >>> >> of SSRC identifiers. [RFC3550] >> > >> >In this case, do we also need a term for the collection of RTP sessions >> >the contains the complete set media exchanged between two endpoints? > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. >=20 >=20 >> > >> > >> >"Layouts" vs. "Spatial Relations", what is the difference? > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. >=20 > =20 >=20 > Although these are all examples of spatial relations, I think we need to = be > very careful to distinguish microphones and audio channels (and cameras /= video > channels). Lots of audio systems use microphone arrays and beam forming = to > get pickup in various parts of the room, and in principle you could use > similar techniques for video. >=20 > So in practice, I think it is essential that we describe relationships of > streams, and not capture/render devices. >=20 > Also, do we mean the "left camera" is physically located on the left, or = that > it shows participants on the left? I think the latter is the intent, and= that > it needs to be clear. Another reason perhaps to avoid talking about came= ra > placement. > =20 >>=20 >>> > >>> >Cheers, >>> >Charles >>> > >>> > >>>> >> -----Original Message----- >>>> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behal= f >>> >Of Stephan Wenger >>>> >> Sent: Friday, May 13, 2011 11:08 AM >>>> >> To: CLUE >>>> >> Subject: [clue] Definitions >>>> >> >>>> >> Hi folks, >>>> >> Here a VERY rough initial draft. Addressing typos, sorting to >>> >alphabetical, and other cleanup tasks >>>> >> will have to wait for the my return to the office next week. I wil= l >>> >submit officially only after the >>>> >> most embarrassing bugs are sorted out. No need to comment on typos= , >>> >but if you have substantial >>>> >> issues then send them now, and I can address them immediately. >>>> >> Stephan >>> > >>=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 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --B_3388566002_11000118 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Of these alternatives, I'm i= n favor of "stage left".  I don't like a protocol expressing something = (like a "to be rendered left" property) over which the protocol has no contr= ol.
Let me also forget to ignore the edu use case for now.  W= e are talking about definitions to be used throughout a set of documents. &n= bsp;If one of the definitions happens to be inapplicable, the spec can alway= s phrase around.
Stephan


<= br>
From: Stephen Botzko <stephen.botzko@gmail.com>
Date: Wed, 18 May 2011 14:32:21 -0400
= To: "Gorzynski, Mark E (The Right One= )" <mark.gorzynski@hp.com><= br>Cc: CLUE <clue@ietf.org>
Subject: <= /span> Re: [clue] Definitions

I am wondering if the = correct way to think about this is that the spatial relationships identify t= he proper rendering.  That is, the left stream is intended to appear to= the immediate left of the center stream. That would be similar to your sugg= estion (though the "display" word isn't explicit).  

Alter= natively, we could use the "stage left" theatrical convention (treating the = displays as the stage).  That defines the streams from the perspective = of the sender. The left stream appears on the audience's right, but is sourc= ed from the left side of the sending system.  That has the benefit of b= eing a well established term.

The educational use case (which is one = where the professor and the class are facing each other in the same room) is= essentially un-ordered as written.  Though it could be made partially = ordered, by having multiple video streams cover the local classroom and also= substituting a panel discussion for the professor.

Stephen Botzko.
On Wed, May 18, 2011 at 2:10 PM, Gorzynski, M= ark E (The Right One) <mark.gorzynski@hp.com> wrote:

Regarding complex environments wh= ere users are seated in multiple directions or in the round, can we consider= the convention direction as relative to facing a media system like a displa= y?  Is there at least a clock-wise sense to media acquisition and repro= duction where there as a counter-clockwise most element and that is first (l= eft most)?  This is still pushing the concept of a single-dimension to = order.

 

From a stream generation point of view, there may indeed be me= dia streams with no logical order / spatial relation relative to other strea= ms generated by the same endpoint.  Can we support both ordered / spati= ally related and unordered  un-spatially related streams from end point= s?  Do we need a higher dimensional (greater than 1 dimension) means of= specifying order?

 

Mark Gorzynski

 

From: Stephen Botzko [mail= to:stephen.botzko@= gmail.com]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)


Cc: CLUE
Subject: Re: [clue] Definitions
<= p>

 

I note we have at least one use c= ase where users in the same room are facing in different directions.

= Stephen Botzko

On Wed, May 18, 2011 at 12:00 PM= , Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:

=B7        Agree with the point (Botzko= ) that “spatial relations” should refer to streams not devices.&= nbsp;

 

=B7  &nbs= p;     Also agree with the point (stated in several places) that left-right shou= ld be clear and be defined with respect to a user facing the displays. = This will of course require being careful about maintaining this convention= when a stream is received.  At a sender, a stream may be thus defined = as from the right-most display.  But when it is received and rendered o= n a display, that final destination will use the receiver’s point of v= iew.  Thus a stream at Sender A may be labeled A-Right and then sent to= receiver B for output to display B-Left.  I would not re-label the str= eam from A to match the receiver convention.  Thus streams might be lab= eled with respect to the sender convention.

 

=B7        We also should be careful when considering spatial rel= ationships to not make the system specific to odd or even numbers of streams= in a spatial relationship.  Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when “right”= begins.  This is not always true.  For example a system with an e= ven number of displays and a camera above each display.  Thus it may be= most efficient to use the sense of “left” to create a beginning= of a spatial relationship and order streams from that beginning, 0,1,2,R= 30;  Thus we may label a stream from the right-most display of a sender= A as coming from A.2  If that stream is sent to a receiver for output = on a left most display, that left most display destination may be B.0.

 

Regards

Mark Gor= zynski

 

&nbs= p;

 

 =

From:<= /span> clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of= Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To= : Stephan Wenger
Cc: CLUE
Subject: Re: [clue] Defini= tions

 

In-line -
Stephen Botzko

On Tue,= May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced there is= need for a change, though there may
be need for more explanatory text.Stephan


On 5= .16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:

>Hi Stephan= ,
>
>This is a great start. I do not know if you volunteered to = update as
>well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point = of final termination through
>> receiving, decoding and rendering, = and/or initiation through
>> capturing, encoding, and sending of media streams.  An endpoi= nt
>> consists of one or more physical devices which source and sin= k
>> media streams.  In contrast to an endpoint, a middle box,= such
>> as an MCU, may also send and receive media streams, but it is
&= gt;> not the initiator nor the final terminator.
>
>I am not = sure we should differentiate between endpoint and MCU. The
>distinctio= n blurs in that an MCU generates and send media streams that
>are not necessarily equivalent to those it received, and it receives>input from other endpoints. I think trying to distinguish them simply>makes more work and add complexity. I also think we will find that the=
>majority of "MCUs" are really more "endpoints" than "MCUs".
>You = introduced the concept of remote. I am proposing remote =3D=3D endpoint
>a= nd remove MCU.

Not sure here.
What "endpoint" attempts to express is that it is the log= ical entity
facing the user--the room including microphones loudspeakers,= screens,
cameras, and some technical stuff that sends and receives RTP s= treams and
implements signaling.  We need such a definition certainly in the
r= equirement spec but also in the use cases.  There is also a "local"
= endpoint, which prohibits the use of "remote".
I think we should leave th= is definition alone.


>
>> Media - Any data that, after suitable encoding, can = be conveyed
>> over RTP, including audio, video or timed text.
&= gt;
>I think this is too general, but I am not able to suggest a good = way to
>improve it.

Again, not sure why this is t= oo general.


&g= t;
>> Session - RTP session.  An association among a set of >> participants communicating with RTP.  The distinguishing feat= ure
>> of an RTP session is that each maintains a full, separate sp= ace
>> of SSRC identifiers.  [RFC3550]
>
>In this = case, do we also need a term for the collection of RTP sessions
>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have seen that = need yet.
Pm the media plane, there is really no such thing as "bundling"= of media
transmission channels.  There is a logical connection between multiple=
sessions, but only in the signaling.


>
>
>"Layouts" vs. "Spatial Relati= ons", what is the difference?

A Layout is the = aggregation of all spatial relations of all
capture/renderer devices at a= given point in time?
"Left speaker is left from right speaker" is a spat= ial relation.
"Left microphone is co-located with left camera" is a spatial relation.
= "Audio channel 1 is left, audio channel 2 is right, and there is only onecenter camera" is a layout.

 

Although these are all exam= ples of spatial relations, I think we need to be very careful to distinguish= microphones and audio channels (and cameras /video channels).  Lots of= audio systems use microphone arrays and beam forming to get pickup in vario= us parts of the room, and in principle you could use similar techniques for = video.

So in practice, I think it is essential that we describe relat= ionships of streams, and not capture/render devices.

Also, do we mean= the "left camera" is physically located on the left, or that it shows parti= cipants on the left?  I think the latter is the intent, and that it nee= ds to be clear.  Another reason perhaps to avoid talking about camera p= lacement.
 

>
>Cheers= ,
>Charles
>
>
>> -----Original Message-----
>&= gt; From: clue-bounce= s@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
&g= t;> To: CLUE
>> Subject: [clue] Definitions
>>
>&= gt; Hi folks,
>> Here a VERY rough initial draft.  Addressing = typos, sorting to
>alphabetical, and other cleanup tasks
>> will have to wait for= the my return to the office next week.  I will
>submit officiall= y only after the
>> most embarrassing bugs are sorted out.  No= need to comment on typos,
>but if you have substantial
>> issues then send them now, and = I can address them immediately.
>> Stephan
>


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

 


_______________________________________________
clue mailin= g list
clue@ietf.orghttps= ://www.ietf.org/mailman/listinfo/clue

&nbs= p;


__________________________________________= _____
clue mailing list
clue@ietf.org
https://w= ww.ietf.org/mailman/listinfo/clue


_______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/m= ailman/listinfo/clue --B_3388566002_11000118-- From mark.gorzynski@hp.com Wed May 18 12:32:24 2011 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 29825E06D3 for ; Wed, 18 May 2011 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 i4gAMJaET5mL for ; Wed, 18 May 2011 12:32:17 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id EA05DE06B1 for ; Wed, 18 May 2011 12:32:16 -0700 (PDT) Received: from G9W0368.americas.hpqcorp.net (g9w0368.houston.hp.com [16.216.193.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 4C9311C9E5 for ; Wed, 18 May 2011 19:32:16 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G9W0368.americas.hpqcorp.net (16.216.193.47) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 19:30:49 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.241]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Wed, 18 May 2011 19:30:49 +0000 From: "Gorzynski, Mark E (The Right One)" To: CLUE Date: Wed, 18 May 2011 19:30:47 +0000 Thread-Topic: [clue] Definitions Thread-Index: AcwVkJz3ENfA5zAxRdiDaRz4H/u1fgAASFsg Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B6C5FDFC@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FDFCGVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions 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, 18 May 2011 19:32:24 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FDFCGVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with a preference for "stage left" creating a 0 start to an order. = Thus streams 0,1,2,... are sender oriented. It is evident to a receiver = then that the order must be retained from the new rendering perspective. Mark From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Wednesday, May 18, 2011 3:20 AM To: Stephen Botzko; Gorzynski, Mark E (The Right One) Cc: CLUE Subject: Re: [clue] Definitions Of these alternatives, I'm in favor of "stage left". I don't like a protoc= ol expressing something (like a "to be rendered left" property) over which = the protocol has no control. Let me also forget to ignore the edu use case for now. We are talking abou= t definitions to be used throughout a set of documents. If one of the defi= nitions happens to be inapplicable, the spec can always phrase around. Stephan From: Stephen Botzko > Date: Wed, 18 May 2011 14:32:21 -0400 To: "Gorzynski, Mark E (The Right One)" > Cc: CLUE > Subject: Re: [clue] Definitions I am wondering if the correct way to think about this is that the spatial r= elationships identify the proper rendering. That is, the left stream is in= tended to appear to the immediate left of the center stream. That would be = similar to your suggestion (though the "display" word isn't explicit). Alternatively, we could use the "stage left" theatrical convention (treatin= g the displays as the stage). That defines the streams from the perspectiv= e of the sender. The left stream appears on the audience's right, but is so= urced from the left side of the sending system. That has the benefit of be= ing a well established term. The educational use case (which is one where the professor and the class ar= e facing each other in the same room) is essentially un-ordered as written.= Though it could be made partially ordered, by having multiple video strea= ms cover the local classroom and also substituting a panel discussion for t= he professor. Stephen Botzko. On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) > wrote: Regarding complex environments where users are seated in multiple direction= s or in the round, can we consider the convention direction as relative to = facing a media system like a display? Is there at least a clock-wise sense= to media acquisition and reproduction where there as a counter-clockwise m= ost element and that is first (left most)? This is still pushing the conce= pt of a single-dimension to order. >From a stream generation point of view, there may indeed be media streams w= ith no logical order / spatial relation relative to other streams generated= by the same endpoint. Can we support both ordered / spatially related and= unordered un-spatially related streams from end points? Do we need a hig= her dimensional (greater than 1 dimension) means of specifying order? Mark Gorzynski From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 18, 2011 9:07 AM To: Gorzynski, Mark E (The Right One) Cc: CLUE Subject: Re: [clue] Definitions I note we have at least one use case where users in the same room are facin= g in different directions. Stephen Botzko On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) > wrote: * Agree with the point (Botzko) that "spatial relations" should refe= r to streams not devices. * Also agree with the point (stated in several places) that left-rig= ht should be clear and be defined with respect to a user facing the display= s. This will of course require being careful about maintaining this conven= tion when a stream is received. At a sender, a stream may be thus defined = as from the right-most display. But when it is received and rendered on a = display, that final destination will use the receiver's point of view. Thu= s a stream at Sender A may be labeled A-Right and then sent to receiver B f= or output to display B-Left. I would not re-label the stream from A to mat= ch the receiver convention. Thus streams might be labeled with respect to = the sender convention. * We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spati= al relationship. Using left-right or -2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when "right" begins. T= his is not always true. For example a system with an even number of displa= ys and a camera above each display. Thus it may be most efficient to use t= he sense of "left" to create a beginning of a spatial relationship and orde= r streams from that beginning, 0,1,2,... Thus we may label a stream from t= he right-most display of a sender A as coming from A.2 If that stream is s= ent to a receiver for output on a left most display, that left most display= destination may be B.0. Regards Mark Gorzynski From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, May 18, 2011 8:17 AM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] Definitions In-line - Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger > wrote: Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoin= t >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. Although these are all examples of spatial relations, I think we need to be= very careful to distinguish microphones and audio channels (and cameras /v= ideo channels). Lots of audio systems use microphone arrays and beam formi= ng to get pickup in various parts of the room, and in principle you could u= se similar techniques for video. So in practice, I think it is essential that we describe relationships of s= treams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or th= at it shows participants on the left? I think the latter is the intent, an= d that it needs to be clear. Another reason perhaps to avoid talking about= camera placement. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >> >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf= .org https://www.ietf.org/mailman/listinfo/clue --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FDFCGVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith a preference for “stage left” creating a 0 start to an orde= r.  Thus streams 0,1,2,… are sender oriented.   It is = evident to a receiver then that the order must be retained from the new ren= dering perspective.

 

Mark<= /p>

 

From: Stephan Wenger [ma= ilto:stewe@stewe.org]
Sent: Wednesday, May 18, 2011 3:20 AM
<= b>To: Stephen Botzko; Gorzynski, Mark E (The Right One)
Cc: C= LUE
Subject: Re: [clue] Definitions

 

Of these alternatives, I'm in favor of "stage left".  I do= n't like a protocol expressing something (like a "to be rendered left&= quot; property) over which the protocol has no control.

Let me also forget to ignore the edu= use case for now.  We are talking about definitions to be used throug= hout a set of documents.  If one of the definitions happens to be inap= plicable, the spec can always phrase around.

Stephan

 

 

<= o:p> 

From= : Stephen Botzko <stephen.botzko@gmail.com>
Date: Wed, 18 May 2011 14:= 32:21 -0400
To: "Gorzynski, Mark E (The Right One)" <= ;mark.gorzynski@hp.com>
= Cc: CLUE <clue@ietf.org><= br>Subject: Re: [clue] Definitions

<= p class=3DMsoNormal> 

I am wondering if the correct way = to think about this is that the spatial relationships identify the proper r= endering.  That is, the left stream is intended to appear to the immed= iate left of the center stream. That would be similar to your suggestion (t= hough the "display" word isn't explicit).  

Alt= ernatively, we could use the "stage left" theatrical convention (= treating the displays as the stage).  That defines the streams from th= e perspective of the sender. The left stream appears on the audience's righ= t, but is sourced from the left side of the sending system.  That has = the benefit of being a well established term.

The educational use ca= se (which is one where the professor and the class are facing each other in= the same room) is essentially un-ordered as written.  Though it could= be made partially ordered, by having multiple video streams cover the loca= l classroom and also substituting a panel discussion for the professor.
=
Stephen Botzko.

On = Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:=

Regarding complex environments where users are seated in multiple dir= ections or in the round, can we consider the convention direction as relati= ve to facing a media system like a display?  Is there at least a clock= -wise sense to media acquisition and reproduction where there as a counter-= clockwise most element and that is first (left most)?  This is still p= ushing the concept of a single-dimension to order.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>From a stream generati= on point of view, there may indeed be media streams with no logical order /= spatial relation relative to other streams generated by the same endpoint.=   Can we support both ordered / spatially related and unordered  = un-spatially related streams from end points?  Do we need a higher dim= ensional (greater than 1 dimension) means of specifying order?

 =

Mark Gorzy= nski

 

From: Stephen Botzko [mailto:stephen.botzko@gmail= .com]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Go= rzynski, Mark E (The Right One)


Cc: CLUE
= Subject: Re: [clue] Definitions

<= div>

 

I note we have at least one use case where users in th= e same room are facing in different directions.

Stephen Botzko<= /o:p>

On Wed, May 18, 201= 1 at 12:00 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:

·  &n= bsp;     Agree with the point (Botzko) th= at “spatial relations” should refer to streams not devices.&nbs= p;

 =

·      &nbs= p; Also agree with the point (stated in several places) that = left-right should be clear and be defined with respect to a user facing the= displays.  This will of course require being careful about maintainin= g this convention when a stream is received.  At a sender, a stream ma= y be thus defined as from the right-most display.  But when it is rece= ived and rendered on a display, that final destination will use the receive= r’s point of view.  Thus a stream at Sender A may be labeled A-R= ight and then sent to receiver B for output to display B-Left.  I woul= d not re-label the stream from A to match the receiver convention.  Th= us streams might be labeled with respect to the sender convention.

 

=

·        <= /span>We also should be careful when considering spatial relationshi= ps to not make the system specific to odd or even numbers of streams in a s= patial relationship.  Using left-right or
-2,-1,0,1,2 or such thin= gs may assume a centered system where one stream is on a center axis or tha= t there is a clear sense of when “right” begins.  This is = not always true.  For example a system with an even number of displays= and a camera above each display.  Thus it may be most efficient to us= e the sense of “left” to create a beginning of a spatial relati= onship and order streams from that beginning, 0,1,2,…  Thus we m= ay label a stream from the right-most display of a sender A as coming from = A.2  If that stream is sent to a receiver for output on a left most di= splay, that left most display destination may be B.0.

 

Regards

Mark Gorzynski

 

 

 

<= a name=3D"130044f4e939019a_13003d7c0b82f2ed__MailE"> <= /o:p>

From= : clue-bounces@ietf.org [mailto= :clue-bounces@ie= tf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, M= ay 18, 2011 8:17 AM
To: Stephan Wenger
Cc: CLUE
S= ubject: Re: [clue] Definitions<= /o:p>

 =

In-line -
Stephen Botzko

On Tue, May 17, 2= 011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

<= span style=3D'color:black'>Hi Charles,
Please see inline.
In summary,= I'm not convinced there is need for a change, though there may
be need = for more explanatory text.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)&qu= ot; <eckelcu@cisc= o.com> wrote:

>Hi Stephan,
>
>This is a great = start. I do not know if you volunteered to update as
>well as provide= the initial version of this document. In any case, here
>are some co= mments.
>
>> Endpoint - The logical point of final terminati= on through
>> receiving, decoding and rendering, and/or initiation= through
>> capturing, encoding, and sending of media streams. &nb= sp;An endpoint
>> consists of one or more physical devices which s= ource and sink
>> media streams.  In contrast to an endpoint,= a middle box, such
>> as an MCU, may also send and receive media = streams, but it is
>> not the initiator nor the final terminator.<= br>>
>I am not sure we should differentiate between endpoint and M= CU. The
>distinction blurs in that an MCU generates and send media st= reams that
>are not necessarily equivalent to those it received, and = it receives
>input from other endpoints. I think trying to distinguis= h them simply
>makes more work and add complexity. I also think we wi= ll find that the
>majority of "MCUs" are really more "= endpoints" than "MCUs".
>You introduced the concept of= remote. I am proposing remote =3D=3D endpoint
>and remove MCU.<= /o:p>

Not sure here.
= What "endpoint" attempts to express is that it is the logical ent= ity
facing the user--the room including microphones loudspeakers, screen= s,
cameras, and some technical stuff that sends and receives RTP streams= and
implements signaling.  We need such a definition certainly in = the
requirement spec but also in the use cases.  There is also a &q= uot;local"
endpoint, which prohibits the use of "remote".=
I think we should leave this definition alone.


>
>> Media - Any data that, = after suitable encoding, can be conveyed
>> over RTP, including au= dio, video or timed text.
>
>I think this is too general, but I= am not able to suggest a good way to
>improve it.<= /p>

Again, not sure why this is too= general.


>>> Session - RTP session.  An association among a set of
&g= t;> participants communicating with RTP.  The distinguishing featur= e
>> of an RTP session is that each maintains a full, separate spa= ce
>> of SSRC identifiers.  [RFC3550]
>
>In this = case, do we also need a term for the collection of RTP sessions
>the = contains the complete set media exchanged between two endpoints?=

Perhaps, though I don't= think we have seen that need yet.
Pm the media plane, there is really n= o such thing as "bundling" of media
transmission channels. &nb= sp;There is a logical connection between multiple
sessions, but only in = the signaling.


&= gt;
>
>"Layouts" vs. "Spatial Relations", w= hat is the difference?

A Layout is the aggregation of all spatial relations of all
ca= pture/renderer devices at a given point in time?
"Left speaker is l= eft from right speaker" is a spatial relation.
"Left microphon= e is co-located with left camera" is a spatial relation.
"Audi= o channel 1 is left, audio channel 2 is right, and there is only one
cen= ter camera" is a layout.

 

<= span style=3D'color:black'>Although these are all examples of spatial relat= ions, I think we need to be very careful to distinguish microphones and aud= io channels (and cameras /video channels).  Lots of audio systems use = microphone arrays and beam forming to get pickup in various parts of the ro= om, and in principle you could use similar techniques for video.

So = in practice, I think it is essential that we describe relationships of stre= ams, and not capture/render devices.

Also, do we mean the "left= camera" is physically located on the left, or that it shows participa= nts on the left?  I think the latter is the intent, and that it needs = to be clear.  Another reason perhaps to avoid talking about camera pla= cement.
 

>
>Cheers,
>Charles
>
= >
>> -----Original Message-----
>> From: clue-bounces@ietf.org [ma= ilto:clue-bounce= s@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday= , May 13, 2011 11:08 AM
>> To: CLUE
>> Subject: [clue] De= finitions
>>
>> Hi folks,
>> Here a VERY rough i= nitial draft.  Addressing typos, sorting to
>alphabetical, and o= ther cleanup tasks
>> will have to wait for the my return to the o= ffice next week.  I will
>submit officially only after the
&g= t;> most embarrassing bugs are sorted out.  No need to comment on t= ypos,
>but if you have substantial
>> issues then send them = now, and I can address them immediately.
>> Stephan
>

_______________________________________________
clue mailing listclue@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/clue" target=3D"_blank">htt= ps://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

<= /div>= --_000_4168915E16BA9E47972F4A4B4EE3228276B6C5FDFCGVW1096EXBame_-- From hmmr@cisco.com Wed May 18 12:42:53 2011 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 E4B3AE0748 for ; Wed, 18 May 2011 12:42:53 -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 X40joOaREOOj for ; Wed, 18 May 2011 12:42:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2FE0746 for ; Wed, 18 May 2011 12:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=7397; q=dns/txt; s=iport; t=1305747772; x=1306957372; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bR1MjwRNAiNHOX17Q1xZgBhGZUWCjA/+YD2cS/AvYlg=; b=Eqlp7K4UpsR7S7HiaO8wqKKiV/hc2uePGK14EyPtHtTpyvZTXllIchTc bmKv5DV0gBnc3dacIH3VWhhEFOtAWtjnCJzQyAWpw9C/m89KTDsOevHQR kULZ/lqkVXvUH7zxsc+BG3IiTwrfqseodL5DXE/TYvvfYvEfv2hys/N0C Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAACwg1E2tJV2Y/2dsb2JhbACXT45Nd4hwoASQH41kgw0BgwsEhlCNeYpb X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="318669407" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 18 May 2011 19:42:51 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4IJgpdN023037; Wed, 18 May 2011 19:42:51 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 14:42:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 14:42:49 -0500 Message-ID: In-Reply-To: <4DD3FD0E.8020503@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwVfqQ54akTr1BFQYe9CwgESLGmsgAE9SsA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 18 May 2011 19:42:50.0370 (UTC) FILETIME=[C56F8E20:01CC1593] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 19:42:54 -0000 Paul, Murphy's Law says that if it is possible to put something together the wrong way,=20 probability says it will go the wrong way sooner or later. LTC Murphy had a=20 young enlisted guy that always found that wrong way to do things. System-wise,=20 the black-swan events occur unless you do your best to design them out. Machines are often designed so that there is exactly one way to do it. We want flexibility in software, but sometimes too much is not so good. Hopefully, proper operation of the protocol won't look like an error. Mike -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Wednesday, May 18, 2011 1:09 PM To: Mike Hammer (hmmr) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] legacy support in requirements On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > Paul, > > I would agree that if the offer-answer model semantic is that here are > several options and any subset of options is acceptable. > > However, if there is any grouping involved such that you need to have a > video and audio feed integrated to make sense then watch out. > > For example, I wouldn't want to end up with the result of a man's video > paired with a woman's voice. That could be rather comical. Well, SDP defines that you should ignore what you don't understand and=20 operate on what is left. So someone constructing an SDP with grouping issues such as you define=20 ought to keep in mind that this could happen, and set things up so that=20 something reasonable happens. You can't expect the dumb legacy device to figure out much. For your example, the result may be far from ideal, but it still is=20 likely to be better than no call at all. And if not, there is always the option of hanging up. But better, presumably the offer could have been=20 constructed in a way that produced a better result. Thanks, Paul > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 17, 2011 7:45 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 6:05 PM, Roni Even wrote: >> Paul, >> I think we read it differently. >> If the answerer does not support the group attribute and the offer had > the >> fid semantics it may look to the answerer as an offer with multiple > m-lines >> of the same media tyoe. In this case an implementation might also > decide to >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > Acceptable), >> because it contains several "m" lines of the same media type. > > That is a slightly different story. > > Then the reason for rejection is not because it saw an attribute it > didn't understand - its because it didn't like something it *did* > understand. > >> This is very relevant to the multiple streams case and we should look > if we >> state this behavior or we will look at providing an approach that will > allow >> the answerer to choose one m-line that the offerer prefers even of it > does >> not understand CLUE. > > IMO (lets see if others differ), if a UA receives an offer with at least > > one m-line it is happy with, then it should not reject the call because > there are others that it does not "understand". > > Here "understand" means something different - presumably it does > understand the direct meaning of the additional m-line, it just doesn't > understand the *significance* or use of it. > > I see little difference to getting to audio m-lines and only wanting > one, and getting one audio and one video and only supporting audio. In > general you should not reject an audio/video call just because you only > support audio. > > I think it will behoove clue to strongly recommend that the m-lines in > an offer be arranged so the first ones are the ones it most wants used > if not all are. > > Thanks, > Paul > >> Roni >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, May 18, 2011 12:37 AM >>> To: Roni Even >>> Cc: 'Stephen Botzko'; clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>> Paul, >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example >>>> Roni >>> >>> OK, I looked. It is consistent with what I said. >>> Either a=3Dgroup: is understood, or not. If not, its ignored, and = not > put >>> in the answer. Same with a=3Dmid: >>> >>> If a=3Dgroup: *is* understood, but some parameter within it is not, > there >>> are explicit rules for what to do. >>> >>> AFAICT there are no examples in this document where failure to >>> understand an a-line in total (or even in part) results in rejecting >>> the >>> offer. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> To: Stephen Botzko >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>> >>>>>> When the offer includes parameters that the answerer > does >>> not >>>>>> understand >>>>>> there are two options, he can ignore the unknown >>> parameters >>>>> or >>>>>> reject >>>>>> the offer. >>>>>> Rejecting the offer in that case is not really kosher. >>>>>> You are required to ignore parameters you do not understand. >>>>>> >>>>>> If you reject something because you don't like the > parameters >>> it >>>>>> contains, then that is an implicit statement that you >>> understand >>>>>> those parameters well enough to decide to reject them. >>>>>> >>>>>> As far as I know, you are always free to reject offers, and it >>>>> doesn't >>>>>> really imply anything when you do that.. Whether it is wise is >>>>> perhaps >>>>>> a different question. >>>>>> Stephen Botzko >>>>> >>>>> Certainly you are always free to reject an offer. >>>>> In general I don't know for certain the reason why, and so if I > give >>>>> you >>>>> the benefit of the doubt I will assume you have a valid reason - >>>>> perhaps >>>>> just policy. >>>>> >>>>> But if the reason you reject the offer is based on your violating a >>>>> spec, then you are non-conforming, whether I can determine you are >>>>> non-conforming or not. Whether being non-conforming is just > un-wise, >>> or >>>>> something stronger, is a separate discussion. The IETF does not > levy >>>>> any >>>>> penalties for violating its specs. But sometimes the market does. >>> (And >>>>> sometimes not.) But we don't need to endorse non-conforming > behavior >>> in >>>>> our documents. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From stephen.botzko@gmail.com Wed May 18 12:56:21 2011 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 3E6B6E0755 for ; Wed, 18 May 2011 12:56:21 -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 k1ZcLaRKBXtX for ; Wed, 18 May 2011 12:56:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38C06E076D for ; Wed, 18 May 2011 12:56:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so1655794vxg.31 for ; Wed, 18 May 2011 12:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7cLHJVSCuOYPicUOgMDkfjBAtYDmm9tNiXBxVf2DnmU=; b=r30At3Eny6lpz1Ex8CUYq8eeQ4wOTNRhaCz+kUqapUwb3712YRRpDbMDX7BuMGESsG hpWwb19ejiLbU3TxVTyxOh8D+eyePO/hPtYsMvkAxheghJEs9x4mvA+CE1QOSokm2GCS bcugMdyB1qj+qBkS6mgYIaY/mHpdg0EdhSm/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tda1g5XlPnqH1wo+9KzLRCvf7X+CkkTkd9kIHOcWt0mSu3CfT0HdA8Q2wzAKO7XJv7 sTCtMpZoVTQk+jg7mZld7omxn/hJ3vapuRHGcgUVzTpy/EexONgRt6Pzuf4gfNIoluvG sEK1hJEMuUpfwzfUKa08p2tLLWpsTrxSAvBmk= MIME-Version: 1.0 Received: by 10.52.68.205 with SMTP id y13mr3251023vdt.76.1305748577207; Wed, 18 May 2011 12:56:17 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 12:56:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 15:56:17 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=20cf307f32301c46f804a392483c Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 19:56:21 -0000 --20cf307f32301c46f804a392483c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Works for me. Stephen Botzko On Wed, May 18, 2011 at 6:19 AM, Stephan Wenger wrote: > Of these alternatives, I'm in favor of "stage left". I don't like a > protocol expressing something (like a "to be rendered left" property) ove= r > which the protocol has no control. > Let me also forget to ignore the edu use case for now. We are talking > about definitions to be used throughout a set of documents. If one of th= e > definitions happens to be inapplicable, the spec can always phrase around= . > Stephan > > > > From: Stephen Botzko > Date: Wed, 18 May 2011 14:32:21 -0400 > > To: "Gorzynski, Mark E (The Right One)" > Cc: CLUE > Subject: Re: [clue] Definitions > > I am wondering if the correct way to think about this is that the spatial > relationships identify the proper rendering. That is, the left stream is > intended to appear to the immediate left of the center stream. That would= be > similar to your suggestion (though the "display" word isn't explicit). > > Alternatively, we could use the "stage left" theatrical convention > (treating the displays as the stage). That defines the streams from the > perspective of the sender. The left stream appears on the audience's righ= t, > but is sourced from the left side of the sending system. That has the > benefit of being a well established term. > > The educational use case (which is one where the professor and the class > are facing each other in the same room) is essentially un-ordered as > written. Though it could be made partially ordered, by having multiple > video streams cover the local classroom and also substituting a panel > discussion for the professor. > > Stephen Botzko. > > On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) < > mark.gorzynski@hp.com> wrote: > >> Regarding complex environments where users are seated in multiple >> directions or in the round, can we consider the convention direction as >> relative to facing a media system like a display? Is there at least a >> clock-wise sense to media acquisition and reproduction where there as a >> counter-clockwise most element and that is first (left most)? This is s= till >> pushing the concept of a single-dimension to order. >> >> >> >> From a stream generation point of view, there may indeed be media stream= s >> with no logical order / spatial relation relative to other streams gener= ated >> by the same endpoint. Can we support both ordered / spatially related a= nd >> unordered un-spatially related streams from end points? Do we need a >> higher dimensional (greater than 1 dimension) means of specifying order? >> >> >> >> Mark Gorzynski >> >> >> >> *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Wednesday, May 18, 2011 9:07 AM >> *To:* Gorzynski, Mark E (The Right One) >> >> *Cc:* CLUE >> *Subject:* Re: [clue] Definitions >> >> >> >> I note we have at least one use case where users in the same room are >> facing in different directions. >> >> Stephen Botzko >> >> On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) < >> mark.gorzynski@hp.com> wrote: >> >> =B7 Agree with the point (Botzko) that =93spatial relations=94 sh= ould >> refer to streams not devices. >> >> >> >> =B7 Also agree with the point (stated in several places) that >> left-right should be clear and be defined with respect to a user facing = the >> displays. This will of course require being careful about maintaining t= his >> convention when a stream is received. At a sender, a stream may be thus >> defined as from the right-most display. But when it is received and >> rendered on a display, that final destination will use the receiver=92s = point >> of view. Thus a stream at Sender A may be labeled A-Right and then sent= to >> receiver B for output to display B-Left. I would not re-label the strea= m >> from A to match the receiver convention. Thus streams might be labeled = with >> respect to the sender convention. >> >> >> >> =B7 We also should be careful when considering spatial relationsh= ips >> to not make the system specific to odd or even numbers of streams in a >> spatial relationship. Using left-right or >> -2,-1,0,1,2 or such things may assume a centered system where one stream >> is on a center axis or that there is a clear sense of when =93right=94 b= egins. >> This is not always true. For example a system with an even number of >> displays and a camera above each display. Thus it may be most efficient= to >> use the sense of =93left=94 to create a beginning of a spatial relations= hip and >> order streams from that beginning, 0,1,2,=85 Thus we may label a stream= from >> the right-most display of a sender A as coming from A.2 If that stream = is >> sent to a receiver for output on a left most display, that left most dis= play >> destination may be B.0. >> >> >> >> Regards >> >> Mark Gorzynski >> >> >> >> >> >> >> >> >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Stephen Botzko >> *Sent:* Wednesday, May 18, 2011 8:17 AM >> *To:* Stephan Wenger >> *Cc:* CLUE >> *Subject:* Re: [clue] Definitions >> >> >> >> In-line - >> Stephen Botzko >> >> On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote= : >> >> Hi Charles, >> Please see inline. >> In summary, I'm not convinced there is need for a change, though there m= ay >> be need for more explanatory text. >> Stephan >> >> >> On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote= : >> >> >Hi Stephan, >> > >> >This is a great start. I do not know if you volunteered to update as >> >well as provide the initial version of this document. In any case, here >> >are some comments. >> > >> >> Endpoint - The logical point of final termination through >> >> receiving, decoding and rendering, and/or initiation through >> >> capturing, encoding, and sending of media streams. An endpoint >> >> consists of one or more physical devices which source and sink >> >> media streams. In contrast to an endpoint, a middle box, such >> >> as an MCU, may also send and receive media streams, but it is >> >> not the initiator nor the final terminator. >> > >> >I am not sure we should differentiate between endpoint and MCU. The >> >distinction blurs in that an MCU generates and send media streams that >> >are not necessarily equivalent to those it received, and it receives >> >input from other endpoints. I think trying to distinguish them simply >> >makes more work and add complexity. I also think we will find that the >> >majority of "MCUs" are really more "endpoints" than "MCUs". >> >You introduced the concept of remote. I am proposing remote =3D=3D endp= oint >> >and remove MCU. >> >> Not sure here. >> What "endpoint" attempts to express is that it is the logical entity >> facing the user--the room including microphones loudspeakers, screens, >> cameras, and some technical stuff that sends and receives RTP streams an= d >> implements signaling. We need such a definition certainly in the >> requirement spec but also in the use cases. There is also a "local" >> endpoint, which prohibits the use of "remote". >> I think we should leave this definition alone. >> >> >> > >> >> Media - Any data that, after suitable encoding, can be conveyed >> >> over RTP, including audio, video or timed text. >> > >> >I think this is too general, but I am not able to suggest a good way to >> >improve it. >> >> Again, not sure why this is too general. >> >> >> > >> >> Session - RTP session. An association among a set of >> >> participants communicating with RTP. The distinguishing feature >> >> of an RTP session is that each maintains a full, separate space >> >> of SSRC identifiers. [RFC3550] >> > >> >In this case, do we also need a term for the collection of RTP sessions >> >the contains the complete set media exchanged between two endpoints? >> >> Perhaps, though I don't think we have seen that need yet. >> Pm the media plane, there is really no such thing as "bundling" of media >> transmission channels. There is a logical connection between multiple >> sessions, but only in the signaling. >> >> >> > >> > >> >"Layouts" vs. "Spatial Relations", what is the difference? >> >> A Layout is the aggregation of all spatial relations of all >> capture/renderer devices at a given point in time? >> "Left speaker is left from right speaker" is a spatial relation. >> "Left microphone is co-located with left camera" is a spatial relation. >> "Audio channel 1 is left, audio channel 2 is right, and there is only on= e >> center camera" is a layout. >> >> >> >> Although these are all examples of spatial relations, I think we need to >> be very careful to distinguish microphones and audio channels (and camer= as >> /video channels). Lots of audio systems use microphone arrays and beam >> forming to get pickup in various parts of the room, and in principle you >> could use similar techniques for video. >> >> So in practice, I think it is essential that we describe relationships o= f >> streams, and not capture/render devices. >> >> Also, do we mean the "left camera" is physically located on the left, or >> that it shows participants on the left? I think the latter is the inten= t, >> and that it needs to be clear. Another reason perhaps to avoid talking >> about camera placement. >> >> >> > >> >Cheers, >> >Charles >> > >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> >Of Stephan Wenger >> >> Sent: Friday, May 13, 2011 11:08 AM >> >> To: CLUE >> >> Subject: [clue] Definitions >> >> >> >> Hi folks, >> >> Here a VERY rough initial draft. Addressing typos, sorting to >> >alphabetical, and other cleanup tasks >> >> will have to wait for the my return to the office next week. I will >> >submit officially only after the >> >> most embarrassing bugs are sorted out. No need to comment on typos, >> >but if you have substantial >> >> issues then send them now, and I can address them immediately. >> >> Stephan >> > >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ clue mailing list > clue@ietf.org https://www.ietf.org/mailman/listinfo/clue > --20cf307f32301c46f804a392483c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Works for me.

Stephen Botzko

On We= d, May 18, 2011 at 6:19 AM, Stephan Wenger <stewe@stewe.org> wrote:
Of these alternatives, I'm in favor of = "stage left". =A0I don't like a protocol expressing something= (like a "to be rendered left" property) over which the protocol = has no control.
Let me also forget to ignore the edu use case for now. =A0We are talki= ng about definitions to be used throughout a set of documents. =A0If one of= the definitions happens to be inapplicable, the spec can always phrase aro= und.
Stephan



From: Stephen Bo= tzko <step= hen.botzko@gmail.com>
Date= : Wed, 18 May 2011 14:32:21 -0400

To: "Gorzynski, Mark E (T= he Right One)" <mark.gorzynski@hp.com>
C= c: CLUE <clue= @ietf.org>
Subject: Re: [clue] Definiti= ons

I am wonderin= g if the correct way to think about this is that the spatial relationships = identify the proper rendering.=A0 That is, the left stream is intended to a= ppear to the immediate left of the center stream. That would be similar to = your suggestion (though the "display" word isn't explicit).= =A0=A0

Alternatively, we could use the "stage left" theatrical conve= ntion (treating the displays as the stage).=A0 That defines the streams fro= m the perspective of the sender. The left stream appears on the audience= 9;s right, but is sourced from the left side of the sending system.=A0 That= has the benefit of being a well established term.

The educational use case (which is one where the professor and the clas= s are facing each other in the same room) is essentially un-ordered as writ= ten.=A0 Though it could be made partially ordered, by having multiple video= streams cover the local classroom and also substituting a panel discussion= for the professor.

Stephen Botzko.

On Wed, May 18, 2011 = at 2:10 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:

Regarding complex environments where users are seated in multiple di= rections or in the round, can we consider the convention direction as relat= ive to facing a media system like a display?=A0 Is there at least a clock-w= ise sense to media acquisition and reproduction where there as a counter-cl= ockwise most element and that is first (left most)?=A0 This is still pushin= g the concept of a single-dimension to order.

=A0

From a stream generation point of view, there may indeed be media strea= ms with no logical order / spatial relation relative to other streams gener= ated by the same endpoint.=A0 Can we support both ordered / spatially relat= ed and unordered =A0un-spatially related streams from end points?=A0 Do we = need a higher dimensional (greater than 1 dimension) means of specifying or= der?

=A0

Mark Gorzynski

=A0

From:= Stephen Botzko [mailto:stephen.botzko@gmail.com] <= br>Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)


Cc: CLUE
Subject: Re: [clue] Definitions
<= p>

=A0

I note we have at least one use case where users in the same room are facin= g in different directions.

Stephen Botzko

On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) &l= t;mark.gorzynski= @hp.com> wrote:

=B7=A0=A0=A0=A0=A0=A0=A0 Agree with the point (Botz= ko) that =93spatial relations=94 should refer to streams not devices.=A0

=A0

=B7=A0=A0=A0=A0=A0=A0=A0 Also agree with the point (= stated in several places) that left-right should be clear and be defined wi= th respect to a user facing the displays.=A0 This will of course require be= ing careful about maintaining this convention when a stream is received.=A0= At a sender, a stream may be thus defined as from the right-most display.= =A0 But when it is received and rendered on a display, that final destinati= on will use the receiver=92s point of view.=A0 Thus a stream at Sender A ma= y be labeled A-Right and then sent to receiver B for output to display B-Le= ft.=A0 I would not re-label the stream from A to match the receiver convent= ion.=A0 Thus streams might be labeled with respect to the sender convention= .

=A0

=B7=A0=A0=A0=A0=A0=A0=A0 We also should be careful when considering spat= ial relationships to not make the system specific to odd or even numbers of= streams in a spatial relationship.=A0 Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when =93right=94 begins= .=A0 This is not always true.=A0 For example a system with an even number o= f displays and a camera above each display.=A0 Thus it may be most efficien= t to use the sense of =93left=94 to create a beginning of a spatial relatio= nship and order streams from that beginning, 0,1,2,=85=A0 Thus we may label= a stream from the right-most display of a sender A as coming from A.2=A0 I= f that stream is sent to a receiver for output on a left most display, that= left most display destination may be B.0.

=A0

Regards

Mar= k Gorzynski

=A0

=A0

=A0

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan WengerCc: CLUE
Subject: Re: [clue] Definitions

=A0

In-line -
Stephen Botzko

On Tu= e, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced ther= e is need for a change, though there may
be need for more explanatory te= xt.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrot= e:

>Hi Stephan,
>
>This is a great start. I do not kn= ow if you volunteered to update as
>well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point= of final termination through
>> receiving, decoding and rendering= , and/or initiation through
>> capturing, encoding, and sending of media streams. =A0An endpoint<= br>>> consists of one or more physical devices which source and sink<= br>>> media streams. =A0In contrast to an endpoint, a middle box, suc= h
>> as an MCU, may also send and receive media streams, but it is
&= gt;> not the initiator nor the final terminator.
>
>I am not= sure we should differentiate between endpoint and MCU. The
>distinct= ion blurs in that an MCU generates and send media streams that
>are not necessarily equivalent to those it received, and it receives>input from other endpoints. I think trying to distinguish them simply<= br>>makes more work and add complexity. I also think we will find that t= he
>majority of "MCUs" are really more "endpoints" than= "MCUs".
>You introduced the concept of remote. I am propos= ing remote =3D=3D endpoint
>and remove MCU.

Not sure here.
What "endpoint" attempts to express is that it = is the logical entity
facing the user--the room including microphones lo= udspeakers, screens,
cameras, and some technical stuff that sends and re= ceives RTP streams and
implements signaling. =A0We need such a definition certainly in the
requ= irement spec but also in the use cases. =A0There is also a "local"= ;
endpoint, which prohibits the use of "remote".
I think we= should leave this definition alone.


>
>= > Media - Any data that, after suitable encoding, can be conveyed
>= ;> over RTP, including audio, video or timed text.
>
>I thin= k this is too general, but I am not able to suggest a good way to
>improve it.

Again, not sure why this is= too general.


>
>> Session - RTP session. =A0An association among a set = of
>> participants communicating with RTP. =A0The distinguishing feature=
>> of an RTP session is that each maintains a full, separate spac= e
>> of SSRC identifiers. =A0[RFC3550]
>
>In this case= , do we also need a term for the collection of RTP sessions
>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have see= n that need yet.
Pm the media plane, there is really no such thing as &q= uot;bundling" of media
transmission channels. =A0There is a logical connection between multiplesessions, but only in the signaling.


>
>
>"Layouts" vs. &= quot;Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial rel= ations of all
capture/renderer devices at a given point in time?
&quo= t;Left speaker is left from right speaker" is a spatial relation.
"Left microphone is co-located with left camera" is a spatial rel= ation.
"Audio channel 1 is left, audio channel 2 is right, and ther= e is only one
center camera" is a layout.

=A0

Although these are all examp= les of spatial relations, I think we need to be very careful to distinguish= microphones and audio channels (and cameras /video channels).=A0 Lots of a= udio systems use microphone arrays and beam forming to get pickup in variou= s parts of the room, and in principle you could use similar techniques for = video.

So in practice, I think it is essential that we describe relationships = of streams, and not capture/render devices.

Also, do we mean the &qu= ot;left camera" is physically located on the left, or that it shows pa= rticipants on the left?=A0 I think the latter is the intent, and that it ne= eds to be clear.=A0 Another reason perhaps to avoid talking about camera pl= acement.
=A0

>
>Che= ers,
>Charles
>
>
>> -----Original Message-----
>&= gt; From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
&g= t;> To: CLUE
>> Subject: [clue] Definitions
>>
>= > Hi folks,
>> Here a VERY rough initial draft. =A0Addressing t= ypos, sorting to
>alphabetical, and other cleanup tasks
>> will have to wait for= the my return to the office next week. =A0I will
>submit officially = only after the
>> most embarrassing bugs are sorted out. =A0No nee= d to comment on typos,
>but if you have substantial
>> issues then send them now, and = I can address them immediately.
>> Stephan
>


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

=A0


_______________________________________________
clue mailing listclue@ietf.org
http= s://www.ietf.org/mailman/listinfo/clue

=A0


___________= ____________________________________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue


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

--20cf307f32301c46f804a392483c-- From espeberg@cisco.com Wed May 18 13:10:34 2011 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 76595E076D for ; Wed, 18 May 2011 13:10:34 -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 Obb4AtWJ5DP6 for ; Wed, 18 May 2011 13:10:33 -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 E4259E0748 for ; Wed, 18 May 2011 13:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=8179; q=dns/txt; s=iport; t=1305749432; x=1306959032; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lFZn7fvcSMkp5WXayRH2kY/Cp1SERKE4TEidH4sB2vQ=; b=UgBieConywAgtQCfOCRFMLB0HOka4PM5kjqSG+8GrSpl5CECgwDKpjld 7wLgETZ48E1mSQ45epJXYistgV+4AS4TSiRKHrDNWrs+4hLPEyViEBzw9 dreEAoBpFFxAQQ6WS5qthnxOQpsACvSpyXLJ7aNzEOxM6vhIIuFrLzUcW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAG0n1E2Q/khRgWdsb2JhbACXT45NFAEBFiYliHCfdpAfjWGDDQGDCwSUSYo/ X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="30963501" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 18 May 2011 20:10:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4IKAVJn016850 for ; Wed, 18 May 2011 20:10:31 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 22:10:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 22:10:30 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E645744@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwVfqQ54akTr1BFQYe9CwgESLGmsgAE9SsAAABmDkA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><4DD3FD0E.8020503@cisco.com> From: "Espen Berger (espeberg)" To: "Mike Hammer (hmmr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 18 May 2011 20:10:31.0543 (UTC) FILETIME=[A3927070:01CC1597] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 18 May 2011 20:10:34 -0000 I think there should be a requirement stating that a clue endpoint must send an initial SDP offer that can be understood by a existing SIP native endpoint. If not we will limit the endpoints a CLUE endpoint can call.=20 That should include a basic user experience for the legacy endpoint, for instance the default audio and video stream from the CLUE endpoint.=20 Regards=20 -Espen=20 =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mike Hammer (hmmr) Sent: 18. mai 2011 21:43 To: Paul Kyzivat (pkyzivat) Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements Paul, Murphy's Law says that if it is possible to put something together the wrong way,=20 probability says it will go the wrong way sooner or later. LTC Murphy had a=20 young enlisted guy that always found that wrong way to do things. System-wise,=20 the black-swan events occur unless you do your best to design them out. Machines are often designed so that there is exactly one way to do it. We want flexibility in software, but sometimes too much is not so good. Hopefully, proper operation of the protocol won't look like an error. Mike -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Wednesday, May 18, 2011 1:09 PM To: Mike Hammer (hmmr) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] legacy support in requirements On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > Paul, > > I would agree that if the offer-answer model semantic is that here are > several options and any subset of options is acceptable. > > However, if there is any grouping involved such that you need to have a > video and audio feed integrated to make sense then watch out. > > For example, I wouldn't want to end up with the result of a man's video > paired with a woman's voice. That could be rather comical. Well, SDP defines that you should ignore what you don't understand and=20 operate on what is left. So someone constructing an SDP with grouping issues such as you define=20 ought to keep in mind that this could happen, and set things up so that=20 something reasonable happens. You can't expect the dumb legacy device to figure out much. For your example, the result may be far from ideal, but it still is=20 likely to be better than no call at all. And if not, there is always the option of hanging up. But better, presumably the offer could have been=20 constructed in a way that produced a better result. Thanks, Paul > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 17, 2011 7:45 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/17/2011 6:05 PM, Roni Even wrote: >> Paul, >> I think we read it differently. >> If the answerer does not support the group attribute and the offer had > the >> fid semantics it may look to the answerer as an offer with multiple > m-lines >> of the same media tyoe. In this case an implementation might also > decide to >> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > Acceptable), >> because it contains several "m" lines of the same media type. > > That is a slightly different story. > > Then the reason for rejection is not because it saw an attribute it > didn't understand - its because it didn't like something it *did* > understand. > >> This is very relevant to the multiple streams case and we should look > if we >> state this behavior or we will look at providing an approach that will > allow >> the answerer to choose one m-line that the offerer prefers even of it > does >> not understand CLUE. > > IMO (lets see if others differ), if a UA receives an offer with at least > > one m-line it is happy with, then it should not reject the call because > there are others that it does not "understand". > > Here "understand" means something different - presumably it does > understand the direct meaning of the additional m-line, it just doesn't > understand the *significance* or use of it. > > I see little difference to getting to audio m-lines and only wanting > one, and getting one audio and one video and only supporting audio. In > general you should not reject an audio/video call just because you only > support audio. > > I think it will behoove clue to strongly recommend that the m-lines in > an offer be arranged so the first ones are the ones it most wants used > if not all are. > > Thanks, > Paul > >> Roni >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, May 18, 2011 12:37 AM >>> To: Roni Even >>> Cc: 'Stephen Botzko'; clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>> Paul, >>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example >>>> Roni >>> >>> OK, I looked. It is consistent with what I said. >>> Either a=3Dgroup: is understood, or not. If not, its ignored, and = not > put >>> in the answer. Same with a=3Dmid: >>> >>> If a=3Dgroup: *is* understood, but some parameter within it is not, > there >>> are explicit rules for what to do. >>> >>> AFAICT there are no examples in this document where failure to >>> understand an a-line in total (or even in part) results in rejecting >>> the >>> offer. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> To: Stephen Botzko >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> >>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>> >>>>>> When the offer includes parameters that the answerer > does >>> not >>>>>> understand >>>>>> there are two options, he can ignore the unknown >>> parameters >>>>> or >>>>>> reject >>>>>> the offer. >>>>>> Rejecting the offer in that case is not really kosher. >>>>>> You are required to ignore parameters you do not understand. >>>>>> >>>>>> If you reject something because you don't like the > parameters >>> it >>>>>> contains, then that is an implicit statement that you >>> understand >>>>>> those parameters well enough to decide to reject them. >>>>>> >>>>>> As far as I know, you are always free to reject offers, and it >>>>> doesn't >>>>>> really imply anything when you do that.. Whether it is wise is >>>>> perhaps >>>>>> a different question. >>>>>> Stephen Botzko >>>>> >>>>> Certainly you are always free to reject an offer. >>>>> In general I don't know for certain the reason why, and so if I > give >>>>> you >>>>> the benefit of the doubt I will assume you have a valid reason - >>>>> perhaps >>>>> just policy. >>>>> >>>>> But if the reason you reject the offer is based on your violating a >>>>> spec, then you are non-conforming, whether I can determine you are >>>>> non-conforming or not. Whether being non-conforming is just > un-wise, >>> or >>>>> something stronger, is a separate discussion. The IETF does not > levy >>>>> any >>>>> penalties for violating its specs. But sometimes the market does. >>> (And >>>>> sometimes not.) But we don't need to endorse non-conforming > behavior >>> in >>>>> our documents. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed May 18 13:42:01 2011 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 3DF72E071F for ; Wed, 18 May 2011 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iOcVxXCQ6jQ0 for ; Wed, 18 May 2011 13:41:55 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 55216E06B1 for ; Wed, 18 May 2011 13:41:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Wed, 18 May 2011 13:41:52 -0700 From: "Duckworth, Mark" To: Stephen Botzko , "Gorzynski, Mark E (The Right One)" Date: Wed, 18 May 2011 13:41:50 -0700 Thread-Topic: [clue] Definitions Thread-Index: AcwVifNsj24Nkd33SkesoulirS17MgAAHN7A Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AC06272F@CRPMBOXPRD01.polycom.com> References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> <4168915E16BA9E47972F4A4B4EE3228276B6C5FD28@GVW1096EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AC06272FCRPMBOXPRD01pol_" MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 20:42:01 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AC06272FCRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been thinking that a single dimension to the spatial ordering is eno= ugh, and can be used even for the "in the round" case as Mark G suggests. = A two dimensional example is a video wall with a two dimensional array of d= isplays, but I'm not sure if this is in scope for CLUE. I like the "stage left" idea too. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: Wednesday, May 18, 2011 2:32 PM To: Gorzynski, Mark E (The Right One) Cc: CLUE Subject: Re: [clue] Definitions I am wondering if the correct way to think about this is that the spatial r= elationships identify the proper rendering. That is, the left stream is in= tended to appear to the immediate left of the center stream. That would be = similar to your suggestion (though the "display" word isn't explicit). Alternatively, we could use the "stage left" theatrical convention (treatin= g the displays as the stage). That defines the streams from the perspectiv= e of the sender. The left stream appears on the audience's right, but is so= urced from the left side of the sending system. That has the benefit of be= ing a well established term. The educational use case (which is one where the professor and the class ar= e facing each other in the same room) is essentially un-ordered as written.= Though it could be made partially ordered, by having multiple video strea= ms cover the local classroom and also substituting a panel discussion for t= he professor. Stephen Botzko. On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) > wrote: Regarding complex environments where users are seated in multiple direction= s or in the round, can we consider the convention direction as relative to = facing a media system like a display? Is there at least a clock-wise sense= to media acquisition and reproduction where there as a counter-clockwise m= ost element and that is first (left most)? This is still pushing the conce= pt of a single-dimension to order. >From a stream generation point of view, there may indeed be media streams w= ith no logical order / spatial relation relative to other streams generated= by the same endpoint. Can we support both ordered / spatially related and= unordered un-spatially related streams from end points? Do we need a hig= her dimensional (greater than 1 dimension) means of specifying order? Mark Gorzynski From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 18, 2011 9:07 AM To: Gorzynski, Mark E (The Right One) Cc: CLUE Subject: Re: [clue] Definitions I note we have at least one use case where users in the same room are facin= g in different directions. Stephen Botzko On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) > wrote: * Agree with the point (Botzko) that "spatial relations" should refe= r to streams not devices. * Also agree with the point (stated in several places) that left-rig= ht should be clear and be defined with respect to a user facing the display= s. This will of course require being careful about maintaining this conven= tion when a stream is received. At a sender, a stream may be thus defined = as from the right-most display. But when it is received and rendered on a = display, that final destination will use the receiver's point of view. Thu= s a stream at Sender A may be labeled A-Right and then sent to receiver B f= or output to display B-Left. I would not re-label the stream from A to mat= ch the receiver convention. Thus streams might be labeled with respect to = the sender convention. * We also should be careful when considering spatial relationships t= o not make the system specific to odd or even numbers of streams in a spati= al relationship. Using left-right or -2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when "right" begins. T= his is not always true. For example a system with an even number of displa= ys and a camera above each display. Thus it may be most efficient to use t= he sense of "left" to create a beginning of a spatial relationship and orde= r streams from that beginning, 0,1,2,... Thus we may label a stream from t= he right-most display of a sender A as coming from A.2 If that stream is s= ent to a receiver for output on a left most display, that left most display= destination may be B.0. Regards Mark Gorzynski From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, May 18, 2011 8:17 AM To: Stephan Wenger Cc: CLUE Subject: Re: [clue] Definitions In-line - Stephen Botzko On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger > wrote: Hi Charles, Please see inline. In summary, I'm not convinced there is need for a change, though there may be need for more explanatory text. Stephan On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > wrote: >Hi Stephan, > >This is a great start. I do not know if you volunteered to update as >well as provide the initial version of this document. In any case, here >are some comments. > >> Endpoint - The logical point of final termination through >> receiving, decoding and rendering, and/or initiation through >> capturing, encoding, and sending of media streams. An endpoint >> consists of one or more physical devices which source and sink >> media streams. In contrast to an endpoint, a middle box, such >> as an MCU, may also send and receive media streams, but it is >> not the initiator nor the final terminator. > >I am not sure we should differentiate between endpoint and MCU. The >distinction blurs in that an MCU generates and send media streams that >are not necessarily equivalent to those it received, and it receives >input from other endpoints. I think trying to distinguish them simply >makes more work and add complexity. I also think we will find that the >majority of "MCUs" are really more "endpoints" than "MCUs". >You introduced the concept of remote. I am proposing remote =3D=3D endpoin= t >and remove MCU. Not sure here. What "endpoint" attempts to express is that it is the logical entity facing the user--the room including microphones loudspeakers, screens, cameras, and some technical stuff that sends and receives RTP streams and implements signaling. We need such a definition certainly in the requirement spec but also in the use cases. There is also a "local" endpoint, which prohibits the use of "remote". I think we should leave this definition alone. > >> Media - Any data that, after suitable encoding, can be conveyed >> over RTP, including audio, video or timed text. > >I think this is too general, but I am not able to suggest a good way to >improve it. Again, not sure why this is too general. > >> Session - RTP session. An association among a set of >> participants communicating with RTP. The distinguishing feature >> of an RTP session is that each maintains a full, separate space >> of SSRC identifiers. [RFC3550] > >In this case, do we also need a term for the collection of RTP sessions >the contains the complete set media exchanged between two endpoints? Perhaps, though I don't think we have seen that need yet. Pm the media plane, there is really no such thing as "bundling" of media transmission channels. There is a logical connection between multiple sessions, but only in the signaling. > > >"Layouts" vs. "Spatial Relations", what is the difference? A Layout is the aggregation of all spatial relations of all capture/renderer devices at a given point in time? "Left speaker is left from right speaker" is a spatial relation. "Left microphone is co-located with left camera" is a spatial relation. "Audio channel 1 is left, audio channel 2 is right, and there is only one center camera" is a layout. Although these are all examples of spatial relations, I think we need to be= very careful to distinguish microphones and audio channels (and cameras /v= ideo channels). Lots of audio systems use microphone arrays and beam formi= ng to get pickup in various parts of the room, and in principle you could u= se similar techniques for video. So in practice, I think it is essential that we describe relationships of s= treams, and not capture/render devices. Also, do we mean the "left camera" is physically located on the left, or th= at it shows participants on the left? I think the latter is the intent, an= d that it needs to be clear. Another reason perhaps to avoid talking about= camera placement. > >Cheers, >Charles > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf >Of Stephan Wenger >> Sent: Friday, May 13, 2011 11:08 AM >> To: CLUE >> Subject: [clue] Definitions >> >> Hi folks, >> Here a VERY rough initial draft. Addressing typos, sorting to >alphabetical, and other cleanup tasks >> will have to wait for the my return to the office next week. I will >submit officially only after the >> most embarrassing bugs are sorted out. No need to comment on typos, >but if you have substantial >> issues then send them now, and I can address them immediately. >> Stephan > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A61AC06272FCRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have be= en thinking that a single dimension to the spatial ordering is enough, and = can be used even for the “in the round” case as Mark G suggests= .  A two dimensional example is a video wall with a two dimensional ar= ray of displays, but I’m not sure if this is in scope for CLUE.<= /o:p>

 

I like the “stage left” idea too.=

 

Mark Duckworth

 

 

From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen= Botzko
Sent: Wednesday, May 18, 2011 2:32 PM
To: Gorzy= nski, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clu= e] Definitions

&= nbsp;

I am won= dering if the correct way to think about this is that the spatial relations= hips identify the proper rendering.  That is, the left stream is inten= ded to appear to the immediate left of the center stream. That would be sim= ilar to your suggestion (though the "display" word isn't explicit= ).  

Alternatively, we could use the "stage left&quo= t; theatrical convention (treating the displays as the stage).  That d= efines the streams from the perspective of the sender. The left stream appe= ars on the audience's right, but is sourced from the left side of the sendi= ng system.  That has the benefit of being a well established term.
=
The educational use case (which is one where the professor and the clas= s are facing each other in the same room) is essentially un-ordered as writ= ten.  Though it could be made partially ordered, by having multiple vi= deo streams cover the local classroom and also substituting a panel discuss= ion for the professor.

Stephen Botzko.

On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right = One) <mark.gorzynski@hp.com= > wrote:

Regarding complex environments where users are seated in mul= tiple directions or in the round, can we consider the convention direction = as relative to facing a media system like a display?  Is there at leas= t a clock-wise sense to media acquisition and reproduction where there as a= counter-clockwise most element and that is first (left most)?  This i= s still pushing the concept of a single-dimension to order.

 

From a s= tream generation point of view, there may indeed be media streams with no l= ogical order / spatial relation relative to other streams generated by the = same endpoint.  Can we support both ordered / spatially related and un= ordered  un-spatially related streams from end points?  Do we nee= d a higher dimensional (greater than 1 dimension) means of specifying order= ?

 

Mark Gorzynski

 =

From:<= /span> Stephen Botzko [mailto:stephen.botzko@gmail= .com]
Sent: Wednesday, May 18, 2011 9:07 AM
To: Go= rzynski, Mark E (The Right One)


Cc: CLUE
Subject: Re: [clue] Definitions=

 

I note we have= at least one use case where users in the same room are facing in different= directions.

Stephen Botzko

On Wed, May 18= , 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wro= te:

·        Agree with the point (Botzko) that “spa= tial relations” should refer to streams not devices. 

 

·&= nbsp;       Also agree with the point (stated in several places) t= hat left-right should be clear and be defined with respect to a user facing= the displays.  This will of course require being careful about mainta= ining this convention when a stream is received.  At a sender, a strea= m may be thus defined as from the right-most display.  But when it is = received and rendered on a display, that final destination will use the rec= eiver’s point of view.  Thus a stream at Sender A may be labeled= A-Right and then sent to receiver B for output to display B-Left.  I = would not re-label the stream from A to match the receiver convention. = ; Thus streams might be labeled with respect to the sender convention.

 

·=         We also should be careful when considering spatial re= lationships to not make the system specific to odd or even numbers of strea= ms in a spatial relationship.  Using left-right or
-2,-1,0,1,2 or = such things may assume a centered system where one stream is on a center ax= is or that there is a clear sense of when “right” begins. = This is not always true.  For example a system with an even number of= displays and a camera above each display.  Thus it may be most effici= ent to use the sense of “left” to create a beginning of a spati= al relationship and order streams from that beginning, 0,1,2,…  = Thus we may label a stream from the right-most display of a sender A as com= ing from A.2  If that stream is sent to a receiver for output on a lef= t most display, that left most display destination may be B.0.<= /o:p>

 

Regards

M= ark Gorzynski

 

 

 

 

From: clue-bounces@ietf.org [mailt= o:clue-bounces@i= etf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, = May 18, 2011 8:17 AM
To: Stephan Wenger
Cc: CLUE
= Subject: Re: [clue] Definitions

 =

In-line -
Stephen Botzko

On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced= there is need for a change, though there may
be need for more explanato= ry text.
Stephan


On 5.16.2011 03:34 , "Char= les Eckel (eckelcu)" <eckelcu@cisco.com> wrote:

>Hi Stephan,
>=
>This is a great start. I do not know if you volunteered to update a= s
>well as provide the initial version of this document. In any case,= here
>are some comments.
>
>> Endpoint - The logical = point of final termination through
>> receiving, decoding and rend= ering, and/or initiation through
>> capturing, encoding, and sendi= ng of media streams.  An endpoint
>> consists of one or more = physical devices which source and sink
>> media streams.  In = contrast to an endpoint, a middle box, such
>> as an MCU, may also= send and receive media streams, but it is
>> not the initiator no= r the final terminator.
>
>I am not sure we should differentiat= e between endpoint and MCU. The
>distinction blurs in that an MCU gen= erates and send media streams that
>are not necessarily equivalent to= those it received, and it receives
>input from other endpoints. I th= ink trying to distinguish them simply
>makes more work and add comple= xity. I also think we will find that the
>majority of "MCUs"= ; are really more "endpoints" than "MCUs".
>You i= ntroduced the concept of remote. I am proposing remote =3D=3D endpoint
&= gt;and remove MCU.

Not sure here.
What "= endpoint" attempts to express is that it is the logical entity
faci= ng the user--the room including microphones loudspeakers, screens,
camer= as, and some technical stuff that sends and receives RTP streams and
imp= lements signaling.  We need such a definition certainly in the
requ= irement spec but also in the use cases.  There is also a "local&q= uot;
endpoint, which prohibits the use of "remote".
I think= we should leave this definition alone.


>
>= ;> Media - Any data that, after suitable encoding, can be conveyed
&g= t;> over RTP, including audio, video or timed text.
>
>I thi= nk this is too general, but I am not able to suggest a good way to
>i= mprove it.

Again, not sure why this is too gener= al.


>
>> Session - RTP session.  A= n association among a set of
>> participants communicating with RT= P.  The distinguishing feature
>> of an RTP session is that e= ach maintains a full, separate space
>> of SSRC identifiers.  = ;[RFC3550]
>
>In this case, do we also need a term for the coll= ection of RTP sessions
>the contains the complete set media exchanged= between two endpoints?

Perhaps, though I don't = think we have seen that need yet.
Pm the media plane, there is really no= such thing as "bundling" of media
transmission channels. &nbs= p;There is a logical connection between multiple
sessions, but only in t= he signaling.


>
>
>"Layouts&quo= t; vs. "Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial relations of allcapture/renderer devices at a given point in time?
"Left speaker = is left from right speaker" is a spatial relation.
"Left micro= phone is co-located with left camera" is a spatial relation.
"= Audio channel 1 is left, audio channel 2 is right, and there is only onecenter camera" is a layout.

 

Although these are all examples of spati= al relations, I think we need to be very careful to distinguish microphones= and audio channels (and cameras /video channels).  Lots of audio syst= ems use microphone arrays and beam forming to get pickup in various parts o= f the room, and in principle you could use similar techniques for video.
So in practice, I think it is essential that we describe relationships= of streams, and not capture/render devices.

Also, do we mean the &q= uot;left camera" is physically located on the left, or that it shows p= articipants on the left?  I think the latter is the intent, and that i= t needs to be clear.  Another reason perhaps to avoid talking about ca= mera placement.
 

>
>Cheers,
>Charles
>
>
>> -----Origi= nal Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
= >> To: CLUE
>> Subject: [clue] Definitions
>>
&g= t;> Hi folks,
>> Here a VERY rough initial draft.  Address= ing typos, sorting to
>alphabetical, and other cleanup tasks
>&= gt; will have to wait for the my return to the office next week.  I wi= ll
>submit officially only after the
>> most embarrassing bu= gs are sorted out.  No need to comment on typos,
>but if you hav= e substantial
>> issues then send them now, and I can address them= immediately.
>> Stephan
>


______________________= _________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/l= istinfo/clue

 =


_______________________________= ________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/c= lue

 

<= /div>


______________= _________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/cl= ue

 

=
= --_000_44C6B6B2D0CF424AA90B6055548D7A61AC06272FCRPMBOXPRD01pol_-- From stephen.botzko@gmail.com Wed May 18 13:51:43 2011 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 00C13E074C for ; Wed, 18 May 2011 13:51:43 -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 0HkyX5aRzLSV for ; Wed, 18 May 2011 13:51:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEFE8E068B for ; Wed, 18 May 2011 13:51:40 -0700 (PDT) Received: by vws12 with SMTP id 12so1725508vws.31 for ; Wed, 18 May 2011 13:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QJeykP0vCjrjiRft7L7yyAJjXz8tDUDiqrU4s/vmxjs=; b=g6fgtkA5SoiktGFlqXzY/6szcv91W9tSylcRArB7X0S49aMOnt15gqooG3olmC1OVh 192yrpJTeSDy8JgmYhFt4ZTSsIGCjxoo+AFLrtTxyOi6cvEgLnwx4IYAKIlYFh2ilzTK 9YYipvD6H36tk7sosRjsq7YE2TbbreWdouaUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dkxp3NC0lmeZljQiPPp4ErNG3FOtzuaNbC7T+vr74D0VQ0xbd+M3NUVl1BluJUBCd8 5Hr1U/Uw8N1m7X6TJGh5zrtgwmmslMRR8Apg5myPhZPA++zDYjpInsXrRN9dS5ue2UOa LLB71eDTB4XHT+jmugMkwAex1As9E09/VhME4= MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr430493vdb.116.1305751900083; Wed, 18 May 2011 13:51:40 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Wed, 18 May 2011 13:51:40 -0700 (PDT) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AC06272F@CRPMBOXPRD01.polycom.com> References: <4168915E16BA9E47972F4A4B4EE3228276B6C5FBA3@GVW1096EXB.americas.hpqcorp.net> <4168915E16BA9E47972F4A4B4EE3228276B6C5FD28@GVW1096EXB.americas.hpqcorp.net> <44C6B6B2D0CF424AA90B6055548D7A61AC06272F@CRPMBOXPRD01.polycom.com> Date: Wed, 18 May 2011 16:51:40 -0400 Message-ID: From: Stephen Botzko To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=20cf307cfdd42b54da04a3930edc Cc: CLUE Subject: Re: [clue] Definitions 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, 18 May 2011 20:51:43 -0000 --20cf307cfdd42b54da04a3930edc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think supporting the "in the round" case implies something other than simple numbering to convey the spatial relationships - you need something like a directed graph with a syntax that allows a loop. This could also describe an MxN video wall. The way I read the charter, both "in the round" and MxN video walls are in scope. Though we would need to decide how important they are. Stephen Botzko On Wed, May 18, 2011 at 4:41 PM, Duckworth, Mark wrote: > I have been thinking that a single dimension to the spatial ordering is > enough, and can be used even for the =93in the round=94 case as Mark G su= ggests. > A two dimensional example is a video wall with a two dimensional array o= f > displays, but I=92m not sure if this is in scope for CLUE. > > > > I like the =93stage left=94 idea too. > > > > Mark Duckworth > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephen Botzko > *Sent:* Wednesday, May 18, 2011 2:32 PM > > *To:* Gorzynski, Mark E (The Right One) > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > I am wondering if the correct way to think about this is that the spatial > relationships identify the proper rendering. That is, the left stream is > intended to appear to the immediate left of the center stream. That would= be > similar to your suggestion (though the "display" word isn't explicit). > > Alternatively, we could use the "stage left" theatrical convention > (treating the displays as the stage). That defines the streams from the > perspective of the sender. The left stream appears on the audience's righ= t, > but is sourced from the left side of the sending system. That has the > benefit of being a well established term. > > The educational use case (which is one where the professor and the class > are facing each other in the same room) is essentially un-ordered as > written. Though it could be made partially ordered, by having multiple > video streams cover the local classroom and also substituting a panel > discussion for the professor. > > Stephen Botzko. > > On Wed, May 18, 2011 at 2:10 PM, Gorzynski, Mark E (The Right One) < > mark.gorzynski@hp.com> wrote: > > Regarding complex environments where users are seated in multiple > directions or in the round, can we consider the convention direction as > relative to facing a media system like a display? Is there at least a > clock-wise sense to media acquisition and reproduction where there as a > counter-clockwise most element and that is first (left most)? This is st= ill > pushing the concept of a single-dimension to order. > > > > From a stream generation point of view, there may indeed be media streams > with no logical order / spatial relation relative to other streams genera= ted > by the same endpoint. Can we support both ordered / spatially related an= d > unordered un-spatially related streams from end points? Do we need a > higher dimensional (greater than 1 dimension) means of specifying order? > > > > Mark Gorzynski > > > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, May 18, 2011 9:07 AM > *To:* Gorzynski, Mark E (The Right One) > > > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > I note we have at least one use case where users in the same room are > facing in different directions. > > Stephen Botzko > > On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) < > mark.gorzynski@hp.com> wrote: > > =B7 Agree with the point (Botzko) that =93spatial relations=94 sho= uld > refer to streams not devices. > > > > =B7 Also agree with the point (stated in several places) that > left-right should be clear and be defined with respect to a user facing t= he > displays. This will of course require being careful about maintaining th= is > convention when a stream is received. At a sender, a stream may be thus > defined as from the right-most display. But when it is received and > rendered on a display, that final destination will use the receiver=92s p= oint > of view. Thus a stream at Sender A may be labeled A-Right and then sent = to > receiver B for output to display B-Left. I would not re-label the stream > from A to match the receiver convention. Thus streams might be labeled w= ith > respect to the sender convention. > > > > =B7 We also should be careful when considering spatial relationshi= ps > to not make the system specific to odd or even numbers of streams in a > spatial relationship. Using left-right or > -2,-1,0,1,2 or such things may assume a centered system where one stream = is > on a center axis or that there is a clear sense of when =93right=94 begin= s. > This is not always true. For example a system with an even number of > displays and a camera above each display. Thus it may be most efficient = to > use the sense of =93left=94 to create a beginning of a spatial relationsh= ip and > order streams from that beginning, 0,1,2,=85 Thus we may label a stream = from > the right-most display of a sender A as coming from A.2 If that stream i= s > sent to a receiver for output on a left most display, that left most disp= lay > destination may be B.0. > > > > Regards > > Mark Gorzynski > > > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephen Botzko > *Sent:* Wednesday, May 18, 2011 8:17 AM > *To:* Stephan Wenger > *Cc:* CLUE > *Subject:* Re: [clue] Definitions > > > > In-line - > Stephen Botzko > > On Tue, May 17, 2011 at 12:17 AM, Stephan Wenger wrote: > > Hi Charles, > Please see inline. > In summary, I'm not convinced there is need for a change, though there ma= y > be need for more explanatory text. > Stephan > > > On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" wrote: > > >Hi Stephan, > > > >This is a great start. I do not know if you volunteered to update as > >well as provide the initial version of this document. In any case, here > >are some comments. > > > >> Endpoint - The logical point of final termination through > >> receiving, decoding and rendering, and/or initiation through > >> capturing, encoding, and sending of media streams. An endpoint > >> consists of one or more physical devices which source and sink > >> media streams. In contrast to an endpoint, a middle box, such > >> as an MCU, may also send and receive media streams, but it is > >> not the initiator nor the final terminator. > > > >I am not sure we should differentiate between endpoint and MCU. The > >distinction blurs in that an MCU generates and send media streams that > >are not necessarily equivalent to those it received, and it receives > >input from other endpoints. I think trying to distinguish them simply > >makes more work and add complexity. I also think we will find that the > >majority of "MCUs" are really more "endpoints" than "MCUs". > >You introduced the concept of remote. I am proposing remote =3D=3D endpo= int > >and remove MCU. > > Not sure here. > What "endpoint" attempts to express is that it is the logical entity > facing the user--the room including microphones loudspeakers, screens, > cameras, and some technical stuff that sends and receives RTP streams and > implements signaling. We need such a definition certainly in the > requirement spec but also in the use cases. There is also a "local" > endpoint, which prohibits the use of "remote". > I think we should leave this definition alone. > > > > > >> Media - Any data that, after suitable encoding, can be conveyed > >> over RTP, including audio, video or timed text. > > > >I think this is too general, but I am not able to suggest a good way to > >improve it. > > Again, not sure why this is too general. > > > > > >> Session - RTP session. An association among a set of > >> participants communicating with RTP. The distinguishing feature > >> of an RTP session is that each maintains a full, separate space > >> of SSRC identifiers. [RFC3550] > > > >In this case, do we also need a term for the collection of RTP sessions > >the contains the complete set media exchanged between two endpoints? > > Perhaps, though I don't think we have seen that need yet. > Pm the media plane, there is really no such thing as "bundling" of media > transmission channels. There is a logical connection between multiple > sessions, but only in the signaling. > > > > > > > >"Layouts" vs. "Spatial Relations", what is the difference? > > A Layout is the aggregation of all spatial relations of all > capture/renderer devices at a given point in time? > "Left speaker is left from right speaker" is a spatial relation. > "Left microphone is co-located with left camera" is a spatial relation. > "Audio channel 1 is left, audio channel 2 is right, and there is only one > center camera" is a layout. > > > > Although these are all examples of spatial relations, I think we need to = be > very careful to distinguish microphones and audio channels (and cameras > /video channels). Lots of audio systems use microphone arrays and beam > forming to get pickup in various parts of the room, and in principle you > could use similar techniques for video. > > So in practice, I think it is essential that we describe relationships of > streams, and not capture/render devices. > > Also, do we mean the "left camera" is physically located on the left, or > that it shows participants on the left? I think the latter is the intent= , > and that it needs to be clear. Another reason perhaps to avoid talking > about camera placement. > > > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >Of Stephan Wenger > >> Sent: Friday, May 13, 2011 11:08 AM > >> To: CLUE > >> Subject: [clue] Definitions > >> > >> Hi folks, > >> Here a VERY rough initial draft. Addressing typos, sorting to > >alphabetical, and other cleanup tasks > >> will have to wait for the my return to the office next week. I will > >submit officially only after the > >> most embarrassing bugs are sorted out. No need to comment on typos, > >but if you have substantial > >> issues then send them now, and I can address them immediately. > >> Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > --20cf307cfdd42b54da04a3930edc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think supporting the "in the round" case implies something othe= r than simple numbering to convey the spatial relationships - you need some= thing like a directed graph with a syntax that allows a loop.=A0 This could= also describe an MxN video wall.

The way I read the charter, both "in the round" and MxN video= walls are in scope.=A0 Though we would need to decide how important they a= re.

Stephen Botzko

On Wed, May 18,= 2011 at 4:41 PM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:=

I have been thinking that a single dimension to the spatial orderin= g is enough, and can be used even for the =93in the round=94 case as Mark G= suggests. =A0A two dimensional example is a video wall with a two dimensio= nal array of displays, but I=92m not sure if this is in scope for CLUE.

=A0

I like the =93stage left=94 idea too.

= =A0

Mark = Duckworth

=A0

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Stephen Botzko
Sent: Wednesday, May 18, 2011 2:32 PM


To: Gorzynski, Mark E (The Right One)
Cc: CLUE
Subject: Re: [clue] Definitions

=A0

I am wondering if the corr= ect way to think about this is that the spatial relationships identify the = proper rendering.=A0 That is, the left stream is intended to appear to the = immediate left of the center stream. That would be similar to your suggesti= on (though the "display" word isn't explicit).=A0=A0

Alternatively, we could use the "stage left" theatrical conve= ntion (treating the displays as the stage).=A0 That defines the streams fro= m the perspective of the sender. The left stream appears on the audience= 9;s right, but is sourced from the left side of the sending system.=A0 That= has the benefit of being a well established term.

The educational use case (which is one where the professor and the clas= s are facing each other in the same room) is essentially un-ordered as writ= ten.=A0 Though it could be made partially ordered, by having multiple video= streams cover the local classroom and also substituting a panel discussion= for the professor.

Stephen Botzko.

On Wed, May 18, 2011 at = 2:10 PM, Gorzynski, Mark E (The Right One) <mark.gorzynski@hp.com> wrote:

Regar= ding complex environments where users are seated in multiple directions or = in the round, can we consider the convention direction as relative to facin= g a media system like a display?=A0 Is there at least a clock-wise sense to= media acquisition and reproduction where there as a counter-clockwise most= element and that is first (left most)?=A0 This is still pushing the concep= t of a single-dimension to order.

=A0

From a stream generation point of view, there may indeed be media strea= ms with no logical order / spatial relation relative to other streams gener= ated by the same endpoint.=A0 Can we support both ordered / spatially relat= ed and unordered =A0un-spatially related streams from end points?=A0 Do we = need a higher dimensional (greater than 1 dimension) means of specifying or= der?

=A0

Mark Gorzynski

=A0

From:= Stephen Botzko [mailto:stephen.botzko@gmail.com] <= br>Sent: Wednesday, May 18, 2011 9:07 AM
To: Gorzynski, Mark E (The Right One)


Cc: CLUE
Subject: Re: [clue] Definition= s

=A0

I note we have at least one use case where users in the same room are facin= g in different directions.

Stephen Botzko

On Wed, May 18, 2011 at 12:00 PM, Gorzynski, Mark E (The Right One) &l= t;mark.gorzynski= @hp.com> wrote:

=B7=A0=A0=A0=A0=A0= =A0=A0 Agree with the= point (Botzko) that =93spatial relations=94 should refer to streams not de= vices.=A0

=A0

=B7=A0=A0=A0=A0=A0= =A0=A0 Also agree wit= h the point (stated in several places) that left-right should be clear and = be defined with respect to a user facing the displays.=A0 This will of cour= se require being careful about maintaining this convention when a stream is= received.=A0 At a sender, a stream may be thus defined as from the right-m= ost display.=A0 But when it is received and rendered on a display, that fin= al destination will use the receiver=92s point of view.=A0 Thus a stream at= Sender A may be labeled A-Right and then sent to receiver B for output to = display B-Left.=A0 I would not re-label the stream from A to match the rece= iver convention.=A0 Thus streams might be labeled with respect to the sende= r convention.

=A0

=B7=A0=A0=A0=A0=A0=A0=A0 We also should be careful when cons= idering spatial relationships to not make the system specific to odd or eve= n numbers of streams in a spatial relationship.=A0 Using left-right or
-2,-1,0,1,2 or such things may assume a centered system where one stream is= on a center axis or that there is a clear sense of when =93right=94 begins= .=A0 This is not always true.=A0 For example a system with an even number o= f displays and a camera above each display.=A0 Thus it may be most efficien= t to use the sense of =93left=94 to create a beginning of a spatial relatio= nship and order streams from that beginning, 0,1,2,=85=A0 Thus we may label= a stream from the right-most display of a sender A as coming from A.2=A0 I= f that stream is sent to a receiver for output on a left most display, that= left most display destination may be B.0.

=A0

Regards

Mar= k Gorzynski

=A0

=A0

=A0

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen= Botzko
Sent: Wednesday, May 18, 2011 8:17 AM
To: Stephan WengerCc: CLUE
Subject: Re: [clue] Definitions

=A0

In-line -
Stephen Botzko

On Tu= e, May 17, 2011 at 12:17 AM, Stephan Wenger <stewe@stewe.org> wrote:

Hi Charles,
Please see inline.
In summary, I'm not convinced ther= e is need for a change, though there may
be need for more explanatory te= xt.
Stephan


On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrot= e:

>Hi Stephan,
>
>This is a great start. I do not kn= ow if you volunteered to update as
>well as provide the initial version of this document. In any case, here=
>are some comments.
>
>> Endpoint - The logical point= of final termination through
>> receiving, decoding and rendering= , and/or initiation through
>> capturing, encoding, and sending of media streams. =A0An endpoint<= br>>> consists of one or more physical devices which source and sink<= br>>> media streams. =A0In contrast to an endpoint, a middle box, suc= h
>> as an MCU, may also send and receive media streams, but it is
&= gt;> not the initiator nor the final terminator.
>
>I am not= sure we should differentiate between endpoint and MCU. The
>distinct= ion blurs in that an MCU generates and send media streams that
>are not necessarily equivalent to those it received, and it receives>input from other endpoints. I think trying to distinguish them simply<= br>>makes more work and add complexity. I also think we will find that t= he
>majority of "MCUs" are really more "endpoints" than= "MCUs".
>You introduced the concept of remote. I am propos= ing remote =3D=3D endpoint
>and remove MCU.

Not sure here.
What "endpoint" attempts to express is that it = is the logical entity
facing the user--the room including microphones lo= udspeakers, screens,
cameras, and some technical stuff that sends and re= ceives RTP streams and
implements signaling. =A0We need such a definition certainly in the
requ= irement spec but also in the use cases. =A0There is also a "local"= ;
endpoint, which prohibits the use of "remote".
I think we= should leave this definition alone.


>
>= > Media - Any data that, after suitable encoding, can be conveyed
>= ;> over RTP, including audio, video or timed text.
>
>I thin= k this is too general, but I am not able to suggest a good way to
>improve it.

Again, not sure why this is= too general.


>
>> Session - RTP session. =A0An association among a set = of
>> participants communicating with RTP. =A0The distinguishing feature=
>> of an RTP session is that each maintains a full, separate spac= e
>> of SSRC identifiers. =A0[RFC3550]
>
>In this case= , do we also need a term for the collection of RTP sessions
>the contains the complete set media exchanged between two endpoints?

Perhaps, though I don't think we have see= n that need yet.
Pm the media plane, there is really no such thing as &q= uot;bundling" of media
transmission channels. =A0There is a logical connection between multiplesessions, but only in the signaling.


>
>
>"Layouts" vs. &= quot;Spatial Relations", what is the difference?

A Layout is the aggregation of all spatial rel= ations of all
capture/renderer devices at a given point in time?
&quo= t;Left speaker is left from right speaker" is a spatial relation.
"Left microphone is co-located with left camera" is a spatial rel= ation.
"Audio channel 1 is left, audio channel 2 is right, and ther= e is only one
center camera" is a layout.

=A0

Although these are all examp= les of spatial relations, I think we need to be very careful to distinguish= microphones and audio channels (and cameras /video channels).=A0 Lots of a= udio systems use microphone arrays and beam forming to get pickup in variou= s parts of the room, and in principle you could use similar techniques for = video.

So in practice, I think it is essential that we describe relationships = of streams, and not capture/render devices.

Also, do we mean the &qu= ot;left camera" is physically located on the left, or that it shows pa= rticipants on the left?=A0 I think the latter is the intent, and that it ne= eds to be clear.=A0 Another reason perhaps to avoid talking about camera pl= acement.
=A0

>
>Che= ers,
>Charles
>
>
>> -----Original Message-----
>&= gt; From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
>Of Stephan Wenger
>> Sent: Friday, May 13, 2011 11:08 AM
&g= t;> To: CLUE
>> Subject: [clue] Definitions
>>
>= > Hi folks,
>> Here a VERY rough initial draft. =A0Addressing t= ypos, sorting to
>alphabetical, and other cleanup tasks
>> will have to wait for= the my return to the office next week. =A0I will
>submit officially = only after the
>> most embarrassing bugs are sorted out. =A0No nee= d to comment on typos,
>but if you have substantial
>> issues then send them now, and = I can address them immediately.
>> Stephan
>


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

=A0


_______________________________________________
clue mailing listclue@ietf.org
http= s://www.ietf.org/mailman/listinfo/clue

=A0


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

=A0


--20cf307cfdd42b54da04a3930edc-- From pkyzivat@cisco.com Wed May 18 16:37:52 2011 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 9E437E07AC for ; Wed, 18 May 2011 16:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.584 X-Spam-Level: X-Spam-Status: No, score=-108.584 tagged_above=-999 required=5 tests=[AWL=-1.884, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8, 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 fqPqy4HApU-s for ; Wed, 18 May 2011 16:37:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id AEEC4E07A9 for ; Wed, 18 May 2011 16:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8455; q=dns/txt; s=iport; t=1305761871; x=1306971471; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Yy3Pbksl0jcYWCO5TExgVYSCrv+ugCm+yTsElZ0k9O8=; b=IZCkrpQBguQ/C0XPvZxSToW3Oe0/uVMwaQKHDx3eRxMxmYHHTBueRe8u OQPZ5oUmwRXM7x7WO1hiCBPndA1Olf2m0jDgTXPcPiVonnshv6CV5Sy6e 5lGH/Ok2UzJEyJLkyJNJvTRVCTQYzsCGEkP1Db7MI2AD3bntQPzy/rx96 M=; X-IronPort-AV: E=Sophos;i="4.65,234,1304294400"; d="scan'208";a="450395492" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 18 May 2011 23:37:51 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4INbo0r008423; Wed, 18 May 2011 23:37:50 GMT Message-ID: <4DD4584E.30405@cisco.com> Date: Wed, 18 May 2011 19:37:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.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] legacy support in requirements 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, 18 May 2011 23:37:52 -0000 On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > Paul, > > Murphy's Law says that if it is possible to put something together the > wrong way, > probability says it will go the wrong way sooner or later. LTC Murphy > had a > young enlisted guy that always found that wrong way to do things. > System-wise, > the black-swan events occur unless you do your best to design them out. > > Machines are often designed so that there is exactly one way to do it. > > We want flexibility in software, but sometimes too much is not so good. > Hopefully, proper operation of the protocol won't look like an error. Mike, I don't understand the point you are trying to make in the context of this conversation. This started out as a discussion of whether it was acceptable to reject an offer because it contains stuff (for the sake of argument lets restrict it to a-lines for now) the the answerer doesn't understand/know anything about. Clearly its *possible* for a UA to do that. And since a UA can reject things for policy reasons, it may be undecidable whether it rejected because of the unknown lines or for some more justifed reason. But still, I think we can *expect* a UA to refrain from doing that. That doesn't mean they all will. But when they don't, its a bug, not a valid implementation choice. Thanks, Paul > Mike > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 1:09 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >> Paul, >> >> I would agree that if the offer-answer model semantic is that here are >> several options and any subset of options is acceptable. >> >> However, if there is any grouping involved such that you need to have > a >> video and audio feed integrated to make sense then watch out. >> >> For example, I wouldn't want to end up with the result of a man's > video >> paired with a woman's voice. That could be rather comical. > > Well, SDP defines that you should ignore what you don't understand and > operate on what is left. > > So someone constructing an SDP with grouping issues such as you define > ought to keep in mind that this could happen, and set things up so that > something reasonable happens. You can't expect the dumb legacy device to > > figure out much. > > For your example, the result may be far from ideal, but it still is > likely to be better than no call at all. And if not, there is always the > > option of hanging up. But better, presumably the offer could have been > constructed in a way that produced a better result. > > Thanks, > Paul > >> Mike >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Paul Kyzivat (pkyzivat) >> Sent: Tuesday, May 17, 2011 7:45 PM >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 6:05 PM, Roni Even wrote: >>> Paul, >>> I think we read it differently. >>> If the answerer does not support the group attribute and the offer > had >> the >>> fid semantics it may look to the answerer as an offer with multiple >> m-lines >>> of the same media tyoe. In this case an implementation might also >> decide to >>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >> Acceptable), >>> because it contains several "m" lines of the same media type. >> >> That is a slightly different story. >> >> Then the reason for rejection is not because it saw an attribute it >> didn't understand - its because it didn't like something it *did* >> understand. >> >>> This is very relevant to the multiple streams case and we should look >> if we >>> state this behavior or we will look at providing an approach that > will >> allow >>> the answerer to choose one m-line that the offerer prefers even of it >> does >>> not understand CLUE. >> >> IMO (lets see if others differ), if a UA receives an offer with at > least >> >> one m-line it is happy with, then it should not reject the call > because >> there are others that it does not "understand". >> >> Here "understand" means something different - presumably it does >> understand the direct meaning of the additional m-line, it just > doesn't >> understand the *significance* or use of it. >> >> I see little difference to getting to audio m-lines and only wanting >> one, and getting one audio and one video and only supporting audio. In >> general you should not reject an audio/video call just because you > only >> support audio. >> >> I think it will behoove clue to strongly recommend that the m-lines in >> an offer be arranged so the first ones are the ones it most wants used >> if not all are. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>> To: Roni Even >>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> Paul, >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example >>>>> Roni >>>> >>>> OK, I looked. It is consistent with what I said. >>>> Either a=group: is understood, or not. If not, its ignored, and not >> put >>>> in the answer. Same with a=mid: >>>> >>>> If a=group: *is* understood, but some parameter within it is not, >> there >>>> are explicit rules for what to do. >>>> >>>> AFAICT there are no examples in this document where failure to >>>> understand an a-line in total (or even in part) results in rejecting >>>> the >>>> offer. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> To: Stephen Botzko >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>> >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>> >>>>>>> When the offer includes parameters that the answerer >> does >>>> not >>>>>>> understand >>>>>>> there are two options, he can ignore the unknown >>>> parameters >>>>>> or >>>>>>> reject >>>>>>> the offer. >>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>> You are required to ignore parameters you do not > understand. >>>>>>> >>>>>>> If you reject something because you don't like the >> parameters >>>> it >>>>>>> contains, then that is an implicit statement that you >>>> understand >>>>>>> those parameters well enough to decide to reject them. >>>>>>> >>>>>>> As far as I know, you are always free to reject offers, and it >>>>>> doesn't >>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>> perhaps >>>>>>> a different question. >>>>>>> Stephen Botzko >>>>>> >>>>>> Certainly you are always free to reject an offer. >>>>>> In general I don't know for certain the reason why, and so if I >> give >>>>>> you >>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>> perhaps >>>>>> just policy. >>>>>> >>>>>> But if the reason you reject the offer is based on your violating > a >>>>>> spec, then you are non-conforming, whether I can determine you are >>>>>> non-conforming or not. Whether being non-conforming is just >> un-wise, >>>> or >>>>>> something stronger, is a separate discussion. The IETF does not >> levy >>>>>> any >>>>>> penalties for violating its specs. But sometimes the market does. >>>> (And >>>>>> sometimes not.) But we don't need to endorse non-conforming >> behavior >>>> in >>>>>> our documents. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From stephane.cazeaux@orange-ftgroup.com Thu May 19 00:19:13 2011 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 C8006E06F2 for ; Thu, 19 May 2011 00:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 9q8g7-sJ04Cd for ; Thu, 19 May 2011 00:19:12 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 72D96E06C4 for ; Thu, 19 May 2011 00:19:10 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E40B6738001; Thu, 19 May 2011 09:20:24 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id D70C06F8004; Thu, 19 May 2011 09:20:24 +0200 (CEST) Received: from ftrdhub1.rd.francetelecom.fr ([10.193.109.193]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 09:19:09 +0200 Received: from FTRDCH01.rd.francetelecom.fr (10.194.32.11) by ftrdhub1.rd.francetelecom.fr (10.193.109.193) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 May 2011 09:19:08 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Thu, 19 May 2011 09:19:07 +0200 From: To: , , Thread-Topic: [clue] Definitions Thread-Index: AcwVbE+a146t/LGk30ms//XJA7T93AAEzhdQABzTIRA= Date: Thu, 19 May 2011 07:17:10 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 May 2011 07:19:09.0136 (UTC) FILETIME=[0B855500:01CC15F5] Subject: Re: [clue] Definitions 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, 19 May 2011 07:19:13 -0000 Hi Mark, Stephan, On my side, I think we should consider cases where we have several SIP UAs = in a single telepresence room.=20 Another discussion is to define the relation between an endpoint and a SIP = UA. IMO, we should define an endpoint as composed of one single SIP UA, and= the endpoint represents all equipment associated to the SIP UA (including = multi-screen/camera). Thus we should consider cases where a telepresence room is composed of seve= ral endpoints. As I suggested in a previous mail, I think that such cases w= ill necessarily exist, with proprietary implementations (thus not interoper= able) in MCU to associate several endpoints so that they form a single tele= presence room. That's why we should consider these cases to have interopera= bility rules. Stephane.=20 -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de D= uckworth, Mark Envoy=E9=A0: mercredi 18 mai 2011 19:27 =C0=A0: Stephan Wenger; clue@ietf.org Objet=A0: Re: [clue] Definitions Stephan, My understanding is an endpoint has a single SIP UA. And there would be on= ly one endpoint in a room. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Wednesday, May 18, 2011 2:00 AM > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > eckelcu@cisco.com; clue@ietf.org > Subject: Re: [clue] Definitions >=20 > Hi Stephane, > Very good point. >=20 > Quoting from RFC 4353 >=20 > [...] > Participant: The software element that connects a user or automat= a to > a conference. It implements, at a minimum, a SIP user agent, but > may also implement non-SIP-specific mechanisms for additional > functionality. > [...] >=20 > My understanding of "endpoint" is that an endpoint encompasses ALL > equipment in a telepresence room. I believe that there are cases where w= e > can have multiple SIP user agents (Uas) in one room. Think of a bunch of > codec boxes in a rack, all having their own UA. Is this the common > understanding of the group? >=20 > To ask the question differently, do we have an agreement that there is a > single SIP UA in one room? >=20 > Guidance, please. >=20 > Thanks, > Stephan >=20 >=20 >=20 >=20 > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > wrote: >=20 > >I don't think that we want to limit the "endpoint" definition to > entities > >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need to > >understand characteristics of the remote, and could maybe have also > some > >characteristics. I don't think we want to exclude such cases. > > > >Relying on the "participant" definition of RFC4353, a telepresence > >conference will be composed of "participants", where a participant is > >connected to the conference through an "endpoint". In telepresence, > the > >participant will have to be aware of the endpoint, in particular when > the > >participant needs to inform the remote of the characteristics of its > >endpoint. > > > >Thus my proposition is to clarify that "endpoint" defines the entity > >through which a participant (we do not limit to entity facing a user) > is > >connected to a telepresence conference. > > > >In the same manner, we could also use the "mixer" word instead of > "MCU". > > > >Most of requirements should then apply on the participant or mixer > >(typically, a participant will describe characteristics of its > endpoint). > > > > > >Regards, > >Stephane. > > > > > >-----Message d'origine----- > >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > de > >Espen Berger (espeberg) > >Envoy=E9 : mercredi 18 mai 2011 10:40 > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > >Objet : Re: [clue] Definitions > > > >I think we should keep both endpoints and MCUs in the definition > >document. > > > >One difference between endpoints and MCUs are how they handle media. > An > >endpoint usually send media representing itself and MCUs send media on > >behalf of others remote endpoint connected. > > > >Cheers > > > >-Espen > > > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >Stephan Wenger > >Sent: 17. mai 2011 06:17 > >To: Charles Eckel (eckelcu); CLUE > >Subject: Re: [clue] Definitions > > > >Hi Charles, > >Please see inline. > >In summary, I'm not convinced there is need for a change, though there > >may > >be need for more explanatory text. > >Stephan > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > >wrote: > > > >>Hi Stephan, > >> > >>This is a great start. I do not know if you volunteered to update as > >>well as provide the initial version of this document. In any case, > here > >>are some comments. > >> > >>> Endpoint - The logical point of final termination through > >>> receiving, decoding and rendering, and/or initiation through > >>> capturing, encoding, and sending of media streams. An endpoint > >>> consists of one or more physical devices which source and sink > >>> media streams. In contrast to an endpoint, a middle box, such > >>> as an MCU, may also send and receive media streams, but it is > >>> not the initiator nor the final terminator. > >> > >>I am not sure we should differentiate between endpoint and MCU. The > >>distinction blurs in that an MCU generates and send media streams > that > >>are not necessarily equivalent to those it received, and it receives > >>input from other endpoints. I think trying to distinguish them simply > >>makes more work and add complexity. I also think we will find that > the > >>majority of "MCUs" are really more "endpoints" than "MCUs". > >>You introduced the concept of remote. I am proposing remote =3D=3D > endpoint > >>and remove MCU. > > > >Not sure here. > >What "endpoint" attempts to express is that it is the logical entity > >facing the user--the room including microphones loudspeakers, screens, > >cameras, and some technical stuff that sends and receives RTP streams > >and > >implements signaling. We need such a definition certainly in the > >requirement spec but also in the use cases. There is also a "local" > >endpoint, which prohibits the use of "remote". > >I think we should leave this definition alone. > > > >> > >>> Media - Any data that, after suitable encoding, can be conveyed > >>> over RTP, including audio, video or timed text. > >> > >>I think this is too general, but I am not able to suggest a good way > to > >>improve it. > > > >Again, not sure why this is too general. > > > >> > >>> Session - RTP session. An association among a set of > >>> participants communicating with RTP. The distinguishing feature > >>> of an RTP session is that each maintains a full, separate space > >>> of SSRC identifiers. [RFC3550] > >> > >>In this case, do we also need a term for the collection of RTP > sessions > >>the contains the complete set media exchanged between two endpoints? > > > >Perhaps, though I don't think we have seen that need yet. > >Pm the media plane, there is really no such thing as "bundling" of > media > >transmission channels. There is a logical connection between multiple > >sessions, but only in the signaling. > > > >> > >> > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > >A Layout is the aggregation of all spatial relations of all > >capture/renderer devices at a given point in time? > >"Left speaker is left from right speaker" is a spatial relation. > >"Left microphone is co-located with left camera" is a spatial > relation. > >"Audio channel 1 is left, audio channel 2 is right, and there is only > >one > >center camera" is a layout. > > > >> > >>Cheers, > >>Charles > >> > >> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>Of Stephan Wenger > >>> Sent: Friday, May 13, 2011 11:08 AM > >>> To: CLUE > >>> Subject: [clue] Definitions > >>> > >>> Hi folks, > >>> Here a VERY rough initial draft. Addressing typos, sorting to > >>alphabetical, and other cleanup tasks > >>> will have to wait for the my return to the office next week. I > will > >>submit officially only after the > >>> most embarrassing bugs are sorted out. No need to comment on > typos, > >>but if you have substantial > >>> issues then send them now, and I can address them immediately. > >>> Stephan > >> > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Thu May 19 04:10:02 2011 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 48174E077F for ; Thu, 19 May 2011 04:10:02 -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 jRa6aBi8NgeF for ; Thu, 19 May 2011 04:09:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D364E0656 for ; Thu, 19 May 2011 04:09:57 -0700 (PDT) Received: by vws12 with SMTP id 12so2177338vws.31 for ; Thu, 19 May 2011 04:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sDakOFmafQT5N3/ZeXzhxQmt4Al6aSsyIZpIqcKuiTQ=; b=HCDVKqovYo5xq2iUIQqXWeZYpK2j2HSni3sAIRaADmuxdoeAzzsa/ngdzVuSuHfyL5 mmvlHxAk8fRwjavW1/ygxZdlD71FgQi35N442UXqqE9a63LJDO4RNGSUxYzIWgfOa6EV HqliUx7P4vsg6N+uvZXfgwqieTIOI4uMvBtAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jWelMHGEaAeyP9GV9E32wA1YzCjzDtv1UCa3XrMO8UGZoQFSKXlQNaWMFzpiVp7QyI aK5bsmD6rTYcMvGNE5k2RtIIOsg+JAX2SNbJ8K1NmIqa8eEzyIN5m53XV6RbGLeMfraI urM+6E5nexgPxOpNQJW8JzYrDCp54D2R3vtPs= MIME-Version: 1.0 Received: by 10.52.106.232 with SMTP id gx8mr4229603vdb.236.1305803396857; Thu, 19 May 2011 04:09:56 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Thu, 19 May 2011 04:09:56 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> Date: Thu, 19 May 2011 07:09:56 -0400 Message-ID: From: Stephen Botzko To: stephane.cazeaux@orange-ftgroup.com Content-Type: multipart/alternative; boundary=bcaec547ca339dbedc04a39f0b22 Cc: clue@ietf.org Subject: Re: [clue] Definitions 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, 19 May 2011 11:10:02 -0000 --bcaec547ca339dbedc04a39f0b22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am confused about how CLUE can make interoperability with proprietary systems a requirement [or a consideration]. There is quite broad consensus among manufacturers that a single UA is the right approach for standardization. The systems in the room need to be highly integrated to create the telepresence experience, and external telepresence MCUs need to have explicit knowledge about what systems are in what rooms, and how the systems are arranged within the room. Coordinated management of the endpoints is problematic. Even simple dialing between rooms becomes complicated. Stephen Botzko On Thu, May 19, 2011 at 3:17 AM, wrote= : > Hi Mark, Stephan, > > On my side, I think we should consider cases where we have several SIP UA= s > in a single telepresence room. > > Another discussion is to define the relation between an endpoint and a SI= P > UA. IMO, we should define an endpoint as composed of one single SIP UA, a= nd > the endpoint represents all equipment associated to the SIP UA (including > multi-screen/camera). > > Thus we should consider cases where a telepresence room is composed of > several endpoints. As I suggested in a previous mail, I think that such > cases will necessarily exist, with proprietary implementations (thus not > interoperable) in MCU to associate several endpoints so that they form a > single telepresence room. That's why we should consider these cases to ha= ve > interoperability rules. > > > Stephane. > > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de > Duckworth, Mark > Envoy=E9 : mercredi 18 mai 2011 19:27 > =C0 : Stephan Wenger; clue@ietf.org > Objet : Re: [clue] Definitions > > Stephan, > > My understanding is an endpoint has a single SIP UA. And there would be > only one endpoint in a room. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Stephan Wenger > > Sent: Wednesday, May 18, 2011 2:00 AM > > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > > eckelcu@cisco.com; clue@ietf.org > > Subject: Re: [clue] Definitions > > > > Hi Stephane, > > Very good point. > > > > Quoting from RFC 4353 > > > > [...] > > Participant: The software element that connects a user or > automata to > > a conference. It implements, at a minimum, a SIP user agent, b= ut > > may also implement non-SIP-specific mechanisms for additional > > functionality. > > [...] > > > > My understanding of "endpoint" is that an endpoint encompasses ALL > > equipment in a telepresence room. I believe that there are cases where > we > > can have multiple SIP user agents (Uas) in one room. Think of a bunch = of > > codec boxes in a rack, all having their own UA. Is this the common > > understanding of the group? > > > > To ask the question differently, do we have an agreement that there is = a > > single SIP UA in one room? > > > > Guidance, please. > > > > Thanks, > > Stephan > > > > > > > > > > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > > wrote: > > > > >I don't think that we want to limit the "endpoint" definition to > > entities > > >facing a user. We could have entities not facing a user (e.g. an > > >automata), but which are sending/receiving media, and which need to > > >understand characteristics of the remote, and could maybe have also > > some > > >characteristics. I don't think we want to exclude such cases. > > > > > >Relying on the "participant" definition of RFC4353, a telepresence > > >conference will be composed of "participants", where a participant is > > >connected to the conference through an "endpoint". In telepresence, > > the > > >participant will have to be aware of the endpoint, in particular when > > the > > >participant needs to inform the remote of the characteristics of its > > >endpoint. > > > > > >Thus my proposition is to clarify that "endpoint" defines the entity > > >through which a participant (we do not limit to entity facing a user) > > is > > >connected to a telepresence conference. > > > > > >In the same manner, we could also use the "mixer" word instead of > > "MCU". > > > > > >Most of requirements should then apply on the participant or mixer > > >(typically, a participant will describe characteristics of its > > endpoint). > > > > > > > > >Regards, > > >Stephane. > > > > > > > > >-----Message d'origine----- > > >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > > de > > >Espen Berger (espeberg) > > >Envoy=E9 : mercredi 18 mai 2011 10:40 > > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > > >Objet : Re: [clue] Definitions > > > > > >I think we should keep both endpoints and MCUs in the definition > > >document. > > > > > >One difference between endpoints and MCUs are how they handle media. > > An > > >endpoint usually send media representing itself and MCUs send media on > > >behalf of others remote endpoint connected. > > > > > >Cheers > > > > > >-Espen > > > > > > > > >-----Original Message----- > > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > >Stephan Wenger > > >Sent: 17. mai 2011 06:17 > > >To: Charles Eckel (eckelcu); CLUE > > >Subject: Re: [clue] Definitions > > > > > >Hi Charles, > > >Please see inline. > > >In summary, I'm not convinced there is need for a change, though there > > >may > > >be need for more explanatory text. > > >Stephan > > > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > > >wrote: > > > > > >>Hi Stephan, > > >> > > >>This is a great start. I do not know if you volunteered to update as > > >>well as provide the initial version of this document. In any case, > > here > > >>are some comments. > > >> > > >>> Endpoint - The logical point of final termination through > > >>> receiving, decoding and rendering, and/or initiation through > > >>> capturing, encoding, and sending of media streams. An endpoint > > >>> consists of one or more physical devices which source and sink > > >>> media streams. In contrast to an endpoint, a middle box, such > > >>> as an MCU, may also send and receive media streams, but it is > > >>> not the initiator nor the final terminator. > > >> > > >>I am not sure we should differentiate between endpoint and MCU. The > > >>distinction blurs in that an MCU generates and send media streams > > that > > >>are not necessarily equivalent to those it received, and it receives > > >>input from other endpoints. I think trying to distinguish them simply > > >>makes more work and add complexity. I also think we will find that > > the > > >>majority of "MCUs" are really more "endpoints" than "MCUs". > > >>You introduced the concept of remote. I am proposing remote =3D=3D > > endpoint > > >>and remove MCU. > > > > > >Not sure here. > > >What "endpoint" attempts to express is that it is the logical entity > > >facing the user--the room including microphones loudspeakers, screens, > > >cameras, and some technical stuff that sends and receives RTP streams > > >and > > >implements signaling. We need such a definition certainly in the > > >requirement spec but also in the use cases. There is also a "local" > > >endpoint, which prohibits the use of "remote". > > >I think we should leave this definition alone. > > > > > >> > > >>> Media - Any data that, after suitable encoding, can be conveyed > > >>> over RTP, including audio, video or timed text. > > >> > > >>I think this is too general, but I am not able to suggest a good way > > to > > >>improve it. > > > > > >Again, not sure why this is too general. > > > > > >> > > >>> Session - RTP session. An association among a set of > > >>> participants communicating with RTP. The distinguishing feature > > >>> of an RTP session is that each maintains a full, separate space > > >>> of SSRC identifiers. [RFC3550] > > >> > > >>In this case, do we also need a term for the collection of RTP > > sessions > > >>the contains the complete set media exchanged between two endpoints? > > > > > >Perhaps, though I don't think we have seen that need yet. > > >Pm the media plane, there is really no such thing as "bundling" of > > media > > >transmission channels. There is a logical connection between multiple > > >sessions, but only in the signaling. > > > > > >> > > >> > > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > > > >A Layout is the aggregation of all spatial relations of all > > >capture/renderer devices at a given point in time? > > >"Left speaker is left from right speaker" is a spatial relation. > > >"Left microphone is co-located with left camera" is a spatial > > relation. > > >"Audio channel 1 is left, audio channel 2 is right, and there is only > > >one > > >center camera" is a layout. > > > > > >> > > >>Cheers, > > >>Charles > > >> > > >> > > >>> -----Original Message----- > > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>Of Stephan Wenger > > >>> Sent: Friday, May 13, 2011 11:08 AM > > >>> To: CLUE > > >>> Subject: [clue] Definitions > > >>> > > >>> Hi folks, > > >>> Here a VERY rough initial draft. Addressing typos, sorting to > > >>alphabetical, and other cleanup tasks > > >>> will have to wait for the my return to the office next week. I > > will > > >>submit officially only after the > > >>> most embarrassing bugs are sorted out. No need to comment on > > typos, > > >>but if you have substantial > > >>> issues then send them now, and I can address them immediately. > > >>> Stephan > > >> > > > > > > > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > 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 > --bcaec547ca339dbedc04a39f0b22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am confused about how CLUE can make interoperability with proprietary sys= tems a requirement [or a consideration].

There is quite broad consen= sus among manufacturers that a single UA is the right approach for standard= ization.=A0 The systems in the room need to be highly integrated to create = the telepresence experience, and external telepresence MCUs need to have ex= plicit knowledge about what systems are in what rooms, and how the systems = are arranged within the room.=A0 Coordinated management of the endpoints is= problematic.=A0 Even simple dialing between rooms becomes complicated.
Stephen Botzko

On Thu, May 19, 2011 a= t 3:17 AM, <stephane.cazeaux@orange-ftgroup.com> wrote:
=
Hi Mark, Stephan,

On my side, I think we should consider cases where we have several SIP UAs = in a single telepresence room.

Another discussion is to define the relation between an endpoint and a SIP = UA. IMO, we should define an endpoint as composed of one single SIP UA, and= the endpoint represents all equipment associated to the SIP UA (including = multi-screen/camera).

Thus we should consider cases where a telepresence room is composed of seve= ral endpoints. As I suggested in a previous mail, I think that such cases w= ill necessarily exist, with proprietary implementations (thus not interoper= able) in MCU to associate several endpoints so that they form a single tele= presence room. That's why we should consider these cases to have intero= perability rules.


Stephane.

-----Message d'origine-----
De=A0: clue-bounces@ietf.org [= mailto:clue-bounces@ietf.org] = De la part de Duckworth, Mark
Envoy=E9=A0: mercredi 18 mai 2011 19:27
=C0=A0: Stephan Wenger; clue@ietf.org<= br> Objet=A0: Re: [clue] Definitions

Stephan,

My understanding is an endpoint has a single SIP UA. =A0And there would be = only one endpoint in a room.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Stephan Wenger
> Sent: Wednesday, May 18, 2011 2:00 AM
> To: stephane.ca= zeaux@orange-ftgroup.com; espeber= g@cisco.com;
> eckelcu@cisco.com; clue@ietf.org
> Subject: Re: [clue] Definitions
>
> Hi Stephane,
> Very good point.
>
> Quoting from RFC 4353
>
> [...]
> =A0 =A0 =A0 =A0 Participant: The software element that connects a user= or automata to
> =A0 =A0 =A0 =A0 a conference. =A0It implements, at a minimum, a SIP us= er agent, but
> =A0 =A0 =A0 =A0 may also implement non-SIP-specific mechanisms for add= itional
> =A0 =A0 =A0 =A0 functionality.
> [...]
>
> My understanding of "endpoint" is that an endpoint encompass= es ALL
> equipment in a telepresence room. =A0I believe that there are cases wh= ere we
> can have multiple SIP user agents (Uas) in one room. =A0Think of a bun= ch of
> codec boxes in a rack, all having their own UA. =A0Is this the common<= br> > understanding of the group?
>
> To ask the question differently, do we have an agreement that there is= a
> single SIP UA in one room?
>
> Guidance, please.
>
> Thanks,
> Stephan
>
>
>
>
> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com"
> <stephane.ca= zeaux@orange-ftgroup.com> wrote:
>
> >I don't think that we want to limit the "endpoint" d= efinition to
> entities
> >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need t= o
> >understand characteristics of the remote, and could maybe have als= o
> some
> >characteristics. I don't think we want to exclude such cases.<= br> > >
> >Relying on the "participant" definition of RFC4353, a te= lepresence
> >conference will be composed of "participants", where a p= articipant is
> >connected to the conference through an "endpoint". In te= lepresence,
> the
> >participant will have to be aware of the endpoint, in particular w= hen
> the
> >participant needs to inform the remote of the characteristics of i= ts
> >endpoint.
> >
> >Thus my proposition is to clarify that "endpoint" define= s the entity
> >through which a participant (we do not limit to entity facing a us= er)
> is
> >connected to a telepresence conference.
> >
> >In the same manner, we could also use the "mixer" word i= nstead of
> "MCU".
> >
> >Most of requirements should then apply on the participant or mixer=
> >(typically, a participant will describe characteristics of its
> endpoint).
> >
> >
> >Regards,
> >Stephane.
> >
> >
> >-----Message d'origine-----
> >De : clue-bounces@ietf.or= g [mailto:clue-bounces@ietf.or= g] De la part
> de
> >Espen Berger (espeberg)
> >Envoy=E9 : mercredi 18 mai 2011 10:40
> >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE
> >Objet : Re: [clue] Definitions
> >
> >I think we should keep both endpoints and MCUs in the definition > >document.
> >
> >One difference between endpoints and MCUs are how they handle medi= a.
> An
> >endpoint usually send media representing itself and MCUs send medi= a on
> >behalf of others remote endpoint connected.
> >
> >Cheers
> >
> >-Espen
> >
> >
> >-----Original Message-----
> >From: clue-bounces@ietf.o= rg [mailto:clue-bounces@ietf.o= rg] On Behalf
> Of
> >Stephan Wenger
> >Sent: 17. mai 2011 06:17
> >To: Charles Eckel (eckelcu); CLUE
> >Subject: Re: [clue] Definitions
> >
> >Hi Charles,
> >Please see inline.
> >In summary, I'm not convinced there is need for a change, thou= gh there
> >may
> >be need for more explanatory text.
> >Stephan
> >
> >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> >wrote:
> >
> >>Hi Stephan,
> >>
> >>This is a great start. I do not know if you volunteered to upd= ate as
> >>well as provide the initial version of this document. In any c= ase,
> here
> >>are some comments.
> >>
> >>> Endpoint - The logical point of final termination through=
> >>> receiving, decoding and rendering, and/or initiation thro= ugh
> >>> capturing, encoding, and sending of media streams. =A0An = endpoint
> >>> consists of one or more physical devices which source and= sink
> >>> media streams. =A0In contrast to an endpoint, a middle bo= x, such
> >>> as an MCU, may also send and receive media streams, but i= t is
> >>> not the initiator nor the final terminator.
> >>
> >>I am not sure we should differentiate between endpoint and MCU= . The
> >>distinction blurs in that an MCU generates and send media stre= ams
> that
> >>are not necessarily equivalent to those it received, and it re= ceives
> >>input from other endpoints. I think trying to distinguish them= simply
> >>makes more work and add complexity. I also think we will find = that
> the
> >>majority of "MCUs" are really more "endpoints&q= uot; than "MCUs".
> >>You introduced the concept of remote. I am proposing remote = =3D=3D
> endpoint
> >>and remove MCU.
> >
> >Not sure here.
> >What "endpoint" attempts to express is that it is the lo= gical entity
> >facing the user--the room including microphones loudspeakers, scre= ens,
> >cameras, and some technical stuff that sends and receives RTP stre= ams
> >and
> >implements signaling. =A0We need such a definition certainly in th= e
> >requirement spec but also in the use cases. =A0There is also a &qu= ot;local"
> >endpoint, which prohibits the use of "remote".
> >I think we should leave this definition alone.
> >
> >>
> >>> Media - Any data that, after suitable encoding, can be co= nveyed
> >>> over RTP, including audio, video or timed text.
> >>
> >>I think this is too general, but I am not able to suggest a go= od way
> to
> >>improve it.
> >
> >Again, not sure why this is too general.
> >
> >>
> >>> Session - RTP session. =A0An association among a set of > >>> participants communicating with RTP. =A0The distinguishin= g feature
> >>> of an RTP session is that each maintains a full, separate= space
> >>> of SSRC identifiers. =A0[RFC3550]
> >>
> >>In this case, do we also need a term for the collection of RTP=
> sessions
> >>the contains the complete set media exchanged between two endp= oints?
> >
> >Perhaps, though I don't think we have seen that need yet.
> >Pm the media plane, there is really no such thing as "bundlin= g" of
> media
> >transmission channels. =A0There is a logical connection between mu= ltiple
> >sessions, but only in the signaling.
> >
> >>
> >>
> >>"Layouts" vs. "Spatial Relations", what is= the difference?
> >
> >A Layout is the aggregation of all spatial relations of all
> >capture/renderer devices at a given point in time?
> >"Left speaker is left from right speaker" is a spatial r= elation.
> >"Left microphone is co-located with left camera" is a sp= atial
> relation.
> >"Audio channel 1 is left, audio channel 2 is right, and there= is only
> >one
> >center camera" is a layout.
> >
> >>
> >>Cheers,
> >>Charles
> >>
> >>
> >>> -----Original Message-----
> >>> From: clue-bounc= es@ietf.org [mailto:clue-bounc= es@ietf.org] On
> Behalf
> >>Of Stephan Wenger
> >>> Sent: Friday, May 13, 2011 11:08 AM
> >>> To: CLUE
> >>> Subject: [clue] Definitions
> >>>
> >>> Hi folks,
> >>> Here a VERY rough initial draft. =A0Addressing typos, sor= ting to
> >>alphabetical, and other cleanup tasks
> >>> will have to wait for the my return to the office next we= ek. =A0I
> will
> >>submit officially only after the
> >>> most embarrassing bugs are sorted out. =A0No need to comm= ent on
> typos,
> >>but if you have substantial
> >>> issues then send them now, and I can address them immedia= tely.
> >>> Stephan
> >>
> >
> >
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/clue
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
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

--bcaec547ca339dbedc04a39f0b22-- From aravind.sethuraman@teliris.com Thu May 19 04:25:12 2011 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 6BDF9E06AB for ; Thu, 19 May 2011 04:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX6UhqrfJOXq for ; Thu, 19 May 2011 04:25:11 -0700 (PDT) Received: from imta-38.everyone.net (sitemail2.everyone.net [216.200.145.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5922AE06A8 for ; Thu, 19 May 2011 04:25:11 -0700 (PDT) Received: from pps.filterd (m0004960 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p4JBNOQo031140; Thu, 19 May 2011 04:25:10 -0700 X-Eon-Dm: dm0201 Received: by dm0201.mta.everyone.net (EON-AUTHRELAY2 - 0c68eab3) id dm0201.4dc0dbb8.2414049; Thu, 19 May 2011 04:24:59 -0700 X-Eon-Sig: AQLO6zJN1P4LsdU4TgIAAAAE,9c3e9d9d2a62dd2faca9f1285ad1c913 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: aravind sethuraman In-Reply-To: Date: Thu, 19 May 2011 07:24:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E0B7CE8-354A-4A2F-B983-8CB7727A2A81@teliris.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> To: X-Mailer: Apple Mail (2.1084) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1105190048 Cc: clue@ietf.org Subject: Re: [clue] Definitions 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, 19 May 2011 11:25:12 -0000 why would an end point want to expose more than one SIP UA / or point of = entry? why would a subsystem of a room be in a part of a call if the entire = room is not a call we have multiple codecs and multiple control panels but there is a = single point of entry which behaves as a SIP UA.....the rest, within the = room can be proprietary or something else... but endpoint -endpoint interoperabilithy has to be as thought between = multi-media capture/decode capable SIP UAs ...... we cannot presume an end-point to have multiple SIP UAs..... my 2 cents... aravind On May 19, 2011, at 3:17 AM, = wrote: > Hi Mark, Stephan, >=20 > On my side, I think we should consider cases where we have several SIP = UAs in a single telepresence room.=20 >=20 > Another discussion is to define the relation between an endpoint and a = SIP UA. IMO, we should define an endpoint as composed of one single SIP = UA, and the endpoint represents all equipment associated to the SIP UA = (including multi-screen/camera). >=20 > Thus we should consider cases where a telepresence room is composed of = several endpoints. As I suggested in a previous mail, I think that such = cases will necessarily exist, with proprietary implementations (thus not = interoperable) in MCU to associate several endpoints so that they form a = single telepresence room. That's why we should consider these cases to = have interoperability rules. >=20 >=20 > Stephane.=20 >=20 > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de Duckworth, Mark > Envoy=E9 : mercredi 18 mai 2011 19:27 > =C0 : Stephan Wenger; clue@ietf.org > Objet : Re: [clue] Definitions >=20 > Stephan, >=20 > My understanding is an endpoint has a single SIP UA. And there would = be only one endpoint in a room. >=20 > Mark >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of >> Stephan Wenger >> Sent: Wednesday, May 18, 2011 2:00 AM >> To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; >> eckelcu@cisco.com; clue@ietf.org >> Subject: Re: [clue] Definitions >>=20 >> Hi Stephane, >> Very good point. >>=20 >> Quoting from RFC 4353 >>=20 >> [...] >> Participant: The software element that connects a user or = automata to >> a conference. It implements, at a minimum, a SIP user agent, = but >> may also implement non-SIP-specific mechanisms for additional >> functionality. >> [...] >>=20 >> My understanding of "endpoint" is that an endpoint encompasses ALL >> equipment in a telepresence room. I believe that there are cases = where we >> can have multiple SIP user agents (Uas) in one room. Think of a = bunch of >> codec boxes in a rack, all having their own UA. Is this the common >> understanding of the group? >>=20 >> To ask the question differently, do we have an agreement that there = is a >> single SIP UA in one room? >>=20 >> Guidance, please. >>=20 >> Thanks, >> Stephan >>=20 >>=20 >>=20 >>=20 >> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" >> wrote: >>=20 >>> I don't think that we want to limit the "endpoint" definition to >> entities >>> facing a user. We could have entities not facing a user (e.g. an >>> automata), but which are sending/receiving media, and which need to >>> understand characteristics of the remote, and could maybe have also >> some >>> characteristics. I don't think we want to exclude such cases. >>>=20 >>> Relying on the "participant" definition of RFC4353, a telepresence >>> conference will be composed of "participants", where a participant = is >>> connected to the conference through an "endpoint". In telepresence, >> the >>> participant will have to be aware of the endpoint, in particular = when >> the >>> participant needs to inform the remote of the characteristics of its >>> endpoint. >>>=20 >>> Thus my proposition is to clarify that "endpoint" defines the entity >>> through which a participant (we do not limit to entity facing a = user) >> is >>> connected to a telepresence conference. >>>=20 >>> In the same manner, we could also use the "mixer" word instead of >> "MCU". >>>=20 >>> Most of requirements should then apply on the participant or mixer >>> (typically, a participant will describe characteristics of its >> endpoint). >>>=20 >>>=20 >>> Regards, >>> Stephane. >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part >> de >>> Espen Berger (espeberg) >>> Envoy=E9 : mercredi 18 mai 2011 10:40 >>> =C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE >>> Objet : Re: [clue] Definitions >>>=20 >>> I think we should keep both endpoints and MCUs in the definition >>> document. >>>=20 >>> One difference between endpoints and MCUs are how they handle media. >> An >>> endpoint usually send media representing itself and MCUs send media = on >>> behalf of others remote endpoint connected. >>>=20 >>> Cheers >>>=20 >>> -Espen >>>=20 >>>=20 >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Stephan Wenger >>> Sent: 17. mai 2011 06:17 >>> To: Charles Eckel (eckelcu); CLUE >>> Subject: Re: [clue] Definitions >>>=20 >>> Hi Charles, >>> Please see inline. >>> In summary, I'm not convinced there is need for a change, though = there >>> may >>> be need for more explanatory text. >>> Stephan >>>=20 >>> On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" >>> wrote: >>>=20 >>>> Hi Stephan, >>>>=20 >>>> This is a great start. I do not know if you volunteered to update = as >>>> well as provide the initial version of this document. In any case, >> here >>>> are some comments. >>>>=20 >>>>> Endpoint - The logical point of final termination through >>>>> receiving, decoding and rendering, and/or initiation through >>>>> capturing, encoding, and sending of media streams. An endpoint >>>>> consists of one or more physical devices which source and sink >>>>> media streams. In contrast to an endpoint, a middle box, such >>>>> as an MCU, may also send and receive media streams, but it is >>>>> not the initiator nor the final terminator. >>>>=20 >>>> I am not sure we should differentiate between endpoint and MCU. The >>>> distinction blurs in that an MCU generates and send media streams >> that >>>> are not necessarily equivalent to those it received, and it = receives >>>> input from other endpoints. I think trying to distinguish them = simply >>>> makes more work and add complexity. I also think we will find that >> the >>>> majority of "MCUs" are really more "endpoints" than "MCUs". >>>> You introduced the concept of remote. I am proposing remote =3D=3D >> endpoint >>>> and remove MCU. >>>=20 >>> Not sure here. >>> What "endpoint" attempts to express is that it is the logical entity >>> facing the user--the room including microphones loudspeakers, = screens, >>> cameras, and some technical stuff that sends and receives RTP = streams >>> and >>> implements signaling. We need such a definition certainly in the >>> requirement spec but also in the use cases. There is also a "local" >>> endpoint, which prohibits the use of "remote". >>> I think we should leave this definition alone. >>>=20 >>>>=20 >>>>> Media - Any data that, after suitable encoding, can be conveyed >>>>> over RTP, including audio, video or timed text. >>>>=20 >>>> I think this is too general, but I am not able to suggest a good = way >> to >>>> improve it. >>>=20 >>> Again, not sure why this is too general. >>>=20 >>>>=20 >>>>> Session - RTP session. An association among a set of >>>>> participants communicating with RTP. The distinguishing feature >>>>> of an RTP session is that each maintains a full, separate space >>>>> of SSRC identifiers. [RFC3550] >>>>=20 >>>> In this case, do we also need a term for the collection of RTP >> sessions >>>> the contains the complete set media exchanged between two = endpoints? >>>=20 >>> Perhaps, though I don't think we have seen that need yet. >>> Pm the media plane, there is really no such thing as "bundling" of >> media >>> transmission channels. There is a logical connection between = multiple >>> sessions, but only in the signaling. >>>=20 >>>>=20 >>>>=20 >>>> "Layouts" vs. "Spatial Relations", what is the difference? >>>=20 >>> A Layout is the aggregation of all spatial relations of all >>> capture/renderer devices at a given point in time? >>> "Left speaker is left from right speaker" is a spatial relation. >>> "Left microphone is co-located with left camera" is a spatial >> relation. >>> "Audio channel 1 is left, audio channel 2 is right, and there is = only >>> one >>> center camera" is a layout. >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of Stephan Wenger >>>>> Sent: Friday, May 13, 2011 11:08 AM >>>>> To: CLUE >>>>> Subject: [clue] Definitions >>>>>=20 >>>>> Hi folks, >>>>> Here a VERY rough initial draft. Addressing typos, sorting to >>>> alphabetical, and other cleanup tasks >>>>> will have to wait for the my return to the office next week. I >> will >>>> submit officially only after the >>>>> most embarrassing bugs are sorted out. No need to comment on >> typos, >>>> but if you have substantial >>>>> issues then send them now, and I can address them immediately. >>>>> Stephan >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >> _______________________________________________ >> 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 Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman From christer.holmberg@ericsson.com Thu May 19 05:04:04 2011 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 90E32E06A8 for ; Thu, 19 May 2011 05:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 d5-xzAWUHurA for ; Thu, 19 May 2011 05:04:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 04208E06B6 for ; Thu, 19 May 2011 05:04:02 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-81-4dd507314d8b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 60.83.20773.13705DD4; Thu, 19 May 2011 14:04:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 19 May 2011 14:04:01 +0200 From: Christer Holmberg To: 'aravind sethuraman' , "stephane.cazeaux@orange-ftgroup.com" Date: Thu, 19 May 2011 14:04:02 +0200 Thread-Topic: [clue] Definitions Thread-Index: AcwWF216a3McYGkjRh+C9yTBJzwW2AABMAHw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84C@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> <8E0B7CE8-354A-4A2F-B983-8CB7727A2A81@teliris.com> In-Reply-To: <8E0B7CE8-354A-4A2F-B983-8CB7727A2A81@teliris.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: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Definitions 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, 19 May 2011 12:04:04 -0000 Hi, I would allow multiple SIP UAs to represent a room, we would have to deal w= ith issues on how to correlate multiple SIP sessions, and how to related me= dia streams within them, associated with that room, which could become very= complicated. In addition, it would make interoperability - not only between CLUE- and le= gacy endpoints, but also between CLUE endpoints represented by a different = number of SIP UAs. So, I wuold really recommend to not go that way. I think we will have enoug= h issues to solve even without it :) OF COURSE, one can have multiple SIP UAs in a PHYSICAL room. But, in that c= ase each SIP UA would represent a separate telepresence room, and would be = seen and treated as different endpoints. Regards, Christer =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of ara= vind sethuraman Sent: 19. toukokuuta 2011 14:25 To: stephane.cazeaux@orange-ftgroup.com Cc: clue@ietf.org Subject: Re: [clue] Definitions why would an end point want to expose more than one SIP UA / or point of en= try? why would a subsystem of a room be in a part of a call if the entire room i= s not a call we have multiple codecs and multiple control panels but there is a single p= oint of entry which behaves as a SIP UA.....the rest, within the room can b= e proprietary or something else... but endpoint -endpoint interoperabilithy has to be as thought between multi= -media capture/decode capable SIP UAs ...... we cannot presume an end-point to have multiple SIP UAs..... my 2 cents... aravind On May 19, 2011, at 3:17 AM, wrote: > Hi Mark, Stephan, >=20 > On my side, I think we should consider cases where we have several SIP UA= s in a single telepresence room.=20 >=20 > Another discussion is to define the relation between an endpoint and a SI= P UA. IMO, we should define an endpoint as composed of one single SIP UA, a= nd the endpoint represents all equipment associated to the SIP UA (includin= g multi-screen/camera). >=20 > Thus we should consider cases where a telepresence room is composed of se= veral endpoints. As I suggested in a previous mail, I think that such cases= will necessarily exist, with proprietary implementations (thus not interop= erable) in MCU to associate several endpoints so that they form a single te= lepresence room. That's why we should consider these cases to have interope= rability rules. >=20 >=20 > Stephane.=20 >=20 > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part=20 > de Duckworth, Mark Envoy=E9 : mercredi 18 mai 2011 19:27 =C0 : Stephan=20 > Wenger; clue@ietf.org Objet : Re: [clue] Definitions >=20 > Stephan, >=20 > My understanding is an endpoint has a single SIP UA. And there would be = only one endpoint in a room. >=20 > Mark >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Stephan Wenger >> Sent: Wednesday, May 18, 2011 2:00 AM >> To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com;=20 >> eckelcu@cisco.com; clue@ietf.org >> Subject: Re: [clue] Definitions >>=20 >> Hi Stephane, >> Very good point. >>=20 >> Quoting from RFC 4353 >>=20 >> [...] >> Participant: The software element that connects a user or automat= a to >> a conference. It implements, at a minimum, a SIP user agent, but >> may also implement non-SIP-specific mechanisms for additional >> functionality. >> [...] >>=20 >> My understanding of "endpoint" is that an endpoint encompasses ALL=20 >> equipment in a telepresence room. I believe that there are cases=20 >> where we can have multiple SIP user agents (Uas) in one room. Think=20 >> of a bunch of codec boxes in a rack, all having their own UA. Is=20 >> this the common understanding of the group? >>=20 >> To ask the question differently, do we have an agreement that there=20 >> is a single SIP UA in one room? >>=20 >> Guidance, please. >>=20 >> Thanks, >> Stephan >>=20 >>=20 >>=20 >>=20 >> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" >> wrote: >>=20 >>> I don't think that we want to limit the "endpoint" definition to >> entities >>> facing a user. We could have entities not facing a user (e.g. an=20 >>> automata), but which are sending/receiving media, and which need to=20 >>> understand characteristics of the remote, and could maybe have also >> some >>> characteristics. I don't think we want to exclude such cases. >>>=20 >>> Relying on the "participant" definition of RFC4353, a telepresence=20 >>> conference will be composed of "participants", where a participant=20 >>> is connected to the conference through an "endpoint". In=20 >>> telepresence, >> the >>> participant will have to be aware of the endpoint, in particular=20 >>> when >> the >>> participant needs to inform the remote of the characteristics of its=20 >>> endpoint. >>>=20 >>> Thus my proposition is to clarify that "endpoint" defines the entity=20 >>> through which a participant (we do not limit to entity facing a=20 >>> user) >> is >>> connected to a telepresence conference. >>>=20 >>> In the same manner, we could also use the "mixer" word instead of >> "MCU". >>>=20 >>> Most of requirements should then apply on the participant or mixer=20 >>> (typically, a participant will describe characteristics of its >> endpoint). >>>=20 >>>=20 >>> Regards, >>> Stephane. >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part >> de >>> Espen Berger (espeberg) >>> Envoy=E9 : mercredi 18 mai 2011 10:40 >>> =C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE Objet : Re: [clue]= =20 >>> Definitions >>>=20 >>> I think we should keep both endpoints and MCUs in the definition=20 >>> document. >>>=20 >>> One difference between endpoints and MCUs are how they handle media. >> An >>> endpoint usually send media representing itself and MCUs send media=20 >>> on behalf of others remote endpoint connected. >>>=20 >>> Cheers >>>=20 >>> -Espen >>>=20 >>>=20 >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Stephan Wenger >>> Sent: 17. mai 2011 06:17 >>> To: Charles Eckel (eckelcu); CLUE >>> Subject: Re: [clue] Definitions >>>=20 >>> Hi Charles, >>> Please see inline. >>> In summary, I'm not convinced there is need for a change, though=20 >>> there may be need for more explanatory text. >>> Stephan >>>=20 >>> On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" >>> wrote: >>>=20 >>>> Hi Stephan, >>>>=20 >>>> This is a great start. I do not know if you volunteered to update=20 >>>> as well as provide the initial version of this document. In any=20 >>>> case, >> here >>>> are some comments. >>>>=20 >>>>> Endpoint - The logical point of final termination through=20 >>>>> receiving, decoding and rendering, and/or initiation through=20 >>>>> capturing, encoding, and sending of media streams. An endpoint=20 >>>>> consists of one or more physical devices which source and sink=20 >>>>> media streams. In contrast to an endpoint, a middle box, such as=20 >>>>> an MCU, may also send and receive media streams, but it is not the=20 >>>>> initiator nor the final terminator. >>>>=20 >>>> I am not sure we should differentiate between endpoint and MCU. The=20 >>>> distinction blurs in that an MCU generates and send media streams >> that >>>> are not necessarily equivalent to those it received, and it=20 >>>> receives input from other endpoints. I think trying to distinguish=20 >>>> them simply makes more work and add complexity. I also think we=20 >>>> will find that >> the >>>> majority of "MCUs" are really more "endpoints" than "MCUs". >>>> You introduced the concept of remote. I am proposing remote =3D=3D >> endpoint >>>> and remove MCU. >>>=20 >>> Not sure here. >>> What "endpoint" attempts to express is that it is the logical entity=20 >>> facing the user--the room including microphones loudspeakers,=20 >>> screens, cameras, and some technical stuff that sends and receives=20 >>> RTP streams and implements signaling. We need such a definition=20 >>> certainly in the requirement spec but also in the use cases. There=20 >>> is also a "local" >>> endpoint, which prohibits the use of "remote". >>> I think we should leave this definition alone. >>>=20 >>>>=20 >>>>> Media - Any data that, after suitable encoding, can be conveyed=20 >>>>> over RTP, including audio, video or timed text. >>>>=20 >>>> I think this is too general, but I am not able to suggest a good=20 >>>> way >> to >>>> improve it. >>>=20 >>> Again, not sure why this is too general. >>>=20 >>>>=20 >>>>> Session - RTP session. An association among a set of participants=20 >>>>> communicating with RTP. The distinguishing feature of an RTP=20 >>>>> session is that each maintains a full, separate space of SSRC=20 >>>>> identifiers. [RFC3550] >>>>=20 >>>> In this case, do we also need a term for the collection of RTP >> sessions >>>> the contains the complete set media exchanged between two endpoints? >>>=20 >>> Perhaps, though I don't think we have seen that need yet. >>> Pm the media plane, there is really no such thing as "bundling" of >> media >>> transmission channels. There is a logical connection between=20 >>> multiple sessions, but only in the signaling. >>>=20 >>>>=20 >>>>=20 >>>> "Layouts" vs. "Spatial Relations", what is the difference? >>>=20 >>> A Layout is the aggregation of all spatial relations of all=20 >>> capture/renderer devices at a given point in time? >>> "Left speaker is left from right speaker" is a spatial relation. >>> "Left microphone is co-located with left camera" is a spatial >> relation. >>> "Audio channel 1 is left, audio channel 2 is right, and there is=20 >>> only one center camera" is a layout. >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of Stephan Wenger >>>>> Sent: Friday, May 13, 2011 11:08 AM >>>>> To: CLUE >>>>> Subject: [clue] Definitions >>>>>=20 >>>>> Hi folks, >>>>> Here a VERY rough initial draft. Addressing typos, sorting to >>>> alphabetical, and other cleanup tasks >>>>> will have to wait for the my return to the office next week. I >> will >>>> submit officially only after the >>>>> most embarrassing bugs are sorted out. No need to comment on >> typos, >>>> but if you have substantial >>>>> issues then send them now, and I can address them immediately. >>>>> Stephan >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >> _______________________________________________ >> 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 Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.= 0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu May 19 05:05:33 2011 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 DAA78E07AB for ; Thu, 19 May 2011 05:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 i56zw1gpGTnO for ; Thu, 19 May 2011 05:05:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 29E53E06B6 for ; Thu, 19 May 2011 05:05:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f6-4dd5078b1122 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.B3.20773.B8705DD4; Thu, 19 May 2011 14:05:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 19 May 2011 14:05:30 +0200 From: Christer Holmberg To: Christer Holmberg , 'aravind sethuraman' , "stephane.cazeaux@orange-ftgroup.com" Date: Thu, 19 May 2011 14:05:30 +0200 Thread-Topic: [clue] Definitions Thread-Index: AcwWF216a3McYGkjRh+C9yTBJzwW2AABMAHwAAAwr0A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84D@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> <8E0B7CE8-354A-4A2F-B983-8CB7727A2A81@teliris.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Definitions 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, 19 May 2011 12:05:34 -0000 "If we would allow multiple SIP UAs to represent a room", that is :) Sorry for the mess. Regards, Christer=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: 19. toukokuuta 2011 15:04 To: 'aravind sethuraman'; stephane.cazeaux@orange-ftgroup.com Cc: clue@ietf.org Subject: Re: [clue] Definitions Hi, I would allow multiple SIP UAs to represent a room, we would have to deal w= ith issues on how to correlate multiple SIP sessions, and how to related me= dia streams within them, associated with that room, which could become very= complicated. In addition, it would make interoperability - not only between CLUE- and le= gacy endpoints, but also between CLUE endpoints represented by a different = number of SIP UAs. So, I wuold really recommend to not go that way. I think we will have enoug= h issues to solve even without it :) OF COURSE, one can have multiple SIP UAs in a PHYSICAL room. But, in that c= ase each SIP UA would represent a separate telepresence room, and would be = seen and treated as different endpoints. Regards, Christer =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of ara= vind sethuraman Sent: 19. toukokuuta 2011 14:25 To: stephane.cazeaux@orange-ftgroup.com Cc: clue@ietf.org Subject: Re: [clue] Definitions why would an end point want to expose more than one SIP UA / or point of en= try? why would a subsystem of a room be in a part of a call if the entire room i= s not a call we have multiple codecs and multiple control panels but there is a single p= oint of entry which behaves as a SIP UA.....the rest, within the room can b= e proprietary or something else... but endpoint -endpoint interoperabilithy has to be as thought between multi= -media capture/decode capable SIP UAs ...... we cannot presume an end-point to have multiple SIP UAs..... my 2 cents... aravind On May 19, 2011, at 3:17 AM, wrote: > Hi Mark, Stephan, >=20 > On my side, I think we should consider cases where we have several SIP UA= s in a single telepresence room.=20 >=20 > Another discussion is to define the relation between an endpoint and a SI= P UA. IMO, we should define an endpoint as composed of one single SIP UA, a= nd the endpoint represents all equipment associated to the SIP UA (includin= g multi-screen/camera). >=20 > Thus we should consider cases where a telepresence room is composed of se= veral endpoints. As I suggested in a previous mail, I think that such cases= will necessarily exist, with proprietary implementations (thus not interop= erable) in MCU to associate several endpoints so that they form a single te= lepresence room. That's why we should consider these cases to have interope= rability rules. >=20 >=20 > Stephane.=20 >=20 > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part=20 > de Duckworth, Mark Envoy=E9 : mercredi 18 mai 2011 19:27 =C0 : Stephan=20 > Wenger; clue@ietf.org Objet : Re: [clue] Definitions >=20 > Stephan, >=20 > My understanding is an endpoint has a single SIP UA. And there would be = only one endpoint in a room. >=20 > Mark >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Stephan Wenger >> Sent: Wednesday, May 18, 2011 2:00 AM >> To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com;=20 >> eckelcu@cisco.com; clue@ietf.org >> Subject: Re: [clue] Definitions >>=20 >> Hi Stephane, >> Very good point. >>=20 >> Quoting from RFC 4353 >>=20 >> [...] >> Participant: The software element that connects a user or automat= a to >> a conference. It implements, at a minimum, a SIP user agent, but >> may also implement non-SIP-specific mechanisms for additional >> functionality. >> [...] >>=20 >> My understanding of "endpoint" is that an endpoint encompasses ALL=20 >> equipment in a telepresence room. I believe that there are cases=20 >> where we can have multiple SIP user agents (Uas) in one room. Think=20 >> of a bunch of codec boxes in a rack, all having their own UA. Is=20 >> this the common understanding of the group? >>=20 >> To ask the question differently, do we have an agreement that there=20 >> is a single SIP UA in one room? >>=20 >> Guidance, please. >>=20 >> Thanks, >> Stephan >>=20 >>=20 >>=20 >>=20 >> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" >> wrote: >>=20 >>> I don't think that we want to limit the "endpoint" definition to >> entities >>> facing a user. We could have entities not facing a user (e.g. an=20 >>> automata), but which are sending/receiving media, and which need to=20 >>> understand characteristics of the remote, and could maybe have also >> some >>> characteristics. I don't think we want to exclude such cases. >>>=20 >>> Relying on the "participant" definition of RFC4353, a telepresence=20 >>> conference will be composed of "participants", where a participant=20 >>> is connected to the conference through an "endpoint". In=20 >>> telepresence, >> the >>> participant will have to be aware of the endpoint, in particular=20 >>> when >> the >>> participant needs to inform the remote of the characteristics of its=20 >>> endpoint. >>>=20 >>> Thus my proposition is to clarify that "endpoint" defines the entity=20 >>> through which a participant (we do not limit to entity facing a >>> user) >> is >>> connected to a telepresence conference. >>>=20 >>> In the same manner, we could also use the "mixer" word instead of >> "MCU". >>>=20 >>> Most of requirements should then apply on the participant or mixer=20 >>> (typically, a participant will describe characteristics of its >> endpoint). >>>=20 >>>=20 >>> Regards, >>> Stephane. >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part >> de >>> Espen Berger (espeberg) >>> Envoy=E9 : mercredi 18 mai 2011 10:40 >>> =C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE Objet : Re: [clue]= =20 >>> Definitions >>>=20 >>> I think we should keep both endpoints and MCUs in the definition=20 >>> document. >>>=20 >>> One difference between endpoints and MCUs are how they handle media. >> An >>> endpoint usually send media representing itself and MCUs send media=20 >>> on behalf of others remote endpoint connected. >>>=20 >>> Cheers >>>=20 >>> -Espen >>>=20 >>>=20 >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Stephan Wenger >>> Sent: 17. mai 2011 06:17 >>> To: Charles Eckel (eckelcu); CLUE >>> Subject: Re: [clue] Definitions >>>=20 >>> Hi Charles, >>> Please see inline. >>> In summary, I'm not convinced there is need for a change, though=20 >>> there may be need for more explanatory text. >>> Stephan >>>=20 >>> On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" >>> wrote: >>>=20 >>>> Hi Stephan, >>>>=20 >>>> This is a great start. I do not know if you volunteered to update=20 >>>> as well as provide the initial version of this document. In any=20 >>>> case, >> here >>>> are some comments. >>>>=20 >>>>> Endpoint - The logical point of final termination through=20 >>>>> receiving, decoding and rendering, and/or initiation through=20 >>>>> capturing, encoding, and sending of media streams. An endpoint=20 >>>>> consists of one or more physical devices which source and sink=20 >>>>> media streams. In contrast to an endpoint, a middle box, such as=20 >>>>> an MCU, may also send and receive media streams, but it is not the=20 >>>>> initiator nor the final terminator. >>>>=20 >>>> I am not sure we should differentiate between endpoint and MCU. The=20 >>>> distinction blurs in that an MCU generates and send media streams >> that >>>> are not necessarily equivalent to those it received, and it=20 >>>> receives input from other endpoints. I think trying to distinguish=20 >>>> them simply makes more work and add complexity. I also think we=20 >>>> will find that >> the >>>> majority of "MCUs" are really more "endpoints" than "MCUs". >>>> You introduced the concept of remote. I am proposing remote =3D=3D >> endpoint >>>> and remove MCU. >>>=20 >>> Not sure here. >>> What "endpoint" attempts to express is that it is the logical entity=20 >>> facing the user--the room including microphones loudspeakers,=20 >>> screens, cameras, and some technical stuff that sends and receives=20 >>> RTP streams and implements signaling. We need such a definition=20 >>> certainly in the requirement spec but also in the use cases. There=20 >>> is also a "local" >>> endpoint, which prohibits the use of "remote". >>> I think we should leave this definition alone. >>>=20 >>>>=20 >>>>> Media - Any data that, after suitable encoding, can be conveyed=20 >>>>> over RTP, including audio, video or timed text. >>>>=20 >>>> I think this is too general, but I am not able to suggest a good=20 >>>> way >> to >>>> improve it. >>>=20 >>> Again, not sure why this is too general. >>>=20 >>>>=20 >>>>> Session - RTP session. An association among a set of participants=20 >>>>> communicating with RTP. The distinguishing feature of an RTP=20 >>>>> session is that each maintains a full, separate space of SSRC=20 >>>>> identifiers. [RFC3550] >>>>=20 >>>> In this case, do we also need a term for the collection of RTP >> sessions >>>> the contains the complete set media exchanged between two endpoints? >>>=20 >>> Perhaps, though I don't think we have seen that need yet. >>> Pm the media plane, there is really no such thing as "bundling" of >> media >>> transmission channels. There is a logical connection between=20 >>> multiple sessions, but only in the signaling. >>>=20 >>>>=20 >>>>=20 >>>> "Layouts" vs. "Spatial Relations", what is the difference? >>>=20 >>> A Layout is the aggregation of all spatial relations of all=20 >>> capture/renderer devices at a given point in time? >>> "Left speaker is left from right speaker" is a spatial relation. >>> "Left microphone is co-located with left camera" is a spatial >> relation. >>> "Audio channel 1 is left, audio channel 2 is right, and there is=20 >>> only one center camera" is a layout. >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of Stephan Wenger >>>>> Sent: Friday, May 13, 2011 11:08 AM >>>>> To: CLUE >>>>> Subject: [clue] Definitions >>>>>=20 >>>>> Hi folks, >>>>> Here a VERY rough initial draft. Addressing typos, sorting to >>>> alphabetical, and other cleanup tasks >>>>> will have to wait for the my return to the office next week. I >> will >>>> submit officially only after the >>>>> most embarrassing bugs are sorted out. No need to comment on >> typos, >>>> but if you have substantial >>>>> issues then send them now, and I can address them immediately. >>>>> Stephan >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >> _______________________________________________ >> 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 Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.= 0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Thu May 19 06:49:14 2011 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 E529EE0656 for ; Thu, 19 May 2011 06:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 oezIbOBHciDq for ; Thu, 19 May 2011 06:49:13 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id EF079E06D9 for ; Thu, 19 May 2011 06:49:10 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2727-1743317 for multiple; Thu, 19 May 2011 15:49:08 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 19 May 2011 06:48:54 +0200 From: Stephan Wenger To: Christer Holmberg , 'aravind sethuraman' , "stephane.cazeaux@orange-ftgroup.com" Message-ID: Thread-Topic: [clue] Definitions In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84D@ESESSCMS0356.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: "clue@ietf.org" Subject: Re: [clue] Definitions 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, 19 May 2011 13:49:15 -0000 To summarize this very useful discussion, I believe the definitions should reflect (only) the case where a single SIP UA represents a "room" at a given time. "Room" being anything from a multi-codec telepresence studio sold for hundreds of thousands down to the screen of a mobile device. If there were cases where we choose to divert from this assumption, the related definition(s) would simply not be used. I'm going to produce and upload the -00 draft today, reflecting the outcome of the discussions as well as I can. Stephan =20 On 5.19.2011 14:05 , "Christer Holmberg" wrote: > >"If we would allow multiple SIP UAs to represent a room", that is :) > >Sorry for the mess. > >Regards, > >Christer=20 > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Christer Holmberg >Sent: 19. toukokuuta 2011 15:04 >To: 'aravind sethuraman'; stephane.cazeaux@orange-ftgroup.com >Cc: clue@ietf.org >Subject: Re: [clue] Definitions > > >Hi, > >I would allow multiple SIP UAs to represent a room, we would have to deal >with issues on how to correlate multiple SIP sessions, and how to related >media streams within them, associated with that room, which could become >very complicated. > >In addition, it would make interoperability - not only between CLUE- and >legacy endpoints, but also between CLUE endpoints represented by a >different number of SIP UAs. > >So, I wuold really recommend to not go that way. I think we will have >enough issues to solve even without it :) > >OF COURSE, one can have multiple SIP UAs in a PHYSICAL room. But, in that >case each SIP UA would represent a separate telepresence room, and would >be seen and treated as different endpoints. > >Regards, > >Christer > > >=20 > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >aravind sethuraman >Sent: 19. toukokuuta 2011 14:25 >To: stephane.cazeaux@orange-ftgroup.com >Cc: clue@ietf.org >Subject: Re: [clue] Definitions > >why would an end point want to expose more than one SIP UA / or point of >entry? >why would a subsystem of a room be in a part of a call if the entire room >is not a call > >we have multiple codecs and multiple control panels but there is a single >point of entry which behaves as a SIP UA.....the rest, within the room >can be proprietary or something else... >but endpoint -endpoint interoperabilithy has to be as thought between >multi-media capture/decode capable SIP UAs ...... >we cannot presume an end-point to have multiple SIP UAs..... > >my 2 cents... > >aravind > > >On May 19, 2011, at 3:17 AM, wrote: > >> Hi Mark, Stephan, >>=20 >> On my side, I think we should consider cases where we have several SIP >>UAs in a single telepresence room. >>=20 >> Another discussion is to define the relation between an endpoint and a >>SIP UA. IMO, we should define an endpoint as composed of one single SIP >>UA, and the endpoint represents all equipment associated to the SIP UA >>(including multi-screen/camera). >>=20 >> Thus we should consider cases where a telepresence room is composed of >>several endpoints. As I suggested in a previous mail, I think that such >>cases will necessarily exist, with proprietary implementations (thus not >>interoperable) in MCU to associate several endpoints so that they form a >>single telepresence room. That's why we should consider these cases to >>have interoperability rules. >>=20 >>=20 >> Stephane.=20 >>=20 >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part >> de Duckworth, Mark Envoy=E9 : mercredi 18 mai 2011 19:27 =C0 : Stephan >> Wenger; clue@ietf.org Objet : Re: [clue] Definitions >>=20 >> Stephan, >>=20 >> My understanding is an endpoint has a single SIP UA. And there would >>be only one endpoint in a room. >>=20 >> Mark >>=20 >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Stephan Wenger >>> Sent: Wednesday, May 18, 2011 2:00 AM >>> To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; >>> eckelcu@cisco.com; clue@ietf.org >>> Subject: Re: [clue] Definitions >>>=20 >>> Hi Stephane, >>> Very good point. >>>=20 >>> Quoting from RFC 4353 >>>=20 >>> [...] >>> Participant: The software element that connects a user or >>>automata to >>> a conference. It implements, at a minimum, a SIP user agent, >>>but >>> may also implement non-SIP-specific mechanisms for additional >>> functionality. >>> [...] >>>=20 >>> My understanding of "endpoint" is that an endpoint encompasses ALL >>> equipment in a telepresence room. I believe that there are cases >>> where we can have multiple SIP user agents (Uas) in one room. Think >>> of a bunch of codec boxes in a rack, all having their own UA. Is >>> this the common understanding of the group? >>>=20 >>> To ask the question differently, do we have an agreement that there >>> is a single SIP UA in one room? >>>=20 >>> Guidance, please. >>>=20 >>> Thanks, >>> Stephan >>>=20 >>>=20 >>>=20 >>>=20 >>> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" >>> wrote: >>>=20 >>>> I don't think that we want to limit the "endpoint" definition to >>> entities >>>> facing a user. We could have entities not facing a user (e.g. an >>>> automata), but which are sending/receiving media, and which need to >>>> understand characteristics of the remote, and could maybe have also >>> some >>>> characteristics. I don't think we want to exclude such cases. >>>>=20 >>>> Relying on the "participant" definition of RFC4353, a telepresence >>>> conference will be composed of "participants", where a participant >>>> is connected to the conference through an "endpoint". In >>>> telepresence, >>> the >>>> participant will have to be aware of the endpoint, in particular >>>> when >>> the >>>> participant needs to inform the remote of the characteristics of its >>>> endpoint. >>>>=20 >>>> Thus my proposition is to clarify that "endpoint" defines the entity >>>> through which a participant (we do not limit to entity facing a >>>> user) >>> is >>>> connected to a telepresence conference. >>>>=20 >>>> In the same manner, we could also use the "mixer" word instead of >>> "MCU". >>>>=20 >>>> Most of requirements should then apply on the participant or mixer >>>> (typically, a participant will describe characteristics of its >>> endpoint). >>>>=20 >>>>=20 >>>> Regards, >>>> Stephane. >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part >>> de >>>> Espen Berger (espeberg) >>>> Envoy=E9 : mercredi 18 mai 2011 10:40 >>>> =C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE Objet : Re: [clue] >>>> Definitions >>>>=20 >>>> I think we should keep both endpoints and MCUs in the definition >>>> document. >>>>=20 >>>> One difference between endpoints and MCUs are how they handle media. >>> An >>>> endpoint usually send media representing itself and MCUs send media >>>> on behalf of others remote endpoint connected. >>>>=20 >>>> Cheers >>>>=20 >>>> -Espen >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>> Stephan Wenger >>>> Sent: 17. mai 2011 06:17 >>>> To: Charles Eckel (eckelcu); CLUE >>>> Subject: Re: [clue] Definitions >>>>=20 >>>> Hi Charles, >>>> Please see inline. >>>> In summary, I'm not convinced there is need for a change, though >>>> there may be need for more explanatory text. >>>> Stephan >>>>=20 >>>> On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" >>>> wrote: >>>>=20 >>>>> Hi Stephan, >>>>>=20 >>>>> This is a great start. I do not know if you volunteered to update >>>>> as well as provide the initial version of this document. In any >>>>> case, >>> here >>>>> are some comments. >>>>>=20 >>>>>> Endpoint - The logical point of final termination through >>>>>> receiving, decoding and rendering, and/or initiation through >>>>>> capturing, encoding, and sending of media streams. An endpoint >>>>>> consists of one or more physical devices which source and sink >>>>>> media streams. In contrast to an endpoint, a middle box, such as >>>>>> an MCU, may also send and receive media streams, but it is not the >>>>>> initiator nor the final terminator. >>>>>=20 >>>>> I am not sure we should differentiate between endpoint and MCU. The >>>>> distinction blurs in that an MCU generates and send media streams >>> that >>>>> are not necessarily equivalent to those it received, and it >>>>> receives input from other endpoints. I think trying to distinguish >>>>> them simply makes more work and add complexity. I also think we >>>>> will find that >>> the >>>>> majority of "MCUs" are really more "endpoints" than "MCUs". >>>>> You introduced the concept of remote. I am proposing remote =3D=3D >>> endpoint >>>>> and remove MCU. >>>>=20 >>>> Not sure here. >>>> What "endpoint" attempts to express is that it is the logical entity >>>> facing the user--the room including microphones loudspeakers, >>>> screens, cameras, and some technical stuff that sends and receives >>>> RTP streams and implements signaling. We need such a definition >>>> certainly in the requirement spec but also in the use cases. There >>>> is also a "local" >>>> endpoint, which prohibits the use of "remote". >>>> I think we should leave this definition alone. >>>>=20 >>>>>=20 >>>>>> Media - Any data that, after suitable encoding, can be conveyed >>>>>> over RTP, including audio, video or timed text. >>>>>=20 >>>>> I think this is too general, but I am not able to suggest a good >>>>> way >>> to >>>>> improve it. >>>>=20 >>>> Again, not sure why this is too general. >>>>=20 >>>>>=20 >>>>>> Session - RTP session. An association among a set of participants >>>>>> communicating with RTP. The distinguishing feature of an RTP >>>>>> session is that each maintains a full, separate space of SSRC >>>>>> identifiers. [RFC3550] >>>>>=20 >>>>> In this case, do we also need a term for the collection of RTP >>> sessions >>>>> the contains the complete set media exchanged between two endpoints? >>>>=20 >>>> Perhaps, though I don't think we have seen that need yet. >>>> Pm the media plane, there is really no such thing as "bundling" of >>> media >>>> transmission channels. There is a logical connection between >>>> multiple sessions, but only in the signaling. >>>>=20 >>>>>=20 >>>>>=20 >>>>> "Layouts" vs. "Spatial Relations", what is the difference? >>>>=20 >>>> A Layout is the aggregation of all spatial relations of all >>>> capture/renderer devices at a given point in time? >>>> "Left speaker is left from right speaker" is a spatial relation. >>>> "Left microphone is co-located with left camera" is a spatial >>> relation. >>>> "Audio channel 1 is left, audio channel 2 is right, and there is >>>> only one center camera" is a layout. >>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Charles >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf >>>>> Of Stephan Wenger >>>>>> Sent: Friday, May 13, 2011 11:08 AM >>>>>> To: CLUE >>>>>> Subject: [clue] Definitions >>>>>>=20 >>>>>> Hi folks, >>>>>> Here a VERY rough initial draft. Addressing typos, sorting to >>>>> alphabetical, and other cleanup tasks >>>>>> will have to wait for the my return to the office next week. I >>> will >>>>> submit officially only after the >>>>>> most embarrassing bugs are sorted out. No need to comment on >>> typos, >>>>> but if you have substantial >>>>>> issues then send them now, and I can address them immediately. >>>>>> Stephan >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>>=20 >>> _______________________________________________ >>> 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 > >Aravind Sethuraman >Software Architect >Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C >+1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM >aravindsraman > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From hmmr@cisco.com Thu May 19 06:51:45 2011 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 5F067E07B0 for ; Thu, 19 May 2011 06:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.649 X-Spam-Level: X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 hcgRXncBh23c for ; Thu, 19 May 2011 06:51:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 037FDE06D9 for ; Thu, 19 May 2011 06:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=9777; q=dns/txt; s=iport; t=1305813100; x=1307022700; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hp1eMkBnE0sxQnl8pq2kMBZgyX1FIN/B+L9d0mo4+A0=; b=TEumZv+W7dSP/wPIysU1wUwiRha29etVbGiaxOOzTm+lEYScDueHjETt 7HBv2st9oJFdFv4XwRsY5L9y5RjxfxHqEoHwk1UpGMtON97rCNxK9j5NL We0KYVoeaYWQpJJ+VtrkSAWnhTiK2F9ypIAqIWY++cwoMrwK/ypZkBMeb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAN0f1U2tJXG//2dsb2JhbACXUY49d4hwomOQH419gw0BgwsEhlCNeYpb X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="700162146" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 19 May 2011 13:51:37 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4JDpbQ7008414; Thu, 19 May 2011 13:51:37 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 08:51:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 08:51:36 -0500 Message-ID: In-Reply-To: <4DD4584E.30405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwVtJtX8TBJbijCQ7eJIFg23c4TvQAdCvZg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 19 May 2011 13:51:37.0550 (UTC) FILETIME=[DF7826E0:01CC162B] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 19 May 2011 13:51:45 -0000 Paul, What I am trying to say is that Telepresence is all about the end-user experience, and that with multiple microphones, speakers, cameras, displays, and data feeds there is more complexity and chance to screw that up. And a key point is that spatial relationships are significant to the user experience. As a result, more rigor is needed to design the system to ensure that backward compatible means that legacy systems are handled as such. I am not sure if the protocol design is far enough along to analyze whether correct protocol operation still results in bad user experience, but would suggest that if certain key concepts like spatial awareness are not understood, then that leg needs to devolve to a known legacy state and handled by the MCU as such. That might mean tagging some parameters as mandatory to understand to force the determination and not leave it ambiguous. I believe some current systems treat legacy systems differently and don't expect them to behave like ones that understands the dynamic speaker controls. Mike -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Wednesday, May 18, 2011 7:38 PM To: Mike Hammer (hmmr) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] legacy support in requirements On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > Paul, > > Murphy's Law says that if it is possible to put something together the > wrong way, > probability says it will go the wrong way sooner or later. LTC Murphy > had a > young enlisted guy that always found that wrong way to do things. > System-wise, > the black-swan events occur unless you do your best to design them out. > > Machines are often designed so that there is exactly one way to do it. > > We want flexibility in software, but sometimes too much is not so good. > Hopefully, proper operation of the protocol won't look like an error. Mike, I don't understand the point you are trying to make in the context of=20 this conversation. This started out as a discussion of whether it was acceptable to reject=20 an offer because it contains stuff (for the sake of argument lets=20 restrict it to a-lines for now) the the answerer doesn't understand/know anything about. Clearly its *possible* for a UA to do that. And since a UA can reject=20 things for policy reasons, it may be undecidable whether it rejected=20 because of the unknown lines or for some more justifed reason. But still, I think we can *expect* a UA to refrain from doing that. That doesn't mean they all will. But when they don't, its a bug, not a=20 valid implementation choice. Thanks, Paul > Mike > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 1:09 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >> Paul, >> >> I would agree that if the offer-answer model semantic is that here are >> several options and any subset of options is acceptable. >> >> However, if there is any grouping involved such that you need to have > a >> video and audio feed integrated to make sense then watch out. >> >> For example, I wouldn't want to end up with the result of a man's > video >> paired with a woman's voice. That could be rather comical. > > Well, SDP defines that you should ignore what you don't understand and > operate on what is left. > > So someone constructing an SDP with grouping issues such as you define > ought to keep in mind that this could happen, and set things up so that > something reasonable happens. You can't expect the dumb legacy device to > > figure out much. > > For your example, the result may be far from ideal, but it still is > likely to be better than no call at all. And if not, there is always the > > option of hanging up. But better, presumably the offer could have been > constructed in a way that produced a better result. > > Thanks, > Paul > >> Mike >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Paul Kyzivat (pkyzivat) >> Sent: Tuesday, May 17, 2011 7:45 PM >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 6:05 PM, Roni Even wrote: >>> Paul, >>> I think we read it differently. >>> If the answerer does not support the group attribute and the offer > had >> the >>> fid semantics it may look to the answerer as an offer with multiple >> m-lines >>> of the same media tyoe. In this case an implementation might also >> decide to >>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >> Acceptable), >>> because it contains several "m" lines of the same media type. >> >> That is a slightly different story. >> >> Then the reason for rejection is not because it saw an attribute it >> didn't understand - its because it didn't like something it *did* >> understand. >> >>> This is very relevant to the multiple streams case and we should look >> if we >>> state this behavior or we will look at providing an approach that > will >> allow >>> the answerer to choose one m-line that the offerer prefers even of it >> does >>> not understand CLUE. >> >> IMO (lets see if others differ), if a UA receives an offer with at > least >> >> one m-line it is happy with, then it should not reject the call > because >> there are others that it does not "understand". >> >> Here "understand" means something different - presumably it does >> understand the direct meaning of the additional m-line, it just > doesn't >> understand the *significance* or use of it. >> >> I see little difference to getting to audio m-lines and only wanting >> one, and getting one audio and one video and only supporting audio. In >> general you should not reject an audio/video call just because you > only >> support audio. >> >> I think it will behoove clue to strongly recommend that the m-lines in >> an offer be arranged so the first ones are the ones it most wants used >> if not all are. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>> To: Roni Even >>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> Paul, >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example >>>>> Roni >>>> >>>> OK, I looked. It is consistent with what I said. >>>> Either a=3Dgroup: is understood, or not. If not, its ignored, and = not >> put >>>> in the answer. Same with a=3Dmid: >>>> >>>> If a=3Dgroup: *is* understood, but some parameter within it is not, >> there >>>> are explicit rules for what to do. >>>> >>>> AFAICT there are no examples in this document where failure to >>>> understand an a-line in total (or even in part) results in rejecting >>>> the >>>> offer. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> To: Stephen Botzko >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>> >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>> >>>>>>> When the offer includes parameters that the answerer >> does >>>> not >>>>>>> understand >>>>>>> there are two options, he can ignore the unknown >>>> parameters >>>>>> or >>>>>>> reject >>>>>>> the offer. >>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>> You are required to ignore parameters you do not > understand. >>>>>>> >>>>>>> If you reject something because you don't like the >> parameters >>>> it >>>>>>> contains, then that is an implicit statement that you >>>> understand >>>>>>> those parameters well enough to decide to reject them. >>>>>>> >>>>>>> As far as I know, you are always free to reject offers, and it >>>>>> doesn't >>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>> perhaps >>>>>>> a different question. >>>>>>> Stephen Botzko >>>>>> >>>>>> Certainly you are always free to reject an offer. >>>>>> In general I don't know for certain the reason why, and so if I >> give >>>>>> you >>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>> perhaps >>>>>> just policy. >>>>>> >>>>>> But if the reason you reject the offer is based on your violating > a >>>>>> spec, then you are non-conforming, whether I can determine you are >>>>>> non-conforming or not. Whether being non-conforming is just >> un-wise, >>>> or >>>>>> something stronger, is a separate discussion. The IETF does not >> levy >>>>>> any >>>>>> penalties for violating its specs. But sometimes the market does. >>>> (And >>>>>> sometimes not.) But we don't need to endorse non-conforming >> behavior >>>> in >>>>>> our documents. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From pkyzivat@cisco.com Thu May 19 07:08:15 2011 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 86630E07BC for ; Thu, 19 May 2011 07:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.449 X-Spam-Level: X-Spam-Status: No, score=-108.449 tagged_above=-999 required=5 tests=[AWL=-1.749, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8, 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 vgUSGevObizn for ; Thu, 19 May 2011 07:08:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 14F64E06BD for ; Thu, 19 May 2011 07:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11299; q=dns/txt; s=iport; t=1305814094; x=1307023694; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MZraFEZlNJt+mIADE9AtaIWw4PdDlE14H7b1cjLA6Cg=; b=Y5gvBMhPSWxMfMW23Z5pwFHwbt3xYAvff2mt/tH/ghbihIZZhCjSF9JQ FuUNbBKamKvTcMDY/9CXdAVfjCE+sIPlNcMku9PTebuYBd05TWBxFhchS 8MrkYHkd3lFtE2/hRBzmGmLZBY4rxar4Dj8HinxFlLUmc+jPFvGBJEA6n I=; X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="233564297" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 19 May 2011 14:08:13 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4JE8CIn012298; Thu, 19 May 2011 14:08:12 GMT Message-ID: <4DD5244C.8090801@cisco.com> Date: Thu, 19 May 2011 10:08:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.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] legacy support in requirements 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, 19 May 2011 14:08:15 -0000 Mike, On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > Paul, > > What I am trying to say is that Telepresence is all about the end-user > experience, and that with multiple microphones, speakers, cameras, > displays, and data feeds there is more complexity and chance to screw > that up. And a key point is that spatial relationships are significant > to the user experience. As a result, more rigor is needed to design the > system to ensure that backward compatible means that legacy systems are > handled as such. > > I am not sure if the protocol design is far enough along to analyze > whether correct protocol operation still results in bad user experience, > but would suggest that if certain key concepts like spatial awareness > are not understood, then that leg needs to devolve to a known legacy > state and handled by the MCU as such. That might mean tagging some > parameters as mandatory to understand to force the determination and not > leave it ambiguous. > > I believe some current systems treat legacy systems differently and > don't expect them to behave like ones that understands the dynamic > speaker controls. I suspect we are talking past each other and are not really in disagreement. I expect that the clue specs, whatever they turn out to be, will require support for a bunch of existing sip/sdp mechanisms that are generally optional and not widely implemented in lower end devices. If so, then if we have two clueful systems attempting to connect, we will be in the realm of negotiating using syntax that both understand. In that case, this discussion of how to behave when something *isn't* understood is moot. Rather that situation will arise when we have a clueful system attempting to connect to a clueless system, or visa versa. That is where my focus is in this discussion. Further into the future, perhaps we will have clue_v2, clue_v3, etc. In that case, we may again be into a situation where we have a clue_v1_ful system that doesn't understand something coming from a clue_v2_ful system. When designing any new protocol for clue_v1, we should keep in mind to specify how to handle that which isn't understood in order to support that future scenario. Thanks, Paul > Mike > > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 7:38 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: >> Paul, >> >> Murphy's Law says that if it is possible to put something together the >> wrong way, >> probability says it will go the wrong way sooner or later. LTC Murphy >> had a >> young enlisted guy that always found that wrong way to do things. >> System-wise, >> the black-swan events occur unless you do your best to design them > out. >> >> Machines are often designed so that there is exactly one way to do it. >> >> We want flexibility in software, but sometimes too much is not so > good. >> Hopefully, proper operation of the protocol won't look like an error. > > Mike, > > I don't understand the point you are trying to make in the context of > this conversation. > > This started out as a discussion of whether it was acceptable to reject > an offer because it contains stuff (for the sake of argument lets > restrict it to a-lines for now) the the answerer doesn't understand/know > > anything about. > > Clearly its *possible* for a UA to do that. And since a UA can reject > things for policy reasons, it may be undecidable whether it rejected > because of the unknown lines or for some more justifed reason. > > But still, I think we can *expect* a UA to refrain from doing that. > > That doesn't mean they all will. But when they don't, its a bug, not a > valid implementation choice. > > Thanks, > Paul > >> Mike >> >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, May 18, 2011 1:09 PM >> To: Mike Hammer (hmmr) >> Cc: Roni Even; clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >>> Paul, >>> >>> I would agree that if the offer-answer model semantic is that here > are >>> several options and any subset of options is acceptable. >>> >>> However, if there is any grouping involved such that you need to have >> a >>> video and audio feed integrated to make sense then watch out. >>> >>> For example, I wouldn't want to end up with the result of a man's >> video >>> paired with a woman's voice. That could be rather comical. >> >> Well, SDP defines that you should ignore what you don't understand and >> operate on what is left. >> >> So someone constructing an SDP with grouping issues such as you define >> ought to keep in mind that this could happen, and set things up so > that >> something reasonable happens. You can't expect the dumb legacy device > to >> >> figure out much. >> >> For your example, the result may be far from ideal, but it still is >> likely to be better than no call at all. And if not, there is always > the >> >> option of hanging up. But better, presumably the offer could have been >> constructed in a way that produced a better result. >> >> Thanks, >> Paul >> >>> Mike >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Paul Kyzivat (pkyzivat) >>> Sent: Tuesday, May 17, 2011 7:45 PM >>> To: Roni Even >>> Cc: clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>> Paul, >>>> I think we read it differently. >>>> If the answerer does not support the group attribute and the offer >> had >>> the >>>> fid semantics it may look to the answerer as an offer with multiple >>> m-lines >>>> of the same media tyoe. In this case an implementation might also >>> decide to >>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>> Acceptable), >>>> because it contains several "m" lines of the same media type. >>> >>> That is a slightly different story. >>> >>> Then the reason for rejection is not because it saw an attribute it >>> didn't understand - its because it didn't like something it *did* >>> understand. >>> >>>> This is very relevant to the multiple streams case and we should > look >>> if we >>>> state this behavior or we will look at providing an approach that >> will >>> allow >>>> the answerer to choose one m-line that the offerer prefers even of > it >>> does >>>> not understand CLUE. >>> >>> IMO (lets see if others differ), if a UA receives an offer with at >> least >>> >>> one m-line it is happy with, then it should not reject the call >> because >>> there are others that it does not "understand". >>> >>> Here "understand" means something different - presumably it does >>> understand the direct meaning of the additional m-line, it just >> doesn't >>> understand the *significance* or use of it. >>> >>> I see little difference to getting to audio m-lines and only wanting >>> one, and getting one audio and one video and only supporting audio. > In >>> general you should not reject an audio/video call just because you >> only >>> support audio. >>> >>> I think it will behoove clue to strongly recommend that the m-lines > in >>> an offer be arranged so the first ones are the ones it most wants > used >>> if not all are. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>> To: Roni Even >>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>> Paul, >>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >> example >>>>>> Roni >>>>> >>>>> OK, I looked. It is consistent with what I said. >>>>> Either a=group: is understood, or not. If not, its ignored, and not >>> put >>>>> in the answer. Same with a=mid: >>>>> >>>>> If a=group: *is* understood, but some parameter within it is not, >>> there >>>>> are explicit rules for what to do. >>>>> >>>>> AFAICT there are no examples in this document where failure to >>>>> understand an a-line in total (or even in part) results in > rejecting >>>>> the >>>>> offer. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> Paul Kyzivat >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>> To: Stephen Botzko >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>> >>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>> >>>>>>>> When the offer includes parameters that the answerer >>> does >>>>> not >>>>>>>> understand >>>>>>>> there are two options, he can ignore the unknown >>>>> parameters >>>>>>> or >>>>>>>> reject >>>>>>>> the offer. >>>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>>> You are required to ignore parameters you do not >> understand. >>>>>>>> >>>>>>>> If you reject something because you don't like the >>> parameters >>>>> it >>>>>>>> contains, then that is an implicit statement that you >>>>> understand >>>>>>>> those parameters well enough to decide to reject them. >>>>>>>> >>>>>>>> As far as I know, you are always free to reject offers, and it >>>>>>> doesn't >>>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>>> perhaps >>>>>>>> a different question. >>>>>>>> Stephen Botzko >>>>>>> >>>>>>> Certainly you are always free to reject an offer. >>>>>>> In general I don't know for certain the reason why, and so if I >>> give >>>>>>> you >>>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>>> perhaps >>>>>>> just policy. >>>>>>> >>>>>>> But if the reason you reject the offer is based on your violating >> a >>>>>>> spec, then you are non-conforming, whether I can determine you > are >>>>>>> non-conforming or not. Whether being non-conforming is just >>> un-wise, >>>>> or >>>>>>> something stronger, is a separate discussion. The IETF does not >>> levy >>>>>>> any >>>>>>> penalties for violating its specs. But sometimes the market does. >>>>> (And >>>>>>> sometimes not.) But we don't need to endorse non-conforming >>> behavior >>>>> in >>>>>>> our documents. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> >>>> >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> > From stephen.botzko@gmail.com Thu May 19 07:10:43 2011 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 743C6E07DA for ; Thu, 19 May 2011 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 tXdthW+HU+u2 for ; Thu, 19 May 2011 07:10:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85E75E07D9 for ; Thu, 19 May 2011 07:10:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so2305774vxg.31 for ; Thu, 19 May 2011 07:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Xy7pLbPbIHK5bcfmwvaV2Bpi12+pk0pgG3mFcq+oLQ=; b=lGtn3vJzec85RMzoBAvECuKKmrMA8YTANWg+9kOqgCg+38fMAH2rV3T+QsQqm333WU UIABfXlT1CByuoAg4FVRE9af4GZn/7SBdsKwPT5qbJZKvztwg+4cegMFSkCwqQ/he7pg A/oVHMY6ffMVjGfJ18nVufeT7khcTk9Sd7SDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QKXg6swFQi3O+Hl6oOF8HIMm/xaN5B7KJQ/eOSwfu7y1ER1lN1J3FMq3Hft+13hikn nWNh3HKZwF25I5PJi6CAZNGYmzX+H7bl/kMQjolFq0wU0FlizJyrkhy8f5d2xYjIL6ZW Dmnmayy3iSqQaDfKJl7f/ut3JzwIZalUSRmN4= MIME-Version: 1.0 Received: by 10.52.173.168 with SMTP id bl8mr1012323vdc.106.1305814240642; Thu, 19 May 2011 07:10:40 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Thu, 19 May 2011 07:10:40 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> Date: Thu, 19 May 2011 10:10:40 -0400 Message-ID: From: Stephen Botzko To: "Mike Hammer (hmmr)" Content-Type: multipart/alternative; boundary=bcaec5197037f4c59e04a3a19104 Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 19 May 2011 14:10:43 -0000 --bcaec5197037f4c59e04a3a19104 Content-Type: text/plain; charset=ISO-8859-1 In line Stephen Botzko On Thu, May 19, 2011 at 9:51 AM, Mike Hammer (hmmr) wrote: > Paul, > > What I am trying to say is that Telepresence is all about the end-user > experience, and that with multiple microphones, speakers, cameras, > displays, and data feeds there is more complexity and chance to screw > that up. And a key point is that spatial relationships are significant > to the user experience. As a result, more rigor is needed to design the > system to ensure that backward compatible means that legacy systems are > handled as such. > > I agree that it is important for CLUE systems to be able to detect if the far end is CLUEless. > I am not sure if the protocol design is far enough along to analyze > whether correct protocol operation still results in bad user experience, > but would suggest that if certain key concepts like spatial awareness > are not understood, then that leg needs to devolve to a known legacy > state and handled by the MCU as such. That might mean tagging some > parameters as mandatory to understand to force the determination and not > leave it ambiguous. > > I think that it is always possible to deliver a bad user experience with correct protocol. Though I agree that we have to make sure the desired interoperable experience is fully enabled, and that we should stick to concepts / modes of operation that are well understood. > I believe some current systems treat legacy systems differently and > don't expect them to behave like ones that understands the dynamic > speaker controls. > > Not sure what the relevance of dynamic speaker controls is here?? Though maybe it doesn't matter, as I agree that telepresence systems will generally want to adjust their operation when connecting to a legacy system. > Mike > > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 7:38 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > > Paul, > > > > Murphy's Law says that if it is possible to put something together the > > wrong way, > > probability says it will go the wrong way sooner or later. LTC Murphy > > had a > > young enlisted guy that always found that wrong way to do things. > > System-wise, > > the black-swan events occur unless you do your best to design them > out. > > > > Machines are often designed so that there is exactly one way to do it. > > > > We want flexibility in software, but sometimes too much is not so > good. > > Hopefully, proper operation of the protocol won't look like an error. > > Mike, > > I don't understand the point you are trying to make in the context of > this conversation. > > This started out as a discussion of whether it was acceptable to reject > an offer because it contains stuff (for the sake of argument lets > restrict it to a-lines for now) the the answerer doesn't understand/know > > anything about. > > Clearly its *possible* for a UA to do that. And since a UA can reject > things for policy reasons, it may be undecidable whether it rejected > because of the unknown lines or for some more justifed reason. > > But still, I think we can *expect* a UA to refrain from doing that. > > That doesn't mean they all will. But when they don't, its a bug, not a > valid implementation choice. > > Thanks, > Paul > > > Mike > > > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Wednesday, May 18, 2011 1:09 PM > > To: Mike Hammer (hmmr) > > Cc: Roni Even; clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > >> Paul, > >> > >> I would agree that if the offer-answer model semantic is that here > are > >> several options and any subset of options is acceptable. > >> > >> However, if there is any grouping involved such that you need to have > > a > >> video and audio feed integrated to make sense then watch out. > >> > >> For example, I wouldn't want to end up with the result of a man's > > video > >> paired with a woman's voice. That could be rather comical. > > > > Well, SDP defines that you should ignore what you don't understand and > > operate on what is left. > > > > So someone constructing an SDP with grouping issues such as you define > > ought to keep in mind that this could happen, and set things up so > that > > something reasonable happens. You can't expect the dumb legacy device > to > > > > figure out much. > > > > For your example, the result may be far from ideal, but it still is > > likely to be better than no call at all. And if not, there is always > the > > > > option of hanging up. But better, presumably the offer could have been > > constructed in a way that produced a better result. > > > > Thanks, > > Paul > > > >> Mike > >> > >> > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > >> Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, May 17, 2011 7:45 PM > >> To: Roni Even > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/17/2011 6:05 PM, Roni Even wrote: > >>> Paul, > >>> I think we read it differently. > >>> If the answerer does not support the group attribute and the offer > > had > >> the > >>> fid semantics it may look to the answerer as an offer with multiple > >> m-lines > >>> of the same media tyoe. In this case an implementation might also > >> decide to > >>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > >> Acceptable), > >>> because it contains several "m" lines of the same media type. > >> > >> That is a slightly different story. > >> > >> Then the reason for rejection is not because it saw an attribute it > >> didn't understand - its because it didn't like something it *did* > >> understand. > >> > >>> This is very relevant to the multiple streams case and we should > look > >> if we > >>> state this behavior or we will look at providing an approach that > > will > >> allow > >>> the answerer to choose one m-line that the offerer prefers even of > it > >> does > >>> not understand CLUE. > >> > >> IMO (lets see if others differ), if a UA receives an offer with at > > least > >> > >> one m-line it is happy with, then it should not reject the call > > because > >> there are others that it does not "understand". > >> > >> Here "understand" means something different - presumably it does > >> understand the direct meaning of the additional m-line, it just > > doesn't > >> understand the *significance* or use of it. > >> > >> I see little difference to getting to audio m-lines and only wanting > >> one, and getting one audio and one video and only supporting audio. > In > >> general you should not reject an audio/video call just because you > > only > >> support audio. > >> > >> I think it will behoove clue to strongly recommend that the m-lines > in > >> an offer be arranged so the first ones are the ones it most wants > used > >> if not all are. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Wednesday, May 18, 2011 12:37 AM > >>>> To: Roni Even > >>>> Cc: 'Stephen Botzko'; clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>>> > >>>> > >>>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>>> Paul, > >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > example > >>>>> Roni > >>>> > >>>> OK, I looked. It is consistent with what I said. > >>>> Either a=group: is understood, or not. If not, its ignored, and not > >> put > >>>> in the answer. Same with a=mid: > >>>> > >>>> If a=group: *is* understood, but some parameter within it is not, > >> there > >>>> are explicit rules for what to do. > >>>> > >>>> AFAICT there are no examples in this document where failure to > >>>> understand an a-line in total (or even in part) results in > rejecting > >>>> the > >>>> offer. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>>> To: Stephen Botzko > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>>> > >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>>> > >>>>>>> When the offer includes parameters that the answerer > >> does > >>>> not > >>>>>>> understand > >>>>>>> there are two options, he can ignore the unknown > >>>> parameters > >>>>>> or > >>>>>>> reject > >>>>>>> the offer. > >>>>>>> Rejecting the offer in that case is not really kosher. > >>>>>>> You are required to ignore parameters you do not > > understand. > >>>>>>> > >>>>>>> If you reject something because you don't like the > >> parameters > >>>> it > >>>>>>> contains, then that is an implicit statement that you > >>>> understand > >>>>>>> those parameters well enough to decide to reject them. > >>>>>>> > >>>>>>> As far as I know, you are always free to reject offers, and it > >>>>>> doesn't > >>>>>>> really imply anything when you do that.. Whether it is wise is > >>>>>> perhaps > >>>>>>> a different question. > >>>>>>> Stephen Botzko > >>>>>> > >>>>>> Certainly you are always free to reject an offer. > >>>>>> In general I don't know for certain the reason why, and so if I > >> give > >>>>>> you > >>>>>> the benefit of the doubt I will assume you have a valid reason - > >>>>>> perhaps > >>>>>> just policy. > >>>>>> > >>>>>> But if the reason you reject the offer is based on your violating > > a > >>>>>> spec, then you are non-conforming, whether I can determine you > are > >>>>>> non-conforming or not. Whether being non-conforming is just > >> un-wise, > >>>> or > >>>>>> something stronger, is a separate discussion. The IETF does not > >> levy > >>>>>> any > >>>>>> penalties for violating its specs. But sometimes the market does. > >>>> (And > >>>>>> sometimes not.) But we don't need to endorse non-conforming > >> behavior > >>>> in > >>>>>> our documents. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>> > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec5197037f4c59e04a3a19104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In line
Stephen Botzko

On Thu, May 19,= 2011 at 9:51 AM, Mike Hammer (hmmr) <hmmr@cisco.com> wrote:
Paul,

What I am trying to say is that Telepresence is all about the end-user
experience, and that with multiple microphones, speakers, cameras,
displays, and data feeds there is more complexity and chance to screw
that up. =A0And a key point is that spatial relationships are significant to the user experience. =A0As a result, more rigor is needed to design the<= br> system to ensure that backward compatible means that legacy systems are
handled as such.

I agree that it is important for CLUE systems to be a= ble to detect if the far end is CLUEless.=A0
=A0
I am not sure if the protocol design is far enough along to analyze
whether correct protocol operation still results in bad user experience, but would suggest that if certain key concepts like spatial awareness
are not understood, then that leg needs to devolve to a known legacy
state and handled by the MCU as such. =A0That might mean tagging some
parameters as mandatory to understand to force the determination and not leave it ambiguous.

I think that it is always possible to deliver a bad u= ser experience with correct protocol.

Though I agree that we have to= make sure the desired interoperable experience is fully enabled, and that = we should stick to concepts / modes of operation that are well understood.<= br> =A0
I believe some current systems treat legacy systems differently and
don't expect them to behave like ones that understands the dynamic
speaker controls.

Not sure what the relevance o= f dynamic speaker controls is here??=A0 Though maybe it doesn't matter,= as I agree that telepresence systems will generally want to adjust their o= peration when connecting to a legacy system.=A0
=A0
Mike


-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Wednesday, May 18, 2011 7:38 = PM
To: Mike Hammer (hmmr)
Cc: Roni Even; clue@ietf.org
Subject: Re: [clue] legacy support in requirements



On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote:
> Paul,
>
> Murphy's Law says that if it is possible to put something together= the
> wrong way,
> probability says it will go the wrong way sooner or later. =A0LTC Murp= hy
> had a
> young enlisted guy that always found that wrong way to do things.
> System-wise,
> the black-swan events occur unless you do your best to design them
out.
>
> Machines are often designed so that there is exactly one way to do it.=
>
> We want flexibility in software, but sometimes too much is not so
good.
> Hopefully, proper operation of the protocol won't look like an err= or.

Mike,

I don't understand the point you are trying to make in the context of this conversation.

This started out as a discussion of whether it was acceptable to reject
an offer because it contains stuff (for the sake of argument lets
restrict it to a-lines for now) the the answerer doesn't understand/kno= w

anything about.

Clearly its *possible* for a UA to do that. And since a UA can reject
things for policy reasons, it may be undecidable whether it rejected
because of the unknown lines or for some more justifed reason.

But still, I think we can *expect* a UA to refrain from doing that.

That doesn't mean they all will. But when they don't, its a bug, no= t a
valid implementation choice.

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

> Mike
>
> -----Original Message-----
> From: Paul Kyzivat (pkyzivat)
> Sent: Wednesday, May 18, 2011 1:09 PM
> To: Mike Hammer (hmmr)
> Cc: Roni Even; clue@ietf.org
> Subject: Re: [clue] legacy support in requirements
>
>
>
> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote:
>> Paul,
>>
>> I would agree that if the offer-answer model semantic is that here=
are
>> several options and any subset of options is acceptable.
>>
>> However, if there is any grouping involved such that you need to h= ave
> a
>> video and audio feed integrated to make sense then watch out.
>>
>> For example, I wouldn't want to end up with the result of a ma= n's
> video
>> paired with a woman's voice. =A0That could be rather comical.<= br> >
> Well, SDP defines that you should ignore what you don't understand= and
> operate on what is left.
>
> So someone constructing an SDP with grouping issues such as you define=
> ought to keep in mind that this could happen, and set things up so
that
> something reasonable happens. You can't expect the dumb legacy dev= ice
to
>
> figure out much.
>
> For your example, the result may be far from ideal, but it still is > likely to be better than no call at all. And if not, there is always the
>
> option of hanging up. But better, presumably the offer could have been=
> constructed in a way that produced a better result.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Mike
>>
>>
>> -----Original Message-----
>> From: clue-bounces@ietf.o= rg [mailto:clue-bounces@ietf.o= rg] On Behalf
> Of
>> Paul Kyzivat (pkyzivat)
>> Sent: Tuesday, May 17, 2011 7:45 PM
>> To: Roni Even
>> Cc: clue@ietf.org
>> Subject: Re: [clue] legacy support in requirements
>>
>>
>>
>> On 5/17/2011 6:05 PM, Roni Even wrote:
>>> Paul,
>>> I think we read it differently.
>>> If the answerer does not support the group attribute and the o= ffer
> had
>> the
>>> fid semantics it may look to the answerer as an offer with mul= tiple
>> m-lines
>>> of the same media tyoe. In this case an implementation might a= lso
>> decide to
>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not<= br> >> Acceptable),
>>> because it contains several "m" lines of the same me= dia type.
>>
>> That is a slightly different story.
>>
>> Then the reason for rejection is not because it saw an attribute i= t
>> didn't understand - its because it didn't like something i= t *did*
>> understand.
>>
>>> This is very relevant to the multiple streams case and we shou= ld
look
>> if we
>>> state this behavior or we will look at providing an approach t= hat
> will
>> allow
>>> the answerer to choose one m-line that the offerer prefers eve= n of
it
>> does
>>> not understand CLUE.
>>
>> IMO (lets see if others differ), if a UA receives an offer with at=
> least
>>
>> one m-line it is happy with, then it should not reject the call > because
>> there are others that it does not "understand".
>>
>> Here "understand" means something different - presumably= it does
>> understand the direct meaning of the additional m-line, it just > doesn't
>> understand the *significance* or use of it.
>>
>> I see little difference to getting to audio m-lines and only wanti= ng
>> one, and getting one audio and one video and only supporting audio= .
In
>> general you should not reject an audio/video call just because you=
> only
>> support audio.
>>
>> I think it will behoove clue to strongly recommend that the m-line= s
in
>> an offer be arranged so the first ones are the ones it most wants<= br> used
>> if not all are.
>>
>> =A0 =A0 =A0Thanks,
>> =A0 =A0 =A0Paul
>>
>>> Roni
>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>> Sent: Wednesday, May 18, 2011 12:37 AM
>>>> To: Roni Even
>>>> Cc: 'Stephen Botzko'; clue@ietf.org
>>>> Subject: Re: [clue] legacy support in requirements
>>>>
>>>>
>>>>
>>>> On 5/17/2011 5:20 PM, Roni Even wrote:
>>>>> Paul,
>>>>> Look at http://tools.ietf.org/html/rfc5888#section= -9.4.2 for
> example
>>>>> Roni
>>>>
>>>> OK, I looked. It is consistent with what I said.
>>>> Either a=3Dgroup: is understood, or not. If not, its ignor= ed, and not
>> put
>>>> in the answer. Same with a=3Dmid:
>>>>
>>>> If a=3Dgroup: *is* understood, but some parameter within i= t is not,
>> there
>>>> are explicit rules for what to do.
>>>>
>>>> AFAICT there are no examples in this document where failur= e to
>>>> understand an a-line in total (or even in part) results in=
rejecting
>>>> the
>>>> offer.
>>>>
>>>> =A0 =A0Thanks,
>>>> =A0 =A0Paul
>>>>
>>>>>> -----Original Message-----
>>>>>> From: clu= e-bounces@ietf.org [mailto:clu= e-bounces@ietf.org] On
>> Behalf
>>>> Of
>>>>>> Paul Kyzivat
>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM
>>>>>> To: Stephen Botzko
>>>>>> Cc: clue@ietf.org=
>>>>>> Subject: Re: [clue] legacy support in requirements=
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote:
>>>>>>
>>>>>>> =A0 =A0 =A0 =A0 On 5/17/2011 2:24 AM, Roni Eve= n wrote:
>>>>>>
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 When the offer include= s parameters that the answerer
>> does
>>>> not
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 understand
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 there are two options,= he can ignore the unknown
>>>> parameters
>>>>>> or
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 reject
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 the offer.
>>>>>>> =A0 =A0 =A0 =A0 Rejecting the offer in that ca= se is not really kosher.
>>>>>>> =A0 =A0 =A0 =A0 You are required to ignore par= ameters you do not
> understand.
>>>>>>>
>>>>>>> =A0 =A0 =A0 =A0 If you reject something becaus= e you don't like the
>> parameters
>>>> it
>>>>>>> =A0 =A0 =A0 =A0 contains, then that is an impl= icit statement that you
>>>> understand
>>>>>>> =A0 =A0 =A0 =A0 those parameters well enough t= o decide to reject them.
>>>>>>>
>>>>>>> As far as I know, you are always free to rejec= t offers, and it
>>>>>> doesn't
>>>>>>> really imply anything when you do that.. =A0Wh= ether it is wise is
>>>>>> perhaps
>>>>>>> a different question.
>>>>>>> Stephen Botzko
>>>>>>
>>>>>> Certainly you are always free to reject an offer.<= br> >>>>>> In general I don't know for certain the reason= why, and so if I
>> give
>>>>>> you
>>>>>> the benefit of the doubt I will assume you have a = valid reason -
>>>>>> perhaps
>>>>>> just policy.
>>>>>>
>>>>>> But if the reason you reject the offer is based on= your violating
> a
>>>>>> spec, then you are non-conforming, whether I can d= etermine you
are
>>>>>> non-conforming or not. Whether being non-conformin= g is just
>> un-wise,
>>>> or
>>>>>> something stronger, is a separate discussion. The = IETF does not
>> levy
>>>>>> any
>>>>>> penalties for violating its specs. But sometimes t= he market does.
>>>> (And
>>>>>> sometimes not.) But we don't need to endorse n= on-conforming
>> behavior
>>>> in
>>>>>> our documents.
>>>>>>
>>>>>> =A0Thanks,
>>>>>> =A0Paul
>>>>>> _______________________________________________ >>>>>> clue mailing list
>>>>>> clue@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>>
>>>
>>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec5197037f4c59e04a3a19104-- From hmmr@cisco.com Thu May 19 07:11:08 2011 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 6B04EE07CF for ; Thu, 19 May 2011 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.162 X-Spam-Level: X-Spam-Status: No, score=-8.162 tagged_above=-999 required=5 tests=[AWL=-1.462, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 sLNTX7QrYRUf for ; Thu, 19 May 2011 07:11:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1CE06BD for ; Thu, 19 May 2011 07:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=11672; q=dns/txt; s=iport; t=1305814266; x=1307023866; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WDwiz1atLyezaz4gd2DHhTz4Z1lv4YP7Nd39Fz2peXg=; b=ObDZLlHe1Dd4eo6JcQXq3vKhmX8kNB16y1ZwVPBWTzxehU7+3rfcUYmG RXJnVl5latmJyBqsVgeyeBog50vbkQVzfbiUIlpXufyhN7EFJBC6wKpXC Imbx7i8Ul+AnTPRaKnpEb+LfHsjI3DrqM+W8vVwnrKHLglS032FaN5UuQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAJsk1U2tJV2Y/2dsb2JhbACXUY49d4hwokmQH44Bgw0BgwsEhlCNeYpb X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="360353026" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 19 May 2011 14:11:05 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4JEB5kv007436; Thu, 19 May 2011 14:11:05 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 09:11:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 09:11:03 -0500 Message-ID: In-Reply-To: <4DD5244C.8090801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwWLjIOsdAYCU3tStCBdkmmggvgpQAAEh9Q References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 19 May 2011 14:11:04.0771 (UTC) FILETIME=[972FF130:01CC162E] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 19 May 2011 14:11:08 -0000 OK, so you do have some mechanism to discover that the other is clueful. That eases my concerns. Mike -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Thursday, May 19, 2011 10:08 AM To: Mike Hammer (hmmr) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] legacy support in requirements Mike, On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > Paul, > > What I am trying to say is that Telepresence is all about the end-user > experience, and that with multiple microphones, speakers, cameras, > displays, and data feeds there is more complexity and chance to screw > that up. And a key point is that spatial relationships are significant > to the user experience. As a result, more rigor is needed to design the > system to ensure that backward compatible means that legacy systems are > handled as such. > > I am not sure if the protocol design is far enough along to analyze > whether correct protocol operation still results in bad user experience, > but would suggest that if certain key concepts like spatial awareness > are not understood, then that leg needs to devolve to a known legacy > state and handled by the MCU as such. That might mean tagging some > parameters as mandatory to understand to force the determination and not > leave it ambiguous. > > I believe some current systems treat legacy systems differently and > don't expect them to behave like ones that understands the dynamic > speaker controls. I suspect we are talking past each other and are not really in disagreement. I expect that the clue specs, whatever they turn out to be, will require support for a bunch of existing sip/sdp mechanisms that are generally=20 optional and not widely implemented in lower end devices. If so, then if we have two clueful systems attempting to connect, we=20 will be in the realm of negotiating using syntax that both understand.=20 In that case, this discussion of how to behave when something *isn't*=20 understood is moot. Rather that situation will arise when we have a=20 clueful system attempting to connect to a clueless system, or visa=20 versa. That is where my focus is in this discussion. Further into the future, perhaps we will have clue_v2, clue_v3, etc. In=20 that case, we may again be into a situation where we have a clue_v1_ful=20 system that doesn't understand something coming from a clue_v2_ful=20 system. When designing any new protocol for clue_v1, we should keep in=20 mind to specify how to handle that which isn't understood in order to=20 support that future scenario. Thanks, Paul > Mike > > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 7:38 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: >> Paul, >> >> Murphy's Law says that if it is possible to put something together the >> wrong way, >> probability says it will go the wrong way sooner or later. LTC Murphy >> had a >> young enlisted guy that always found that wrong way to do things. >> System-wise, >> the black-swan events occur unless you do your best to design them > out. >> >> Machines are often designed so that there is exactly one way to do it. >> >> We want flexibility in software, but sometimes too much is not so > good. >> Hopefully, proper operation of the protocol won't look like an error. > > Mike, > > I don't understand the point you are trying to make in the context of > this conversation. > > This started out as a discussion of whether it was acceptable to reject > an offer because it contains stuff (for the sake of argument lets > restrict it to a-lines for now) the the answerer doesn't understand/know > > anything about. > > Clearly its *possible* for a UA to do that. And since a UA can reject > things for policy reasons, it may be undecidable whether it rejected > because of the unknown lines or for some more justifed reason. > > But still, I think we can *expect* a UA to refrain from doing that. > > That doesn't mean they all will. But when they don't, its a bug, not a > valid implementation choice. > > Thanks, > Paul > >> Mike >> >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, May 18, 2011 1:09 PM >> To: Mike Hammer (hmmr) >> Cc: Roni Even; clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >>> Paul, >>> >>> I would agree that if the offer-answer model semantic is that here > are >>> several options and any subset of options is acceptable. >>> >>> However, if there is any grouping involved such that you need to have >> a >>> video and audio feed integrated to make sense then watch out. >>> >>> For example, I wouldn't want to end up with the result of a man's >> video >>> paired with a woman's voice. That could be rather comical. >> >> Well, SDP defines that you should ignore what you don't understand and >> operate on what is left. >> >> So someone constructing an SDP with grouping issues such as you define >> ought to keep in mind that this could happen, and set things up so > that >> something reasonable happens. You can't expect the dumb legacy device > to >> >> figure out much. >> >> For your example, the result may be far from ideal, but it still is >> likely to be better than no call at all. And if not, there is always > the >> >> option of hanging up. But better, presumably the offer could have been >> constructed in a way that produced a better result. >> >> Thanks, >> Paul >> >>> Mike >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Paul Kyzivat (pkyzivat) >>> Sent: Tuesday, May 17, 2011 7:45 PM >>> To: Roni Even >>> Cc: clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>> Paul, >>>> I think we read it differently. >>>> If the answerer does not support the group attribute and the offer >> had >>> the >>>> fid semantics it may look to the answerer as an offer with multiple >>> m-lines >>>> of the same media tyoe. In this case an implementation might also >>> decide to >>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>> Acceptable), >>>> because it contains several "m" lines of the same media type. >>> >>> That is a slightly different story. >>> >>> Then the reason for rejection is not because it saw an attribute it >>> didn't understand - its because it didn't like something it *did* >>> understand. >>> >>>> This is very relevant to the multiple streams case and we should > look >>> if we >>>> state this behavior or we will look at providing an approach that >> will >>> allow >>>> the answerer to choose one m-line that the offerer prefers even of > it >>> does >>>> not understand CLUE. >>> >>> IMO (lets see if others differ), if a UA receives an offer with at >> least >>> >>> one m-line it is happy with, then it should not reject the call >> because >>> there are others that it does not "understand". >>> >>> Here "understand" means something different - presumably it does >>> understand the direct meaning of the additional m-line, it just >> doesn't >>> understand the *significance* or use of it. >>> >>> I see little difference to getting to audio m-lines and only wanting >>> one, and getting one audio and one video and only supporting audio. > In >>> general you should not reject an audio/video call just because you >> only >>> support audio. >>> >>> I think it will behoove clue to strongly recommend that the m-lines > in >>> an offer be arranged so the first ones are the ones it most wants > used >>> if not all are. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>> To: Roni Even >>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>> Paul, >>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >> example >>>>>> Roni >>>>> >>>>> OK, I looked. It is consistent with what I said. >>>>> Either a=3Dgroup: is understood, or not. If not, its ignored, and not >>> put >>>>> in the answer. Same with a=3Dmid: >>>>> >>>>> If a=3Dgroup: *is* understood, but some parameter within it is = not, >>> there >>>>> are explicit rules for what to do. >>>>> >>>>> AFAICT there are no examples in this document where failure to >>>>> understand an a-line in total (or even in part) results in > rejecting >>>>> the >>>>> offer. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> Paul Kyzivat >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>> To: Stephen Botzko >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>> >>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>> >>>>>>>> When the offer includes parameters that the answerer >>> does >>>>> not >>>>>>>> understand >>>>>>>> there are two options, he can ignore the unknown >>>>> parameters >>>>>>> or >>>>>>>> reject >>>>>>>> the offer. >>>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>>> You are required to ignore parameters you do not >> understand. >>>>>>>> >>>>>>>> If you reject something because you don't like the >>> parameters >>>>> it >>>>>>>> contains, then that is an implicit statement that you >>>>> understand >>>>>>>> those parameters well enough to decide to reject them. >>>>>>>> >>>>>>>> As far as I know, you are always free to reject offers, and it >>>>>>> doesn't >>>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>>> perhaps >>>>>>>> a different question. >>>>>>>> Stephen Botzko >>>>>>> >>>>>>> Certainly you are always free to reject an offer. >>>>>>> In general I don't know for certain the reason why, and so if I >>> give >>>>>>> you >>>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>>> perhaps >>>>>>> just policy. >>>>>>> >>>>>>> But if the reason you reject the offer is based on your violating >> a >>>>>>> spec, then you are non-conforming, whether I can determine you > are >>>>>>> non-conforming or not. Whether being non-conforming is just >>> un-wise, >>>>> or >>>>>>> something stronger, is a separate discussion. The IETF does not >>> levy >>>>>>> any >>>>>>> penalties for violating its specs. But sometimes the market does. >>>>> (And >>>>>>> sometimes not.) But we don't need to endorse non-conforming >>> behavior >>>>> in >>>>>>> our documents. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> >>>> >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> > From hmmr@cisco.com Thu May 19 07:18:54 2011 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 BB8BBE069B for ; Thu, 19 May 2011 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.869 X-Spam-Level: X-Spam-Status: No, score=-7.869 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 QMGny4WGXxNO for ; Thu, 19 May 2011 07:18:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id EB1E6E066A for ; Thu, 19 May 2011 07:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=32050; q=dns/txt; s=iport; t=1305814732; x=1307024332; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=JZydaXyPwXUtz969o1b091vXWODlQTSkhRXmPwH+UtU=; b=X7X27Bj1Qqg0w20NBlG61ZfCIKjBB1iGp6F2XQ9PfC6+EL06gdcncM0z ZMX+aK+iwiSY6vz4wC/aHcJg4dH45gIgLx/PRo3Tx6LHRVLw/IWzht4No eRSApl/I2BJKakUjW3bb0e45XaORw4qgOlAGQpvq9ESZVpmfnHDkCdKcN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBAP4l1U2tJXHB/2dsb2JhbACCZZRshnABh0x3iHCiYpAfjgGDDQGDCwSGUI15hBOGSA X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208,217";a="234015493" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2011 14:18:50 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4JEIo42017973; Thu, 19 May 2011 14:18:50 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 09:18:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC162F.9BE52FFF" Date: Thu, 19 May 2011 09:18:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwWLor2eaw0T37YTSWyS8FejC8v/wAAMpug References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><4DD3FD0E.8020503@cisco.com><4DD4584E.30405@cisco.com> From: "Mike Hammer (hmmr)" To: "Stephen Botzko" X-OriginalArrivalTime: 19 May 2011 14:18:22.0808 (UTC) FILETIME=[9C471580:01CC162F] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 19 May 2011 14:18:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC162F.9BE52FFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, =20 I was thinking of when you could have more participants than displays and that what gets mapped where is dynamic and may depend on speaker. That might be handled by some other mechanism, but you need starting point to know if an endpoint can handle such signaling. =20 Mike =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Thursday, May 19, 2011 10:11 AM To: Mike Hammer (hmmr) Cc: Paul Kyzivat (pkyzivat); clue@ietf.org Subject: Re: [clue] legacy support in requirements =20 In line Stephen Botzko On Thu, May 19, 2011 at 9:51 AM, Mike Hammer (hmmr) wrote: Paul, What I am trying to say is that Telepresence is all about the end-user experience, and that with multiple microphones, speakers, cameras, displays, and data feeds there is more complexity and chance to screw that up. And a key point is that spatial relationships are significant to the user experience. As a result, more rigor is needed to design the system to ensure that backward compatible means that legacy systems are handled as such. I agree that it is important for CLUE systems to be able to detect if the far end is CLUEless. =20 =20 I am not sure if the protocol design is far enough along to analyze whether correct protocol operation still results in bad user experience, but would suggest that if certain key concepts like spatial awareness are not understood, then that leg needs to devolve to a known legacy state and handled by the MCU as such. That might mean tagging some parameters as mandatory to understand to force the determination and not leave it ambiguous. I think that it is always possible to deliver a bad user experience with correct protocol. Though I agree that we have to make sure the desired interoperable experience is fully enabled, and that we should stick to concepts / modes of operation that are well understood. =20 I believe some current systems treat legacy systems differently and don't expect them to behave like ones that understands the dynamic speaker controls. =20 Not sure what the relevance of dynamic speaker controls is here?? Though maybe it doesn't matter, as I agree that telepresence systems will generally want to adjust their operation when connecting to a legacy system. =20 =20 Mike =09 =09 -----Original Message----- From: Paul Kyzivat (pkyzivat) Sent: Wednesday, May 18, 2011 7:38 PM To: Mike Hammer (hmmr) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] legacy support in requirements =09 =09 =09 On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > Paul, > > Murphy's Law says that if it is possible to put something together the > wrong way, > probability says it will go the wrong way sooner or later. LTC Murphy > had a > young enlisted guy that always found that wrong way to do things. > System-wise, > the black-swan events occur unless you do your best to design them out. > > Machines are often designed so that there is exactly one way to do it. > > We want flexibility in software, but sometimes too much is not so good. > Hopefully, proper operation of the protocol won't look like an error. =09 Mike, =09 I don't understand the point you are trying to make in the context of this conversation. =09 This started out as a discussion of whether it was acceptable to reject an offer because it contains stuff (for the sake of argument lets restrict it to a-lines for now) the the answerer doesn't understand/know =09 anything about. =09 Clearly its *possible* for a UA to do that. And since a UA can reject things for policy reasons, it may be undecidable whether it rejected because of the unknown lines or for some more justifed reason. =09 But still, I think we can *expect* a UA to refrain from doing that. =09 That doesn't mean they all will. But when they don't, its a bug, not a valid implementation choice. =09 Thanks, Paul =09 > Mike > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 18, 2011 1:09 PM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >> Paul, >> >> I would agree that if the offer-answer model semantic is that here are >> several options and any subset of options is acceptable. >> >> However, if there is any grouping involved such that you need to have > a >> video and audio feed integrated to make sense then watch out. >> >> For example, I wouldn't want to end up with the result of a man's > video >> paired with a woman's voice. That could be rather comical. > > Well, SDP defines that you should ignore what you don't understand and > operate on what is left. > > So someone constructing an SDP with grouping issues such as you define > ought to keep in mind that this could happen, and set things up so that > something reasonable happens. You can't expect the dumb legacy device to > > figure out much. > > For your example, the result may be far from ideal, but it still is > likely to be better than no call at all. And if not, there is always the > > option of hanging up. But better, presumably the offer could have been > constructed in a way that produced a better result. > > Thanks, > Paul > >> Mike >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Paul Kyzivat (pkyzivat) >> Sent: Tuesday, May 17, 2011 7:45 PM >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/17/2011 6:05 PM, Roni Even wrote: >>> Paul, >>> I think we read it differently. >>> If the answerer does not support the group attribute and the offer > had >> the >>> fid semantics it may look to the answerer as an offer with multiple >> m-lines >>> of the same media tyoe. In this case an implementation might also >> decide to >>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >> Acceptable), >>> because it contains several "m" lines of the same media type. >> >> That is a slightly different story. >> >> Then the reason for rejection is not because it saw an attribute it >> didn't understand - its because it didn't like something it *did* >> understand. >> >>> This is very relevant to the multiple streams case and we should look >> if we >>> state this behavior or we will look at providing an approach that > will >> allow >>> the answerer to choose one m-line that the offerer prefers even of it >> does >>> not understand CLUE. >> >> IMO (lets see if others differ), if a UA receives an offer with at > least >> >> one m-line it is happy with, then it should not reject the call > because >> there are others that it does not "understand". >> >> Here "understand" means something different - presumably it does >> understand the direct meaning of the additional m-line, it just > doesn't >> understand the *significance* or use of it. >> >> I see little difference to getting to audio m-lines and only wanting >> one, and getting one audio and one video and only supporting audio. In >> general you should not reject an audio/video call just because you > only >> support audio. >> >> I think it will behoove clue to strongly recommend that the m-lines in >> an offer be arranged so the first ones are the ones it most wants used >> if not all are. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>> To: Roni Even >>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> Paul, >>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > example >>>>> Roni >>>> >>>> OK, I looked. It is consistent with what I said. >>>> Either a=3Dgroup: is understood, or not. If not, its ignored, and not >> put >>>> in the answer. Same with a=3Dmid: >>>> >>>> If a=3Dgroup: *is* understood, but some parameter within it is not, >> there >>>> are explicit rules for what to do. >>>> >>>> AFAICT there are no examples in this document where failure to >>>> understand an a-line in total (or even in part) results in rejecting >>>> the >>>> offer. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> To: Stephen Botzko >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>> >>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>> >>>>>>> When the offer includes parameters that the answerer >> does >>>> not >>>>>>> understand >>>>>>> there are two options, he can ignore the unknown >>>> parameters >>>>>> or >>>>>>> reject >>>>>>> the offer. >>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>> You are required to ignore parameters you do not > understand. >>>>>>> >>>>>>> If you reject something because you don't like the >> parameters >>>> it >>>>>>> contains, then that is an implicit statement that you >>>> understand >>>>>>> those parameters well enough to decide to reject them. >>>>>>> >>>>>>> As far as I know, you are always free to reject offers, and it >>>>>> doesn't >>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>> perhaps >>>>>>> a different question. >>>>>>> Stephen Botzko >>>>>> >>>>>> Certainly you are always free to reject an offer. >>>>>> In general I don't know for certain the reason why, and so if I >> give >>>>>> you >>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>> perhaps >>>>>> just policy. >>>>>> >>>>>> But if the reason you reject the offer is based on your violating > a >>>>>> spec, then you are non-conforming, whether I can determine you are >>>>>> non-conforming or not. Whether being non-conforming is just >> un-wise, >>>> or >>>>>> something stronger, is a separate discussion. The IETF does not >> levy >>>>>> any >>>>>> penalties for violating its specs. But sometimes the market does. >>>> (And >>>>>> sometimes not.) But we don't need to endorse non-conforming >> behavior >>>> in >>>>>> our documents. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC162F.9BE52FFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen,

 

I was = thinking of when you could have more participants than displays and that = what gets mapped where is dynamic and may depend on speaker.  That = might be handled by some other mechanism, but you need starting point to = know if an endpoint can handle such signaling.

 

Mike

 

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Thursday, May 19, 2011 10:11 AM
To: Mike Hammer = (hmmr)
Cc: Paul Kyzivat (pkyzivat); = clue@ietf.org
Subject: Re: [clue] legacy support in = requirements

 

In line
Stephen = Botzko

On Thu, May 19, 2011 at = 9:51 AM, Mike Hammer (hmmr) <hmmr@cisco.com> = wrote:

Paul,

What I am trying to say is = that Telepresence is all about the end-user
experience, and that with = multiple microphones, speakers, cameras,
displays, and data feeds = there is more complexity and chance to screw
that up.  And a key = point is that spatial relationships are significant
to the user = experience.  As a result, more rigor is needed to design = the
system to ensure that backward compatible means that legacy = systems are
handled as such.

I agree that it is important for CLUE systems to be = able to detect if the far end is CLUEless.  =
 

I am not sure if the protocol design is = far enough along to analyze
whether correct protocol operation still = results in bad user experience,
but would suggest that if certain key = concepts like spatial awareness
are not understood, then that leg = needs to devolve to a known legacy
state and handled by the MCU as = such.  That might mean tagging some
parameters as mandatory to = understand to force the determination and not
leave it = ambiguous.

I think = that it is always possible to deliver a bad user experience with correct = protocol.

Though I agree that we have to make sure the desired = interoperable experience is fully enabled, and that we should stick to = concepts / modes of operation that are well = understood.
 

I believe = some current systems treat legacy systems differently and
don't = expect them to behave like ones that understands the dynamic
speaker = controls.

 

Not sure what the relevance of dynamic speaker = controls is here??  Though maybe it doesn't matter, as I agree that = telepresence systems will generally want to adjust their operation when = connecting to a legacy system.  =
 

Mike


-----Original Message-----
From: = Paul Kyzivat (pkyzivat)

Sent: Wednesday, May 18, 2011 7:38 PM
To: Mike = Hammer (hmmr)
Cc: Roni Even; clue@ietf.org
Subject: Re: [clue] = legacy support in requirements



On 5/18/2011 3:42 PM, Mike = Hammer (hmmr) wrote:
> Paul,
>
> Murphy's Law says = that if it is possible to put something together the
> wrong = way,
> probability says it will go the wrong way sooner or later. =  LTC Murphy
> had a
> young enlisted guy that always = found that wrong way to do things.
> System-wise,
> the = black-swan events occur unless you do your best to design = them
out.
>
> Machines are often designed so that there = is exactly one way to do it.
>
> We want flexibility in = software, but sometimes too much is not so
good.
> Hopefully, = proper operation of the protocol won't look like an = error.

Mike,

I don't understand the point you are trying = to make in the context of
this conversation.

This started out = as a discussion of whether it was acceptable to reject
an offer = because it contains stuff (for the sake of argument lets
restrict it = to a-lines for now) the the answerer doesn't = understand/know

anything about.

Clearly its *possible* for = a UA to do that. And since a UA can reject
things for policy reasons, = it may be undecidable whether it rejected
because of the unknown = lines or for some more justifed reason.

But still, I think we can = *expect* a UA to refrain from doing that.

That doesn't mean they = all will. But when they don't, its a bug, not a
valid implementation = choice.

       Thanks,
    =    Paul

> Mike
>
> -----Original = Message-----
> From: Paul Kyzivat (pkyzivat)
> Sent: = Wednesday, May 18, 2011 1:09 PM
> To: Mike Hammer (hmmr)
> = Cc: Roni Even; clue@ietf.org
> Subject: Re: = [clue] legacy support in requirements
>
>
>
> On = 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote:
>> = Paul,
>>
>> I would agree that if the offer-answer = model semantic is that here
are
>> several options and any = subset of options is acceptable.
>>
>> However, if = there is any grouping involved such that you need to have
> = a
>> video and audio feed integrated to make sense then watch = out.
>>
>> For example, I wouldn't want to end up with = the result of a man's
> video
>> paired with a woman's = voice.  That could be rather comical.
>
> Well, SDP = defines that you should ignore what you don't understand and
> = operate on what is left.
>
> So someone constructing an SDP = with grouping issues such as you define
> ought to keep in mind = that this could happen, and set things up so
that
> something = reasonable happens. You can't expect the dumb legacy = device
to
>
> figure out much.
>
> For your = example, the result may be far from ideal, but it still is
> = likely to be better than no call at all. And if not, there is = always
the
>
> option of hanging up. But better, = presumably the offer could have been
> constructed in a way that = produced a better result.
>
>       = Thanks,
>       Paul
>
>> = Mike
>>
>>
>> -----Original = Message-----
>> From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf
> Of
>> Paul Kyzivat (pkyzivat)
>> Sent: = Tuesday, May 17, 2011 7:45 PM
>> To: Roni Even
>> Cc: = clue@ietf.org
>> Subject: = Re: [clue] legacy support in = requirements
>>
>>
>>
>> On = 5/17/2011 6:05 PM, Roni Even wrote:
>>> = Paul,
>>> I think we read it differently.
>>> If = the answerer does not support the group attribute and the offer
> = had
>> the
>>> fid semantics it may look to the = answerer as an offer with multiple
>> m-lines
>>> = of the same media tyoe. In this case an implementation might = also
>> decide to
>>> refuse the request (e.g., 488 = Not Acceptable Here, or 606 Not
>> Acceptable),
>>> = because it contains several "m" lines of the same media = type.
>>
>> That is a slightly different = story.
>>
>> Then the reason for rejection is not = because it saw an attribute it
>> didn't understand - its = because it didn't like something it *did*
>> = understand.
>>
>>> This is very relevant to the = multiple streams case and we should
look
>> if = we
>>> state this behavior or we will look at providing an = approach that
> will
>> allow
>>> the = answerer to choose one m-line that the offerer prefers even = of
it
>> does
>>> not understand = CLUE.
>>
>> IMO (lets see if others differ), if a UA = receives an offer with at
> least
>>
>> one = m-line it is happy with, then it should not reject the call
> = because
>> there are others that it does not = "understand".
>>
>> Here = "understand" means something different - presumably it = does
>> understand the direct meaning of the additional m-line, = it just
> doesn't
>> understand the *significance* or use = of it.
>>
>> I see little difference to getting to = audio m-lines and only wanting
>> one, and getting one audio = and one video and only supporting audio.
In
>> general you = should not reject an audio/video call just because you
> = only
>> support audio.
>>
>> I think it will = behoove clue to strongly recommend that the m-lines
in
>> an = offer be arranged so the first ones are the ones it most = wants
used
>> if not all are.
>>
>>   =    Thanks,
>>     =  Paul
>>
>>> = Roni
>>>
>>>> -----Original = Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>>= ;> Sent: Wednesday, May 18, 2011 12:37 AM
>>>> To: = Roni Even
>>>> Cc: 'Stephen Botzko'; clue@ietf.org
>>>> = Subject: Re: [clue] legacy support in = requirements
>>>>
>>>>
>>>><= br>>>>> On 5/17/2011 5:20 PM, Roni Even = wrote:
>>>>> Paul,
>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 = for
> example
>>>>> = Roni
>>>>
>>>> OK, I looked. It is = consistent with what I said.
>>>> Either a=3Dgroup: is = understood, or not. If not, its ignored, and not
>> = put
>>>> in the answer. Same with = a=3Dmid:
>>>>
>>>> If a=3Dgroup: *is* = understood, but some parameter within it is not,
>> = there
>>>> are explicit rules for what to = do.
>>>>
>>>> AFAICT there are no examples = in this document where failure to
>>>> understand an = a-line in total (or even in part) results = in
rejecting
>>>> the
>>>> = offer.
>>>>
>>>>   =  Thanks,
>>>>   =  Paul
>>>>
>>>>>> -----Original = Message-----
>>>>>> From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] = On
>> Behalf
>>>> Of
>>>>>> = Paul Kyzivat
>>>>>> Sent: Tuesday, May 17, 2011 = 6:11 PM
>>>>>> To: Stephen = Botzko
>>>>>> Cc: clue@ietf.org
>>>>>&g= t; Subject: Re: [clue] legacy support in = requirements
>>>>>>
>>>>>>
&= gt;>>>>>
>>>>>> On 5/17/2011 10:34 = AM, Stephen Botzko = wrote:
>>>>>>
>>>>>>> =         On 5/17/2011 2:24 AM, Roni Even = wrote:
>>>>>>
>>>>>>> =             When the offer includes = parameters that the answerer
>> does
>>>> = not
>>>>>>>           =   understand
>>>>>>>       =       there are two options, he can ignore the = unknown
>>>> parameters
>>>>>> = or
>>>>>>>           =   reject
>>>>>>>       =       the offer.
>>>>>>>   =       Rejecting the offer in that case is not really = kosher.
>>>>>>>         You = are required to ignore parameters you do not
> = understand.
>>>>>>>
>>>>>>&g= t;         If you reject something because you don't = like the
>> parameters
>>>> = it
>>>>>>>         contains, = then that is an implicit statement that you
>>>> = understand
>>>>>>>         = those parameters well enough to decide to reject = them.
>>>>>>>
>>>>>>> As = far as I know, you are always free to reject offers, and = it
>>>>>> doesn't
>>>>>>> = really imply anything when you do that..  Whether it is wise = is
>>>>>> perhaps
>>>>>>> a = different question.
>>>>>>> Stephen = Botzko
>>>>>>
>>>>>> Certainly = you are always free to reject an offer.
>>>>>> In = general I don't know for certain the reason why, and so if I
>> = give
>>>>>> you
>>>>>> the = benefit of the doubt I will assume you have a valid reason = -
>>>>>> perhaps
>>>>>> just = policy.
>>>>>>
>>>>>> But if = the reason you reject the offer is based on your violating
> = a
>>>>>> spec, then you are non-conforming, whether = I can determine you
are
>>>>>> non-conforming or = not. Whether being non-conforming is just
>> = un-wise,
>>>> or
>>>>>> something = stronger, is a separate discussion. The IETF does not
>> = levy
>>>>>> any
>>>>>> = penalties for violating its specs. But sometimes the market = does.
>>>> (And
>>>>>> sometimes = not.) But we don't need to endorse non-conforming
>> = behavior
>>>> in
>>>>>> our = documents.
>>>>>>
>>>>>> =  Thanks,
>>>>>> =  Paul
>>>>>> = _______________________________________________
>>>>>&g= t; clue mailing list
>>>>>> clue@ietf.org
>>>>>&g= t; https://www.ietf.org/mailman/listinfo/clue
>&= gt;>>>
>>>>>
>>>
>>>>> _______________________________________________
>> = clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>
_______________________________________________
clue = mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CC162F.9BE52FFF-- From pkyzivat@cisco.com Thu May 19 08:10:27 2011 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 87AD9E07D1 for ; Thu, 19 May 2011 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.357 X-Spam-Level: X-Spam-Status: No, score=-108.357 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8, 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 jzPhdIvN01z1 for ; Thu, 19 May 2011 08:10:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 68EF7E07DF for ; Thu, 19 May 2011 08:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=12256; q=dns/txt; s=iport; t=1305817823; x=1307027423; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7aFWikp+yzERgDfTRKMgn04OGZ6HCa0/co6dkuvUKss=; b=iyHiGN6AockZV8qxlhMYgPDJiOjlzHvql19d6S8b4UdTZleK5e0XbvOD zEDawk3VbejoraiKC+he0g6yDYeKkDj29xSenaljdZ9yh2KfMEOaPZKPp ShXt4eblxQaOWLm2Jjw/HnMNwHFAMSfxbitXHWG4BY4Na7lGjwabMTHOY 4=; X-IronPort-AV: E=Sophos;i="4.65,238,1304294400"; d="scan'208";a="356564037" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 19 May 2011 15:10:22 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4JFALVE021031; Thu, 19 May 2011 15:10:22 GMT Message-ID: <4DD532DD.5050303@cisco.com> Date: Thu, 19 May 2011 11:10:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.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] legacy support in requirements 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, 19 May 2011 15:10:27 -0000 On 5/19/2011 10:11 AM, Mike Hammer (hmmr) wrote: > OK, so you do have some mechanism to discover that the other is clueful. No mechanisms have yet been specified. I certainly think the existing requirements at least imply such discovery. Thanks, Paul > That eases my concerns. > > Mike > > > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Thursday, May 19, 2011 10:08 AM > To: Mike Hammer (hmmr) > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > Mike, > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: >> Paul, >> >> What I am trying to say is that Telepresence is all about the end-user >> experience, and that with multiple microphones, speakers, cameras, >> displays, and data feeds there is more complexity and chance to screw >> that up. And a key point is that spatial relationships are > significant >> to the user experience. As a result, more rigor is needed to design > the >> system to ensure that backward compatible means that legacy systems > are >> handled as such. >> >> I am not sure if the protocol design is far enough along to analyze >> whether correct protocol operation still results in bad user > experience, >> but would suggest that if certain key concepts like spatial awareness >> are not understood, then that leg needs to devolve to a known legacy >> state and handled by the MCU as such. That might mean tagging some >> parameters as mandatory to understand to force the determination and > not >> leave it ambiguous. >> >> I believe some current systems treat legacy systems differently and >> don't expect them to behave like ones that understands the dynamic >> speaker controls. > > I suspect we are talking past each other and are not really in > disagreement. > > I expect that the clue specs, whatever they turn out to be, will require > > support for a bunch of existing sip/sdp mechanisms that are generally > optional and not widely implemented in lower end devices. > > If so, then if we have two clueful systems attempting to connect, we > will be in the realm of negotiating using syntax that both understand. > In that case, this discussion of how to behave when something *isn't* > understood is moot. Rather that situation will arise when we have a > clueful system attempting to connect to a clueless system, or visa > versa. That is where my focus is in this discussion. > > Further into the future, perhaps we will have clue_v2, clue_v3, etc. In > that case, we may again be into a situation where we have a clue_v1_ful > system that doesn't understand something coming from a clue_v2_ful > system. When designing any new protocol for clue_v1, we should keep in > mind to specify how to handle that which isn't understood in order to > support that future scenario. > > Thanks, > Paul > >> Mike >> >> >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, May 18, 2011 7:38 PM >> To: Mike Hammer (hmmr) >> Cc: Roni Even; clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: >>> Paul, >>> >>> Murphy's Law says that if it is possible to put something together > the >>> wrong way, >>> probability says it will go the wrong way sooner or later. LTC > Murphy >>> had a >>> young enlisted guy that always found that wrong way to do things. >>> System-wise, >>> the black-swan events occur unless you do your best to design them >> out. >>> >>> Machines are often designed so that there is exactly one way to do > it. >>> >>> We want flexibility in software, but sometimes too much is not so >> good. >>> Hopefully, proper operation of the protocol won't look like an error. >> >> Mike, >> >> I don't understand the point you are trying to make in the context of >> this conversation. >> >> This started out as a discussion of whether it was acceptable to > reject >> an offer because it contains stuff (for the sake of argument lets >> restrict it to a-lines for now) the the answerer doesn't > understand/know >> >> anything about. >> >> Clearly its *possible* for a UA to do that. And since a UA can reject >> things for policy reasons, it may be undecidable whether it rejected >> because of the unknown lines or for some more justifed reason. >> >> But still, I think we can *expect* a UA to refrain from doing that. >> >> That doesn't mean they all will. But when they don't, its a bug, not a >> valid implementation choice. >> >> Thanks, >> Paul >> >>> Mike >>> >>> -----Original Message----- >>> From: Paul Kyzivat (pkyzivat) >>> Sent: Wednesday, May 18, 2011 1:09 PM >>> To: Mike Hammer (hmmr) >>> Cc: Roni Even; clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: >>>> Paul, >>>> >>>> I would agree that if the offer-answer model semantic is that here >> are >>>> several options and any subset of options is acceptable. >>>> >>>> However, if there is any grouping involved such that you need to > have >>> a >>>> video and audio feed integrated to make sense then watch out. >>>> >>>> For example, I wouldn't want to end up with the result of a man's >>> video >>>> paired with a woman's voice. That could be rather comical. >>> >>> Well, SDP defines that you should ignore what you don't understand > and >>> operate on what is left. >>> >>> So someone constructing an SDP with grouping issues such as you > define >>> ought to keep in mind that this could happen, and set things up so >> that >>> something reasonable happens. You can't expect the dumb legacy device >> to >>> >>> figure out much. >>> >>> For your example, the result may be far from ideal, but it still is >>> likely to be better than no call at all. And if not, there is always >> the >>> >>> option of hanging up. But better, presumably the offer could have > been >>> constructed in a way that produced a better result. >>> >>> Thanks, >>> Paul >>> >>>> Mike >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>> Paul Kyzivat (pkyzivat) >>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>> Paul, >>>>> I think we read it differently. >>>>> If the answerer does not support the group attribute and the offer >>> had >>>> the >>>>> fid semantics it may look to the answerer as an offer with multiple >>>> m-lines >>>>> of the same media tyoe. In this case an implementation might also >>>> decide to >>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>> Acceptable), >>>>> because it contains several "m" lines of the same media type. >>>> >>>> That is a slightly different story. >>>> >>>> Then the reason for rejection is not because it saw an attribute it >>>> didn't understand - its because it didn't like something it *did* >>>> understand. >>>> >>>>> This is very relevant to the multiple streams case and we should >> look >>>> if we >>>>> state this behavior or we will look at providing an approach that >>> will >>>> allow >>>>> the answerer to choose one m-line that the offerer prefers even of >> it >>>> does >>>>> not understand CLUE. >>>> >>>> IMO (lets see if others differ), if a UA receives an offer with at >>> least >>>> >>>> one m-line it is happy with, then it should not reject the call >>> because >>>> there are others that it does not "understand". >>>> >>>> Here "understand" means something different - presumably it does >>>> understand the direct meaning of the additional m-line, it just >>> doesn't >>>> understand the *significance* or use of it. >>>> >>>> I see little difference to getting to audio m-lines and only wanting >>>> one, and getting one audio and one video and only supporting audio. >> In >>>> general you should not reject an audio/video call just because you >>> only >>>> support audio. >>>> >>>> I think it will behoove clue to strongly recommend that the m-lines >> in >>>> an offer be arranged so the first ones are the ones it most wants >> used >>>> if not all are. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>> To: Roni Even >>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>> Paul, >>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>> example >>>>>>> Roni >>>>>> >>>>>> OK, I looked. It is consistent with what I said. >>>>>> Either a=group: is understood, or not. If not, its ignored, and > not >>>> put >>>>>> in the answer. Same with a=mid: >>>>>> >>>>>> If a=group: *is* understood, but some parameter within it is not, >>>> there >>>>>> are explicit rules for what to do. >>>>>> >>>>>> AFAICT there are no examples in this document where failure to >>>>>> understand an a-line in total (or even in part) results in >> rejecting >>>>>> the >>>>>> offer. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf >>>>>> Of >>>>>>>> Paul Kyzivat >>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>> To: Stephen Botzko >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>> >>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>> >>>>>>>>> When the offer includes parameters that the > answerer >>>> does >>>>>> not >>>>>>>>> understand >>>>>>>>> there are two options, he can ignore the unknown >>>>>> parameters >>>>>>>> or >>>>>>>>> reject >>>>>>>>> the offer. >>>>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>>>> You are required to ignore parameters you do not >>> understand. >>>>>>>>> >>>>>>>>> If you reject something because you don't like the >>>> parameters >>>>>> it >>>>>>>>> contains, then that is an implicit statement that you >>>>>> understand >>>>>>>>> those parameters well enough to decide to reject them. >>>>>>>>> >>>>>>>>> As far as I know, you are always free to reject offers, and it >>>>>>>> doesn't >>>>>>>>> really imply anything when you do that.. Whether it is wise is >>>>>>>> perhaps >>>>>>>>> a different question. >>>>>>>>> Stephen Botzko >>>>>>>> >>>>>>>> Certainly you are always free to reject an offer. >>>>>>>> In general I don't know for certain the reason why, and so if I >>>> give >>>>>>>> you >>>>>>>> the benefit of the doubt I will assume you have a valid reason - >>>>>>>> perhaps >>>>>>>> just policy. >>>>>>>> >>>>>>>> But if the reason you reject the offer is based on your > violating >>> a >>>>>>>> spec, then you are non-conforming, whether I can determine you >> are >>>>>>>> non-conforming or not. Whether being non-conforming is just >>>> un-wise, >>>>>> or >>>>>>>> something stronger, is a separate discussion. The IETF does not >>>> levy >>>>>>>> any >>>>>>>> penalties for violating its specs. But sometimes the market > does. >>>>>> (And >>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>> behavior >>>>>> in >>>>>>>> our documents. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >> > From stephane.cazeaux@orange-ftgroup.com Thu May 19 08:42:06 2011 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 D8E77E0753 for ; Thu, 19 May 2011 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fzvEBh-RkZk for ; Thu, 19 May 2011 08:42:01 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 35BA8E0804 for ; Thu, 19 May 2011 08:41:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF41FFC400D; Thu, 19 May 2011 17:41:58 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 988EDFC400C; Thu, 19 May 2011 17:41:58 +0200 (CEST) Received: from ftrdhub2.rd.francetelecom.fr ([10.193.109.194]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 17:41:58 +0200 Received: from FTRDCH02.rd.francetelecom.fr (10.194.32.13) by ftrdhub2.rd.francetelecom.fr (10.193.109.194) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 May 2011 17:41:57 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Thu, 19 May 2011 17:41:57 +0200 From: To: Thread-Topic: [clue] Definitions Thread-Index: AcwVbE+a146t/LGk30ms//XJA7T93AAEzhdQABzTIRAABGw4AAAMWiVg Date: Thu, 19 May 2011 15:41:57 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.166] Content-Type: multipart/alternative; boundary="_000_FEE7A6136F518B4B87037A58924AB6B0A7C66BFTRDMB03rdfrancet_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 May 2011 15:41:58.0406 (UTC) FILETIME=[49CE9A60:01CC163B] Cc: clue@ietf.org Subject: Re: [clue] Definitions 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, 19 May 2011 15:42:07 -0000 --_000_FEE7A6136F518B4B87037A58924AB6B0A7C66BFTRDMB03rdfrancet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, Please see inline. St=E9phane. De : Stephen Botzko [mailto:stephen.botzko@gmail.com] Envoy=E9 : jeudi 19 mai 2011 13:10 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : Mark.Duckworth@polycom.com; stewe@stewe.org; clue@ietf.org Objet : Re: [clue] Definitions I am confused about how CLUE can make interoperability with proprietary sys= tems a requirement [or a consideration]. [SC] We all agree that interoperability with proprietary systems is explici= tly out of scope of the charter. This is not the purpose of the discussion = here (sorry if I was confusing on that point). There is quite broad consensus among manufacturers that a single UA is the = right approach for standardization. [SCa] I am ok with this consensus. Actually, the suggestion to support tele= presence rooms made of multiple SIP UAs does not intend to replace the sing= le SIP UA approach. Instead, it intends to be an alternative. The systems in the room need to be highly integrated to create the telepres= ence experience, and external telepresence MCUs need to have explicit knowl= edge about what systems are in what rooms, and how the systems are arranged= within the room. [SCa] I do not agree with this argument. CLUE targets any endpoint from a f= ull and high-cost telepresence room to a simple handheld device. I don't th= ink that we can have the same level of integration, thus telepresence exper= ience, with all endpoints. Quoting draft-romanow-clue-telepresence-use-cases-01.txt (section 4.6.) " The importance of this example is that the multiple video streams are not used to create an immersive conferencing experience with panoramic views at all the site. Instead the multiple streams are dynamically used to enable full participation of remote students in a university class. " This use case is interesting, especially because it leverages the teleprese= nce multi-screen. We could have cases where we setup endpoints in the main = site, with endpoints that all have different capabilities. For instance: on= e endpoint presents a regular HD video of the participants, another with a = 3D video of a concept, etc... But a the end, all these endpoints are in the= same telepresence room, and obviously in a same telepresence conference (b= tw. I don't see the case where these endpoints are connected to different c= onferences). If we don't consider the alternative of having multiple SIP UA= (i.e. multiple endpoints) in a same room, I don't think we can realize suc= h (advanced) cases. Coordinated management of the endpoints is problematic. Even simple dialin= g between rooms becomes complicated. Stephen Botzko On Thu, May 19, 2011 at 3:17 AM, > wrote: Hi Mark, Stephan, On my side, I think we should consider cases where we have several SIP UAs = in a single telepresence room. Another discussion is to define the relation between an endpoint and a SIP = UA. IMO, we should define an endpoint as composed of one single SIP UA, and= the endpoint represents all equipment associated to the SIP UA (including = multi-screen/camera). Thus we should consider cases where a telepresence room is composed of seve= ral endpoints. As I suggested in a previous mail, I think that such cases w= ill necessarily exist, with proprietary implementations (thus not interoper= able) in MCU to associate several endpoints so that they form a single tele= presence room. That's why we should consider these cases to have interopera= bility rules. Stephane. -----Message d'origine----- De : clue-bounces@ietf.org [mailto:clue-bounc= es@ietf.org] De la part de Duckworth, Mark Envoy=E9 : mercredi 18 mai 2011 19:27 =C0 : Stephan Wenger; clue@ietf.org Objet : Re: [clue] Definitions Stephan, My understanding is an endpoint has a single SIP UA. And there would be on= ly one endpoint in a room. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Wednesday, May 18, 2011 2:00 AM > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > eckelcu@cisco.com; clue@ietf.org > Subject: Re: [clue] Definitions > > Hi Stephane, > Very good point. > > Quoting from RFC 4353 > > [...] > Participant: The software element that connects a user or automat= a to > a conference. It implements, at a minimum, a SIP user agent, but > may also implement non-SIP-specific mechanisms for additional > functionality. > [...] > > My understanding of "endpoint" is that an endpoint encompasses ALL > equipment in a telepresence room. I believe that there are cases where w= e > can have multiple SIP user agents (Uas) in one room. Think of a bunch of > codec boxes in a rack, all having their own UA. Is this the common > understanding of the group? > > To ask the question differently, do we have an agreement that there is a > single SIP UA in one room? > > Guidance, please. > > Thanks, > Stephan > > > > > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > > wrote: > > >I don't think that we want to limit the "endpoint" definition to > entities > >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need to > >understand characteristics of the remote, and could maybe have also > some > >characteristics. I don't think we want to exclude such cases. > > > >Relying on the "participant" definition of RFC4353, a telepresence > >conference will be composed of "participants", where a participant is > >connected to the conference through an "endpoint". In telepresence, > the > >participant will have to be aware of the endpoint, in particular when > the > >participant needs to inform the remote of the characteristics of its > >endpoint. > > > >Thus my proposition is to clarify that "endpoint" defines the entity > >through which a participant (we do not limit to entity facing a user) > is > >connected to a telepresence conference. > > > >In the same manner, we could also use the "mixer" word instead of > "MCU". > > > >Most of requirements should then apply on the participant or mixer > >(typically, a participant will describe characteristics of its > endpoint). > > > > > >Regards, > >Stephane. > > > > > >-----Message d'origine----- > >De : clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] De la part > de > >Espen Berger (espeberg) > >Envoy=E9 : mercredi 18 mai 2011 10:40 > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > >Objet : Re: [clue] Definitions > > > >I think we should keep both endpoints and MCUs in the definition > >document. > > > >One difference between endpoints and MCUs are how they handle media. > An > >endpoint usually send media representing itself and MCUs send media on > >behalf of others remote endpoint connected. > > > >Cheers > > > >-Espen > > > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf > Of > >Stephan Wenger > >Sent: 17. mai 2011 06:17 > >To: Charles Eckel (eckelcu); CLUE > >Subject: Re: [clue] Definitions > > > >Hi Charles, > >Please see inline. > >In summary, I'm not convinced there is need for a change, though there > >may > >be need for more explanatory text. > >Stephan > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > > >wrote: > > > >>Hi Stephan, > >> > >>This is a great start. I do not know if you volunteered to update as > >>well as provide the initial version of this document. In any case, > here > >>are some comments. > >> > >>> Endpoint - The logical point of final termination through > >>> receiving, decoding and rendering, and/or initiation through > >>> capturing, encoding, and sending of media streams. An endpoint > >>> consists of one or more physical devices which source and sink > >>> media streams. In contrast to an endpoint, a middle box, such > >>> as an MCU, may also send and receive media streams, but it is > >>> not the initiator nor the final terminator. > >> > >>I am not sure we should differentiate between endpoint and MCU. The > >>distinction blurs in that an MCU generates and send media streams > that > >>are not necessarily equivalent to those it received, and it receives > >>input from other endpoints. I think trying to distinguish them simply > >>makes more work and add complexity. I also think we will find that > the > >>majority of "MCUs" are really more "endpoints" than "MCUs". > >>You introduced the concept of remote. I am proposing remote =3D=3D > endpoint > >>and remove MCU. > > > >Not sure here. > >What "endpoint" attempts to express is that it is the logical entity > >facing the user--the room including microphones loudspeakers, screens, > >cameras, and some technical stuff that sends and receives RTP streams > >and > >implements signaling. We need such a definition certainly in the > >requirement spec but also in the use cases. There is also a "local" > >endpoint, which prohibits the use of "remote". > >I think we should leave this definition alone. > > > >> > >>> Media - Any data that, after suitable encoding, can be conveyed > >>> over RTP, including audio, video or timed text. > >> > >>I think this is too general, but I am not able to suggest a good way > to > >>improve it. > > > >Again, not sure why this is too general. > > > >> > >>> Session - RTP session. An association among a set of > >>> participants communicating with RTP. The distinguishing feature > >>> of an RTP session is that each maintains a full, separate space > >>> of SSRC identifiers. [RFC3550] > >> > >>In this case, do we also need a term for the collection of RTP > sessions > >>the contains the complete set media exchanged between two endpoints? > > > >Perhaps, though I don't think we have seen that need yet. > >Pm the media plane, there is really no such thing as "bundling" of > media > >transmission channels. There is a logical connection between multiple > >sessions, but only in the signaling. > > > >> > >> > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > >A Layout is the aggregation of all spatial relations of all > >capture/renderer devices at a given point in time? > >"Left speaker is left from right speaker" is a spatial relation. > >"Left microphone is co-located with left camera" is a spatial > relation. > >"Audio channel 1 is left, audio channel 2 is right, and there is only > >one > >center camera" is a layout. > > > >> > >>Cheers, > >>Charles > >> > >> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clu= e-bounces@ietf.org] On > Behalf > >>Of Stephan Wenger > >>> Sent: Friday, May 13, 2011 11:08 AM > >>> To: CLUE > >>> Subject: [clue] Definitions > >>> > >>> Hi folks, > >>> Here a VERY rough initial draft. Addressing typos, sorting to > >>alphabetical, and other cleanup tasks > >>> will have to wait for the my return to the office next week. I > will > >>submit officially only after the > >>> most embarrassing bugs are sorted out. No need to comment on > typos, > >>but if you have substantial > >>> issues then send them now, and I can address them immediately. > >>> Stephan > >> > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ 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_FEE7A6136F518B4B87037A58924AB6B0A7C66BFTRDMB03rdfrancet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stephen= ,

 = ;

Please see= inline.

 = ;

 = ;

St=E9phane= .

 = ;

De : Stephen Botzko [mailto:stephen.botzko@gmail.com]
Envoy=E9 : jeudi 19 mai 2011 13:10
=C0 : CAZEAUX Stephane RD-BIZZ-CAE
Cc : Mark.Duckworth@polycom.com; stewe@stewe.org; clue@ietf.org=
Objet : Re: [clue] Definitions

 

= I am confused about how CLUE can make interoperability with proprietary sys= tems a requirement [or a consideration].=

[SC] We all agree that interoperability with proprieta= ry systems is explicitly out of scope of the charter. This is not the purpose of the discussion here (sorry if I was confusing on that p= oint).

=
There is quite broad consensus among manufacturers that a single UA is the = right approach for standardization. 

[SCa] I am ok with this consensus. Actually, the sugge= stion to support telepresence rooms made of multiple SIP UAs does not intend to replace the single SIP UA approach. Instead, it intends= to be an alternative.

= The systems in the room need to be highly integrated to create the telepres= ence experience, and external telepresence MCUs need to have explicit knowl= edge about what systems are in what rooms, and how the systems are arranged within the room.  =

[SCa] I do not agree with this argument. CLUE targets = any endpoint from a full and high-cost telepresence room to a simple handheld device. I don’t think that we can have the same le= vel of integration, thus telepresence experience, with all endpoints.

Quoting draft-romanow-clue-telepresence-use-cases-01.t= xt (section 4.6.)

“

The import= ance of this example is that the multiple video streams are

 &nbs= p; not used to create an immersive conferencing experience with<= /span>

 &nbs= p; panoramic views at all the site.  Instead the multiple streams are<= o:p>

 &nbs= p; dynamically used to enable full participation of remote students in a

 &nbs= p; university class.

“

This use case is interesting, especially because it le= verages the telepresence multi-screen. We could have cases where we setup endpoints in the main site, with endpoints that all have differen= t capabilities. For instance: one endpoint presents a regular HD video of t= he participants, another with a 3D video of a concept, etc… But a the= end, all these endpoints are in the same telepresence room, and obviously in a same telepresence conference (btw. I= don’t see the case where these endpoints are connected to different = conferences). If we don’t consider the alternative of having multiple= SIP UA (i.e. multiple endpoints) in a same room, I don’t think we can realize such (advanced) cases.

 

=  

=  

= Coordinated management of the endpoints is problematic.  Even simple d= ialing between rooms becomes complicated.

=

Stephen Botzko

On Thu, May 19, 2011 at 3:17 AM= , <stephane.cazeaux@orange-ftgroup.com> wrote:

Hi Mark, Stephan,

On my side, I think we should consider cases where we have several SIP UAs = in a single telepresence room.

Another discussion is to define the relation between an endpoint and a SIP = UA. IMO, we should define an endpoint as composed of one single SIP UA, and= the endpoint represents all equipment associated to the SIP UA (including = multi-screen/camera).

Thus we should consider cases where a telepresence room is composed of seve= ral endpoints. As I suggested in a previous mail, I think that such cases w= ill necessarily exist, with proprietary implementations (thus not interoper= able) in MCU to associate several endpoints so that they form a single telepresence room. That's why we shou= ld consider these cases to have interoperability rules.


Stephane.

-----Message d'origine-----
De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Duckworth, Mark
Envoy=E9 : mercredi 18 mai 2011 19:27
=C0 : Stephan Wenger; clue@ietf.org
Objet : Re: [clue] Definitions


Stephan,

My understanding is an endpoint has a single SIP UA.  And there would = be only one endpoint in a room.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Stephan Wenger
> Sent: Wednesday, May 18, 2011 2:00 AM
> To: stephane.cazeaux@orange-ftgroup.com; espeberg@= cisco.com;
> eckel= cu@cisco.com; clue@ietf.org<= /span>
> Subject: Re: [clue] Definitions
>
> Hi Stephane,
> Very good point.
>
> Quoting from RFC 4353
>
> [...]
>         Participant: The software element that con= nects a user or automata to
>         a conference.  It implements, at a mi= nimum, a SIP user agent, but
>         may also implement non-SIP-specific mechan= isms for additional
>         functionality.
> [...]
>
> My understanding of "endpoint" is that an endpoint encompass= es ALL
> equipment in a telepresence room.  I believe that there are cases= where we
> can have multiple SIP user agents (Uas) in one room.  Think of a = bunch of
> codec boxes in a rack, all having their own UA.  Is this the comm= on
> understanding of the group?
>
> To ask the question differently, do we have an agreement that there is= a
> single SIP UA in one room?
>
> Guidance, please.
>
> Thanks,
> Stephan
>
>
>
>
> On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com= "
> <stephane.cazeaux@orange-ftgroup.com> wrote:
>
> >I don't think that we want to limit the "endpoint" defin= ition to
> entities
> >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need t= o
> >understand characteristics of the remote, and could maybe have als= o
> some
> >characteristics. I don't think we want to exclude such cases.
> >
> >Relying on the "participant" definition of RFC4353, a te= lepresence
> >conference will be composed of "participants", where a p= articipant is
> >connected to the conference through an "endpoint". In te= lepresence,
> the
> >participant will have to be aware of the endpoint, in particular w= hen
> the
> >participant needs to inform the remote of the characteristics of i= ts
> >endpoint.
> >
> >Thus my proposition is to clarify that "endpoint" define= s the entity
> >through which a participant (we do not limit to entity facing a us= er)
> is
> >connected to a telepresence conference.
> >
> >In the same manner, we could also use the "mixer" word i= nstead of
> "MCU".
> >
> >Most of requirements should then apply on the participant or mixer=
> >(typically, a participant will describe characteristics of its
> endpoint).
> >
> >
> >Regards,
> >Stephane.
> >
> >
> >-----Message d'origine-----
> >De : clue-bounces@ietf.org [mailto:clue-bounce= s@ietf.org] De la part
> de
> >Espen Berger (espeberg)
> >Envoy=E9 : mercredi 18 mai 2011 10:40
> >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE
> >Objet : Re: [clue] Definitions
> >
> >I think we should keep both endpoints and MCUs in the definition > >document.
> >
> >One difference between endpoints and MCUs are how they handle medi= a.
> An
> >endpoint usually send media representing itself and MCUs send medi= a on
> >behalf of others remote endpoint connected.
> >
> >Cheers
> >
> >-Espen
> >
> >
> >-----Original Message-----
> >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf
> Of
> >Stephan Wenger
> >Sent: 17. mai 2011 06:17
> >To: Charles Eckel (eckelcu); CLUE
> >Subject: Re: [clue] Definitions
> >
> >Hi Charles,
> >Please see inline.
> >In summary, I'm not convinced there is need for a change, though t= here
> >may
> >be need for more explanatory text.
> >Stephan
> >
> >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.c= om>
> >wrote:
> >
> >>Hi Stephan,
> >>
> >>This is a great start. I do not know if you volunteered to upd= ate as
> >>well as provide the initial version of this document. In any c= ase,
> here
> >>are some comments.
> >>
> >>> Endpoint - The logical point of final termination through=
> >>> receiving, decoding and rendering, and/or initiation thro= ugh
> >>> capturing, encoding, and sending of media streams.  = An endpoint
> >>> consists of one or more physical devices which source and= sink
> >>> media streams.  In contrast to an endpoint, a middle= box, such
> >>> as an MCU, may also send and receive media streams, but i= t is
> >>> not the initiator nor the final terminator.
> >>
> >>I am not sure we should differentiate between endpoint and MCU= . The
> >>distinction blurs in that an MCU generates and send media stre= ams
> that
> >>are not necessarily equivalent to those it received, and it re= ceives
> >>input from other endpoints. I think trying to distinguish them= simply
> >>makes more work and add complexity. I also think we will find = that
> the
> >>majority of "MCUs" are really more "endpoints&q= uot; than "MCUs".
> >>You introduced the concept of remote. I am proposing remote = =3D=3D
> endpoint
> >>and remove MCU.
> >
> >Not sure here.
> >What "endpoint" attempts to express is that it is the lo= gical entity
> >facing the user--the room including microphones loudspeakers, scre= ens,
> >cameras, and some technical stuff that sends and receives RTP stre= ams
> >and
> >implements signaling.  We need such a definition certainly in= the
> >requirement spec but also in the use cases.  There is also a = "local"
> >endpoint, which prohibits the use of "remote".
> >I think we should leave this definition alone.
> >
> >>
> >>> Media - Any data that, after suitable encoding, can be co= nveyed
> >>> over RTP, including audio, video or timed text.
> >>
> >>I think this is too general, but I am not able to suggest a go= od way
> to
> >>improve it.
> >
> >Again, not sure why this is too general.
> >
> >>
> >>> Session - RTP session.  An association among a set o= f
> >>> participants communicating with RTP.  The distinguis= hing feature
> >>> of an RTP session is that each maintains a full, separate= space
> >>> of SSRC identifiers.  [RFC3550]
> >>
> >>In this case, do we also need a term for the collection of RTP=
> sessions
> >>the contains the complete set media exchanged between two endp= oints?
> >
> >Perhaps, though I don't think we have seen that need yet.
> >Pm the media plane, there is really no such thing as "bundlin= g" of
> media
> >transmission channels.  There is a logical connection between= multiple
> >sessions, but only in the signaling.
> >
> >>
> >>
> >>"Layouts" vs. "Spatial Relations", what is= the difference?
> >
> >A Layout is the aggregation of all spatial relations of all
> >capture/renderer devices at a given point in time?
> >"Left speaker is left from right speaker" is a spatial r= elation.
> >"Left microphone is co-located with left camera" is a sp= atial
> relation.
> >"Audio channel 1 is left, audio channel 2 is right, and there= is only
> >one
> >center camera" is a layout.
> >
> >>
> >>Cheers,
> >>Charles
> >>
> >>
> >>> -----Original Message-----
> >>> From: clue-bounces@ietf.org [ma= ilto:c= lue-bounces@ietf.org] On
> Behalf
> >>Of Stephan Wenger
> >>> Sent: Friday, May 13, 2011 11:08 AM
> >>> To: CLUE
> >>> Subject: [clue] Definitions
> >>>
> >>> Hi folks,
> >>> Here a VERY rough initial draft.  Addressing typos, = sorting to
> >>alphabetical, and other cleanup tasks
> >>> will have to wait for the my return to the office next we= ek.  I
> will
> >>submit officially only after the
> >>> most embarrassing bugs are sorted out.  No need to c= omment on
> typos,
> >>but if you have substantial
> >>> issues then send them now, and I can address them immedia= tely.
> >>> Stephan
> >>
> >
> >
> >_______________________________________________
> >clue mailing list
> >clue@= ietf.org
> >https://www.ietf.org/mailman/listinfo/cl= ue
> >_______________________________________________
> >clue mailing list
> >clue@= ietf.org
> >https://www.ietf.org/mailman/listinfo/cl= ue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf= .org
> https://www.ietf.org/mailman/listinfo/clue=
_______________________________________________
clue mailing list
clue@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/clue=
_______________________________________________
clue mailing list
clue@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/clue=

 

--_000_FEE7A6136F518B4B87037A58924AB6B0A7C66BFTRDMB03rdfrancet_-- From stephen.botzko@gmail.com Thu May 19 08:51:28 2011 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 AEB84E0814 for ; Thu, 19 May 2011 08:51:28 -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 dDXy++y70ycU for ; Thu, 19 May 2011 08:51:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4AE080F for ; Thu, 19 May 2011 08:51:25 -0700 (PDT) Received: by vxg33 with SMTP id 33so2409318vxg.31 for ; Thu, 19 May 2011 08:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H2MFrvELf/gZMTxrf+J/GpF9KoxEuAaDOlNWqND90RQ=; b=Afy8IrM1YzFseGl+isBsuCZzWgtvuJhPKUOAbQL20wZFON2GqIN73L7klOfZe/3wog Ftg2JyS+++NvLyoQfczVC1aKvxFMonM9k27Q/QNcH7f1YkHYjnHqxQWjMiLvtuGDhX3v 0SQ3b+tljXsyYb8qtQDyt42Y0LkJyCjExzuRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QYuRwsWbe5yCpxesPgWbdnus3luiYxUwy5MrH//AmXCTopAo7sUSb0PVzmoZPK7hje TIKbkxX74dQQn+moQsfV5YtIDYZY7yliqc25xYDeE540vWQ3ssk6PAlwunsfr+3ZLd7z AGZEqV73JE7U8bsd6NFmGvwTI7hkUnxdlXhR8= MIME-Version: 1.0 Received: by 10.52.101.195 with SMTP id fi3mr4662803vdb.156.1305820285153; Thu, 19 May 2011 08:51:25 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Thu, 19 May 2011 08:51:25 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A61AC06256D@CRPMBOXPRD01.polycom.com> Date: Thu, 19 May 2011 11:51:25 -0400 Message-ID: From: Stephen Botzko To: stephane.cazeaux@orange-ftgroup.com Content-Type: multipart/alternative; boundary=bcaec548a4133cb14904a3a2fa34 Cc: clue@ietf.org Subject: Re: [clue] Definitions 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, 19 May 2011 15:51:28 -0000 --bcaec548a4133cb14904a3a2fa34 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oddly enough I wrote the use case you quote. I don't see the need for multiple SIP UAs to realize it. If you've ever operated multiple endpoints independently in the same room, you'll realize that you get echo and potentially other problems. I think we should go with Stephan's recommendation for now. Explicitly use a single SIP UA for this set of definitions, and we can deal with other cases later on. Stephen. On Thu, May 19, 2011 at 11:41 AM, wrot= e: > Hi Stephen, > > > > Please see inline. > > > > > > St=E9phane. > > > > *De :* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Envoy=E9 :* jeudi 19 mai 2011 13:10 > *=C0 :* CAZEAUX Stephane RD-BIZZ-CAE > *Cc :* Mark.Duckworth@polycom.com; stewe@stewe.org; clue@ietf.org > *Objet :* Re: [clue] Definitions > > > > I am confused about how CLUE can make interoperability with proprietary > systems a requirement [or a consideration]. > > [SC] We all agree that interoperability with proprietary systems is > explicitly out of scope of the charter. This is not the purpose of the > discussion here (sorry if I was confusing on that point). > > > There is quite broad consensus among manufacturers that a single UA is th= e > right approach for standardization. > > [SCa] I am ok with this consensus. Actually, the suggestion to support > telepresence rooms made of multiple SIP UAs does not intend to replace th= e > single SIP UA approach. Instead, it intends to be an alternative. > > The systems in the room need to be highly integrated to create the > telepresence experience, and external telepresence MCUs need to have > explicit knowledge about what systems are in what rooms, and how the syst= ems > are arranged within the room. > > [SCa] I do not agree with this argument. CLUE targets any endpoint from a > full and high-cost telepresence room to a simple handheld device. I don= =92t > think that we can have the same level of integration, thus telepresence > experience, with all endpoints. > > Quoting draft-romanow-clue-telepresence-use-cases-01.txt (section 4.6.) > > =93 > > The importance of this example is that the multiple video streams are > > not used to create an immersive conferencing experience with > > panoramic views at all the site. Instead the multiple streams are > > dynamically used to enable full participation of remote students in a > > university class. > > =93 > > This use case is interesting, especially because it leverages the > telepresence multi-screen. We could have cases where we setup endpoints i= n > the main site, with endpoints that all have different capabilities. For > instance: one endpoint presents a regular HD video of the participants, > another with a 3D video of a concept, etc=85 But a the end, all these > endpoints are in the same telepresence room, and obviously in a same > telepresence conference (btw. I don=92t see the case where these endpoint= s are > connected to different conferences). If we don=92t consider the alternati= ve of > having multiple SIP UA (i.e. multiple endpoints) in a same room, I don=92= t > think we can realize such (advanced) cases. > > > > > > > > Coordinated management of the endpoints is problematic. Even simple > dialing between rooms becomes complicated. > > > > Stephen Botzko > > On Thu, May 19, 2011 at 3:17 AM, > wrote: > > Hi Mark, Stephan, > > On my side, I think we should consider cases where we have several SIP UA= s > in a single telepresence room. > > Another discussion is to define the relation between an endpoint and a SI= P > UA. IMO, we should define an endpoint as composed of one single SIP UA, a= nd > the endpoint represents all equipment associated to the SIP UA (including > multi-screen/camera). > > Thus we should consider cases where a telepresence room is composed of > several endpoints. As I suggested in a previous mail, I think that such > cases will necessarily exist, with proprietary implementations (thus not > interoperable) in MCU to associate several endpoints so that they form a > single telepresence room. That's why we should consider these cases to ha= ve > interoperability rules. > > > Stephane. > > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de > Duckworth, Mark > Envoy=E9 : mercredi 18 mai 2011 19:27 > =C0 : Stephan Wenger; clue@ietf.org > Objet : Re: [clue] Definitions > > > Stephan, > > My understanding is an endpoint has a single SIP UA. And there would be > only one endpoint in a room. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Stephan Wenger > > Sent: Wednesday, May 18, 2011 2:00 AM > > To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com; > > eckelcu@cisco.com; clue@ietf.org > > Subject: Re: [clue] Definitions > > > > Hi Stephane, > > Very good point. > > > > Quoting from RFC 4353 > > > > [...] > > Participant: The software element that connects a user or > automata to > > a conference. It implements, at a minimum, a SIP user agent, b= ut > > may also implement non-SIP-specific mechanisms for additional > > functionality. > > [...] > > > > My understanding of "endpoint" is that an endpoint encompasses ALL > > equipment in a telepresence room. I believe that there are cases where > we > > can have multiple SIP user agents (Uas) in one room. Think of a bunch = of > > codec boxes in a rack, all having their own UA. Is this the common > > understanding of the group? > > > > To ask the question differently, do we have an agreement that there is = a > > single SIP UA in one room? > > > > Guidance, please. > > > > Thanks, > > Stephan > > > > > > > > > > On 5.18.2011 12:46 , "stephane.cazeaux@orange-ftgroup.com" > > wrote: > > > > >I don't think that we want to limit the "endpoint" definition to > > entities > > >facing a user. We could have entities not facing a user (e.g. an > > >automata), but which are sending/receiving media, and which need to > > >understand characteristics of the remote, and could maybe have also > > some > > >characteristics. I don't think we want to exclude such cases. > > > > > >Relying on the "participant" definition of RFC4353, a telepresence > > >conference will be composed of "participants", where a participant is > > >connected to the conference through an "endpoint". In telepresence, > > the > > >participant will have to be aware of the endpoint, in particular when > > the > > >participant needs to inform the remote of the characteristics of its > > >endpoint. > > > > > >Thus my proposition is to clarify that "endpoint" defines the entity > > >through which a participant (we do not limit to entity facing a user) > > is > > >connected to a telepresence conference. > > > > > >In the same manner, we could also use the "mixer" word instead of > > "MCU". > > > > > >Most of requirements should then apply on the participant or mixer > > >(typically, a participant will describe characteristics of its > > endpoint). > > > > > > > > >Regards, > > >Stephane. > > > > > > > > >-----Message d'origine----- > > >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > > de > > >Espen Berger (espeberg) > > >Envoy=E9 : mercredi 18 mai 2011 10:40 > > >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE > > >Objet : Re: [clue] Definitions > > > > > >I think we should keep both endpoints and MCUs in the definition > > >document. > > > > > >One difference between endpoints and MCUs are how they handle media. > > An > > >endpoint usually send media representing itself and MCUs send media on > > >behalf of others remote endpoint connected. > > > > > >Cheers > > > > > >-Espen > > > > > > > > >-----Original Message----- > > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > >Stephan Wenger > > >Sent: 17. mai 2011 06:17 > > >To: Charles Eckel (eckelcu); CLUE > > >Subject: Re: [clue] Definitions > > > > > >Hi Charles, > > >Please see inline. > > >In summary, I'm not convinced there is need for a change, though there > > >may > > >be need for more explanatory text. > > >Stephan > > > > > >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" > > >wrote: > > > > > >>Hi Stephan, > > >> > > >>This is a great start. I do not know if you volunteered to update as > > >>well as provide the initial version of this document. In any case, > > here > > >>are some comments. > > >> > > >>> Endpoint - The logical point of final termination through > > >>> receiving, decoding and rendering, and/or initiation through > > >>> capturing, encoding, and sending of media streams. An endpoint > > >>> consists of one or more physical devices which source and sink > > >>> media streams. In contrast to an endpoint, a middle box, such > > >>> as an MCU, may also send and receive media streams, but it is > > >>> not the initiator nor the final terminator. > > >> > > >>I am not sure we should differentiate between endpoint and MCU. The > > >>distinction blurs in that an MCU generates and send media streams > > that > > >>are not necessarily equivalent to those it received, and it receives > > >>input from other endpoints. I think trying to distinguish them simply > > >>makes more work and add complexity. I also think we will find that > > the > > >>majority of "MCUs" are really more "endpoints" than "MCUs". > > >>You introduced the concept of remote. I am proposing remote =3D=3D > > endpoint > > >>and remove MCU. > > > > > >Not sure here. > > >What "endpoint" attempts to express is that it is the logical entity > > >facing the user--the room including microphones loudspeakers, screens, > > >cameras, and some technical stuff that sends and receives RTP streams > > >and > > >implements signaling. We need such a definition certainly in the > > >requirement spec but also in the use cases. There is also a "local" > > >endpoint, which prohibits the use of "remote". > > >I think we should leave this definition alone. > > > > > >> > > >>> Media - Any data that, after suitable encoding, can be conveyed > > >>> over RTP, including audio, video or timed text. > > >> > > >>I think this is too general, but I am not able to suggest a good way > > to > > >>improve it. > > > > > >Again, not sure why this is too general. > > > > > >> > > >>> Session - RTP session. An association among a set of > > >>> participants communicating with RTP. The distinguishing feature > > >>> of an RTP session is that each maintains a full, separate space > > >>> of SSRC identifiers. [RFC3550] > > >> > > >>In this case, do we also need a term for the collection of RTP > > sessions > > >>the contains the complete set media exchanged between two endpoints? > > > > > >Perhaps, though I don't think we have seen that need yet. > > >Pm the media plane, there is really no such thing as "bundling" of > > media > > >transmission channels. There is a logical connection between multiple > > >sessions, but only in the signaling. > > > > > >> > > >> > > >>"Layouts" vs. "Spatial Relations", what is the difference? > > > > > >A Layout is the aggregation of all spatial relations of all > > >capture/renderer devices at a given point in time? > > >"Left speaker is left from right speaker" is a spatial relation. > > >"Left microphone is co-located with left camera" is a spatial > > relation. > > >"Audio channel 1 is left, audio channel 2 is right, and there is only > > >one > > >center camera" is a layout. > > > > > >> > > >>Cheers, > > >>Charles > > >> > > >> > > >>> -----Original Message----- > > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>Of Stephan Wenger > > >>> Sent: Friday, May 13, 2011 11:08 AM > > >>> To: CLUE > > >>> Subject: [clue] Definitions > > >>> > > >>> Hi folks, > > >>> Here a VERY rough initial draft. Addressing typos, sorting to > > >>alphabetical, and other cleanup tasks > > >>> will have to wait for the my return to the office next week. I > > will > > >>submit officially only after the > > >>> most embarrassing bugs are sorted out. No need to comment on > > typos, > > >>but if you have substantial > > >>> issues then send them now, and I can address them immediately. > > >>> Stephan > > >> > > > > > > > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > >_______________________________________________ > > >clue mailing list > > >clue@ietf.org > > >https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > 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 > > > --bcaec548a4133cb14904a3a2fa34 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oddly enough I wrote the use case you quote.=A0 I don't see the need fo= r multiple SIP UAs to realize it. If you've ever operated multiple endp= oints independently in the same room, you'll realize that you get echo = and potentially other problems.

I think we should go with Stephan's recommendation for now.=A0 Expl= icitly use a single SIP UA for this set of definitions, and we can deal wit= h other cases later on.

Stephen.

O= n Thu, May 19, 2011 at 11:41 AM, <stephane.cazeaux@orange-ftgroup.com= > wrote:

Hi Stephen,

=A0

Please see inline.

=A0

=A0

St=E9phane.

=A0

D= e=A0: Stephen Bo= tzko [mailto:= stephen.botzko@gmail.com]
Envoy=E9=A0: jeudi 19 mai 2011 13:10
=C0=A0: CAZEAUX Stephane RD-BIZZ-CAE
Cc=A0: Mark.Duckworth@polycom.com; stewe@stewe.org; clue@ietf.org
Objet=A0: Re: [clue] Definitions

=A0

= I am confused about how CLUE can make interoperability with proprietary sys= tems a requirement [or a consideration].

[SC] We all agree that interoperab= ility with proprietary systems is explicitly out of scope of the charter. T= his is not the purpose of the discussion here (sorry if I was confusing on that p= oint).

=
There is quite broad consensus among manufacturers that a single UA is the = right approach for standardization.=A0

[SCa] I am ok with this cons= ensus. Actually, the suggestion to support telepresence rooms made of multi= ple SIP UAs does not intend to replace the single SIP UA approach. Instead, it intends= to be an alternative.

= The systems in the room need to be highly integrated to create the telepres= ence experience, and external telepresence MCUs need to have explicit knowl= edge about what systems are in what rooms, and how the systems are arranged within the room.=A0

[SCa] I do not agree with th= is argument. CLUE targets any endpoint from a full and high-cost telepresen= ce room to a simple handheld device. I don=92t think that we can have the same level = of integration, thus telepresence experience, with all endpoints.

Quoting draft-romanow-clue-telepre= sence-use-cases-01.txt (section 4.6.)

=93

The importance of this example is that the multiple video stream= s are

=A0=A0 not used to create an immersive conferencing experience w= ith

=A0=A0 panoramic views at all the site.=A0 Instead the multiple = streams are

=A0=A0 dynamically used to enable full participation of remote s= tudents in a

=A0=A0 university class.

=93

This use case is interesting, espe= cially because it leverages the telepresence multi-screen. We could have ca= ses where we setup endpoints in the main site, with endpoints that all have differen= t capabilities. For instance: one endpoint presents a regular HD video of t= he participants, another with a 3D video of a concept, etc=85 But a the end= , all these endpoints are in the same telepresence room, and obviously in a same telepresence conference (btw. I= don=92t see the case where these endpoints are connected to different conf= erences). If we don=92t consider the alternative of having multiple SIP UA = (i.e. multiple endpoints) in a same room, I don=92t think we can realize such (advanced) cases.

=A0

= =A0

= =A0

= Coordinated management of the endpoints is problematic.=A0 Even simple dial= ing between rooms becomes complicated.

=

Stephen Botzko

On Thu, May 19, 2011 at 3:17 AM= , <stephane.cazeaux@orange-ftgroup.com= > wrote:

Hi Mark, Stephan,

On my side, I think we should consider cases where we have several SIP UAs = in a single telepresence room.

Another discussion is to define the relation between an endpoint and a SIP = UA. IMO, we should define an endpoint as composed of one single SIP UA, and= the endpoint represents all equipment associated to the SIP UA (including = multi-screen/camera).

Thus we should consider cases where a telepresence room is composed of seve= ral endpoints. As I suggested in a previous mail, I think that such cases w= ill necessarily exist, with proprietary implementations (thus not interoper= able) in MCU to associate several endpoints so that they form a single telepresence room. That's why we = should consider these cases to have interoperability rules.


Stephane.

-----Message d'origine-----
De=A0: clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Duckworth, Mark
Envoy=E9=A0: mercredi 18 mai 2011 19:27
=C0=A0: Stephan Wenger; = clue@ietf.org
Objet=A0: Re: [clue] Definitions


Stephan,

My understanding is an endpoint has a single SIP UA. =A0And there would be = only one endpoint in a room.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Stephan Wenger
> Sent: Wednesday, May 18, 2011 2:00 AM
> To: stephane.cazeaux@orange-ftgroup.com; espeberg@cisco.com;
> eckelcu@cisco.com; clue@ietf.org
> Subject: Re: [clue] Definitions
>
> Hi Stephane,
> Very good point.
>
> Quoting from RFC 4353
>
> [...]
> =A0 =A0 =A0 =A0 Participant: The software element that connects a user= or automata to
> =A0 =A0 =A0 =A0 a conference. =A0It implements, at a minimum, a SIP us= er agent, but
> =A0 =A0 =A0 =A0 may also implement non-SIP-specific mechanisms for add= itional
> =A0 =A0 =A0 =A0 functionality.
> [...]
>
> My understanding of "endpoint" is that an endpoint encompass= es ALL
> equipment in a telepresence room. =A0I believe that there are cases wh= ere we
> can have multiple SIP user agents (Uas) in one room. =A0Think of a bun= ch of
> codec boxes in a rack, all having their own UA. =A0Is this the common<= br> > understanding of the group?
>
> To ask the question differently, do we have an agreement that there is= a
> single SIP UA in one room?
>
> Guidance, please.
>
> Thanks,
> Stephan
>
>
>
>
> On 5.18.2011 12:46 , "stephane.cazeaux@= orange-ftgroup.com"
> <stephane.cazeaux@orange-ftgroup.com> wrote:
>
> >I don't think that we want to limit the "endpoint" d= efinition to
> entities
> >facing a user. We could have entities not facing a user (e.g. an > >automata), but which are sending/receiving media, and which need t= o
> >understand characteristics of the remote, and could maybe have als= o
> some
> >characteristics. I don't think we want to exclude such cases.<= br> > >
> >Relying on the "participant" definition of RFC4353, a te= lepresence
> >conference will be composed of "participants", where a p= articipant is
> >connected to the conference through an "endpoint". In te= lepresence,
> the
> >participant will have to be aware of the endpoint, in particular w= hen
> the
> >participant needs to inform the remote of the characteristics of i= ts
> >endpoint.
> >
> >Thus my proposition is to clarify that "endpoint" define= s the entity
> >through which a participant (we do not limit to entity facing a us= er)
> is
> >connected to a telepresence conference.
> >
> >In the same manner, we could also use the "mixer" word i= nstead of
> "MCU".
> >
> >Most of requirements should then apply on the participant or mixer=
> >(typically, a participant will describe characteristics of its
> endpoint).
> >
> >
> >Regards,
> >Stephane.
> >
> >
> >-----Message d'origine-----
> >De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part
> de
> >Espen Berger (espeberg)
> >Envoy=E9 : mercredi 18 mai 2011 10:40
> >=C0 : Stephan Wenger; Charles Eckel (eckelcu); CLUE
> >Objet : Re: [clue] Definitions
> >
> >I think we should keep both endpoints and MCUs in the definition > >document.
> >
> >One difference between endpoints and MCUs are how they handle medi= a.
> An
> >endpoint usually send media representing itself and MCUs send medi= a on
> >behalf of others remote endpoint connected.
> >
> >Cheers
> >
> >-Espen
> >
> >
> >-----Original Message-----
> >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of
> >Stephan Wenger
> >Sent: 17. mai 2011 06:17
> >To: Charles Eckel (eckelcu); CLUE
> >Subject: Re: [clue] Definitions
> >
> >Hi Charles,
> >Please see inline.
> >In summary, I'm not convinced there is need for a change, thou= gh there
> >may
> >be need for more explanatory text.
> >Stephan
> >
> >On 5.16.2011 03:34 , "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> >wrote:
> >
> >>Hi Stephan,
> >>
> >>This is a great start. I do not know if you volunteered to upd= ate as
> >>well as provide the initial version of this document. In any c= ase,
> here
> >>are some comments.
> >>
> >>> Endpoint - The logical point of final termination through=
> >>> receiving, decoding and rendering, and/or initiation thro= ugh
> >>> capturing, encoding, and sending of media streams. =A0An = endpoint
> >>> consists of one or more physical devices which source and= sink
> >>> media streams. =A0In contrast to an endpoint, a middle bo= x, such
> >>> as an MCU, may also send and receive media streams, but i= t is
> >>> not the initiator nor the final terminator.
> >>
> >>I am not sure we should differentiate between endpoint and MCU= . The
> >>distinction blurs in that an MCU generates and send media stre= ams
> that
> >>are not necessarily equivalent to those it received, and it re= ceives
> >>input from other endpoints. I think trying to distinguish them= simply
> >>makes more work and add complexity. I also think we will find = that
> the
> >>majority of "MCUs" are really more "endpoints&q= uot; than "MCUs".
> >>You introduced the concept of remote. I am proposing remote = =3D=3D
> endpoint
> >>and remove MCU.
> >
> >Not sure here.
> >What "endpoint" attempts to express is that it is the lo= gical entity
> >facing the user--the room including microphones loudspeakers, scre= ens,
> >cameras, and some technical stuff that sends and receives RTP stre= ams
> >and
> >implements signaling. =A0We need such a definition certainly in th= e
> >requirement spec but also in the use cases. =A0There is also a &qu= ot;local"
> >endpoint, which prohibits the use of "remote".
> >I think we should leave this definition alone.
> >
> >>
> >>> Media - Any data that, after suitable encoding, can be co= nveyed
> >>> over RTP, including audio, video or timed text.
> >>
> >>I think this is too general, but I am not able to suggest a go= od way
> to
> >>improve it.
> >
> >Again, not sure why this is too general.
> >
> >>
> >>> Session - RTP session. =A0An association among a set of > >>> participants communicating with RTP. =A0The distinguishin= g feature
> >>> of an RTP session is that each maintains a full, separate= space
> >>> of SSRC identifiers. =A0[RFC3550]
> >>
> >>In this case, do we also need a term for the collection of RTP=
> sessions
> >>the contains the complete set media exchanged between two endp= oints?
> >
> >Perhaps, though I don't think we have seen that need yet.
> >Pm the media plane, there is really no such thing as "bundlin= g" of
> media
> >transmission channels. =A0There is a logical connection between mu= ltiple
> >sessions, but only in the signaling.
> >
> >>
> >>
> >>"Layouts" vs. "Spatial Relations", what is= the difference?
> >
> >A Layout is the aggregation of all spatial relations of all
> >capture/renderer devices at a given point in time?
> >"Left speaker is left from right speaker" is a spatial r= elation.
> >"Left microphone is co-located with left camera" is a sp= atial
> relation.
> >"Audio channel 1 is left, audio channel 2 is right, and there= is only
> >one
> >center camera" is a layout.
> >
> >>
> >>Cheers,
> >>Charles
> >>
> >>
> >>> -----Original Message-----
> >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> Behalf
> >>Of Stephan Wenger
> >>> Sent: Friday, May 13, 2011 11:08 AM
> >>> To: CLUE
> >>> Subject: [clue] Definitions
> >>>
> >>> Hi folks,
> >>> Here a VERY rough initial draft. =A0Addressing typos, sor= ting to
> >>alphabetical, and other cleanup tasks
> >>> will have to wait for the my return to the office next we= ek. =A0I
> will
> >>submit officially only after the
> >>> most embarrassing bugs are sorted out. =A0No need to comm= ent on
> typos,
> >>but if you have substantial
> >>> issues then send them now, and I can address them immedia= tely.
> >>> Stephan
> >>
> >
> >
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/cl= ue
> >_______________________________________________
> >clue mailing list
> >clue@ietf.org
> >https://www.ietf.org/mailman/listinfo/cl= ue
>
>
> _______________________________________________
> 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=

=A0


--bcaec548a4133cb14904a3a2fa34-- From stewe@stewe.org Thu May 19 10:08:04 2011 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 1A9F5E081B for ; Thu, 19 May 2011 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 pEjDYQP2nuQP for ; Thu, 19 May 2011 10:08:03 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 12C88E0706 for ; Thu, 19 May 2011 10:08:02 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2807-1743317 for ; Thu, 19 May 2011 19:08:01 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 19 May 2011 10:07:52 +0200 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Definitions-00 posted Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388644481_15680242" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] Definitions-00 posted 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, 19 May 2011 17:08:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388644481_15680242 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, I just posted the =AD00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt --B_3388644481_15680242 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi all,
I just pos= ted the –00 draft, reflecting (hopefully) the outcome of the discussio= ns of the last six days as well as (hopefully) addressing most typos.  = Comments welcome.
Stephan

http://www.ietf= .org/id/draft-wenger-clue-definitions-00.txt
--B_3388644481_15680242-- From john.elwell@siemens-enterprise.com Fri May 20 01:27:06 2011 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 5FB09E06D1 for ; Fri, 20 May 2011 01:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.581 X-Spam-Level: X-Spam-Status: No, score=-104.581 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 QnjnpOHh9uXL for ; Fri, 20 May 2011 01:27:04 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id DB275E06F6 for ; Fri, 20 May 2011 01:27:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1305880022!20451662!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 6219 invoked from network); 20 May 2011 08:27:02 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-174.messagelabs.com with SMTP; 20 May 2011 08:27:02 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 60D501EB83ED; Fri, 20 May 2011 10:27:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 20 May 2011 10:27:02 +0200 From: "Elwell, John" To: Paul Kyzivat , "Mike Hammer (hmmr)" Date: Fri, 20 May 2011 10:27:00 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwWLjQTgokU0MbsT6KCGe3kqiLwcgAmP1wA Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> In-Reply-To: <4DD5244C.8090801@cisco.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 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 20 May 2011 08:27:06 -0000 =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 19 May 2011 15:08 > To: Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Mike, >=20 > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > Paul, > > > > What I am trying to say is that Telepresence is all about=20 > the end-user > > experience, and that with multiple microphones, speakers, cameras, > > displays, and data feeds there is more complexity and=20 > chance to screw > > that up. And a key point is that spatial relationships are=20 > significant > > to the user experience. As a result, more rigor is needed=20 > to design the > > system to ensure that backward compatible means that legacy=20 > systems are > > handled as such. > > > > I am not sure if the protocol design is far enough along to analyze > > whether correct protocol operation still results in bad=20 > user experience, > > but would suggest that if certain key concepts like spatial=20 > awareness > > are not understood, then that leg needs to devolve to a known legacy > > state and handled by the MCU as such. That might mean tagging some > > parameters as mandatory to understand to force the=20 > determination and not > > leave it ambiguous. > > > > I believe some current systems treat legacy systems differently and > > don't expect them to behave like ones that understands the dynamic > > speaker controls. >=20 > I suspect we are talking past each other and are not really=20 > in disagreement. >=20 > I expect that the clue specs, whatever they turn out to be,=20 > will require=20 > support for a bunch of existing sip/sdp mechanisms that are generally=20 > optional and not widely implemented in lower end devices. >=20 > If so, then if we have two clueful systems attempting to connect, we=20 > will be in the realm of negotiating using syntax that both=20 > understand.=20 > In that case, this discussion of how to behave when something *isn't*=20 > understood is moot. Rather that situation will arise when we have a=20 > clueful system attempting to connect to a clueless system, or visa=20 > versa. That is where my focus is in this discussion. [JRE] And furthermore, we might have a conference comprising a number of CL= UEful endpoints and a number of CLUEless endpoints. We would ideally like t= o be in a position where the CLUEful endpoint users can share a telepresenc= e experience, and yet the CLUEless endpoint users can still participate mea= ningfully in the conference. John >=20 > Further into the future, perhaps we will have clue_v2,=20 > clue_v3, etc. In=20 > that case, we may again be into a situation where we have a=20 > clue_v1_ful=20 > system that doesn't understand something coming from a clue_v2_ful=20 > system. When designing any new protocol for clue_v1, we=20 > should keep in=20 > mind to specify how to handle that which isn't understood in order to=20 > support that future scenario. >=20 > Thanks, > Paul >=20 > > Mike > > > > > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Wednesday, May 18, 2011 7:38 PM > > To: Mike Hammer (hmmr) > > Cc: Roni Even; clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > >> Paul, > >> > >> Murphy's Law says that if it is possible to put something=20 > together the > >> wrong way, > >> probability says it will go the wrong way sooner or later.=20 > LTC Murphy > >> had a > >> young enlisted guy that always found that wrong way to do things. > >> System-wise, > >> the black-swan events occur unless you do your best to design them > > out. > >> > >> Machines are often designed so that there is exactly one=20 > way to do it. > >> > >> We want flexibility in software, but sometimes too much is not so > > good. > >> Hopefully, proper operation of the protocol won't look=20 > like an error. > > > > Mike, > > > > I don't understand the point you are trying to make in the=20 > context of > > this conversation. > > > > This started out as a discussion of whether it was=20 > acceptable to reject > > an offer because it contains stuff (for the sake of argument lets > > restrict it to a-lines for now) the the answerer doesn't=20 > understand/know > > > > anything about. > > > > Clearly its *possible* for a UA to do that. And since a UA=20 > can reject > > things for policy reasons, it may be undecidable whether it rejected > > because of the unknown lines or for some more justifed reason. > > > > But still, I think we can *expect* a UA to refrain from doing that. > > > > That doesn't mean they all will. But when they don't, its a=20 > bug, not a > > valid implementation choice. > > > > Thanks, > > Paul > > > >> Mike > >> > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Wednesday, May 18, 2011 1:09 PM > >> To: Mike Hammer (hmmr) > >> Cc: Roni Even; clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > >>> Paul, > >>> > >>> I would agree that if the offer-answer model semantic is that here > > are > >>> several options and any subset of options is acceptable. > >>> > >>> However, if there is any grouping involved such that you=20 > need to have > >> a > >>> video and audio feed integrated to make sense then watch out. > >>> > >>> For example, I wouldn't want to end up with the result of a man's > >> video > >>> paired with a woman's voice. That could be rather comical. > >> > >> Well, SDP defines that you should ignore what you don't=20 > understand and > >> operate on what is left. > >> > >> So someone constructing an SDP with grouping issues such=20 > as you define > >> ought to keep in mind that this could happen, and set things up so > > that > >> something reasonable happens. You can't expect the dumb=20 > legacy device > > to > >> > >> figure out much. > >> > >> For your example, the result may be far from ideal, but it still is > >> likely to be better than no call at all. And if not, there=20 > is always > > the > >> > >> option of hanging up. But better, presumably the offer=20 > could have been > >> constructed in a way that produced a better result. > >> > >> Thanks, > >> Paul > >> > >>> Mike > >>> > >>> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > >> Of > >>> Paul Kyzivat (pkyzivat) > >>> Sent: Tuesday, May 17, 2011 7:45 PM > >>> To: Roni Even > >>> Cc: clue@ietf.org > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> > >>> > >>> On 5/17/2011 6:05 PM, Roni Even wrote: > >>>> Paul, > >>>> I think we read it differently. > >>>> If the answerer does not support the group attribute and=20 > the offer > >> had > >>> the > >>>> fid semantics it may look to the answerer as an offer=20 > with multiple > >>> m-lines > >>>> of the same media tyoe. In this case an implementation might also > >>> decide to > >>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > >>> Acceptable), > >>>> because it contains several "m" lines of the same media type. > >>> > >>> That is a slightly different story. > >>> > >>> Then the reason for rejection is not because it saw an=20 > attribute it > >>> didn't understand - its because it didn't like something it *did* > >>> understand. > >>> > >>>> This is very relevant to the multiple streams case and we should > > look > >>> if we > >>>> state this behavior or we will look at providing an approach that > >> will > >>> allow > >>>> the answerer to choose one m-line that the offerer=20 > prefers even of > > it > >>> does > >>>> not understand CLUE. > >>> > >>> IMO (lets see if others differ), if a UA receives an offer with at > >> least > >>> > >>> one m-line it is happy with, then it should not reject the call > >> because > >>> there are others that it does not "understand". > >>> > >>> Here "understand" means something different - presumably it does > >>> understand the direct meaning of the additional m-line, it just > >> doesn't > >>> understand the *significance* or use of it. > >>> > >>> I see little difference to getting to audio m-lines and=20 > only wanting > >>> one, and getting one audio and one video and only=20 > supporting audio. > > In > >>> general you should not reject an audio/video call just because you > >> only > >>> support audio. > >>> > >>> I think it will behoove clue to strongly recommend that=20 > the m-lines > > in > >>> an offer be arranged so the first ones are the ones it most wants > > used > >>> if not all are. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Roni > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: Wednesday, May 18, 2011 12:37 AM > >>>>> To: Roni Even > >>>>> Cc: 'Stephen Botzko'; clue@ietf.org > >>>>> Subject: Re: [clue] legacy support in requirements > >>>>> > >>>>> > >>>>> > >>>>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>>>> Paul, > >>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >> example > >>>>>> Roni > >>>>> > >>>>> OK, I looked. It is consistent with what I said. > >>>>> Either a=3Dgroup: is understood, or not. If not, its=20 > ignored, and not > >>> put > >>>>> in the answer. Same with a=3Dmid: > >>>>> > >>>>> If a=3Dgroup: *is* understood, but some parameter within=20 > it is not, > >>> there > >>>>> are explicit rules for what to do. > >>>>> > >>>>> AFAICT there are no examples in this document where failure to > >>>>> understand an a-line in total (or even in part) results in > > rejecting > >>>>> the > >>>>> offer. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>> Behalf > >>>>> Of > >>>>>>> Paul Kyzivat > >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>>>> To: Stephen Botzko > >>>>>>> Cc: clue@ietf.org > >>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>>>> > >>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>>>> > >>>>>>>> When the offer includes parameters that=20 > the answerer > >>> does > >>>>> not > >>>>>>>> understand > >>>>>>>> there are two options, he can ignore the unknown > >>>>> parameters > >>>>>>> or > >>>>>>>> reject > >>>>>>>> the offer. > >>>>>>>> Rejecting the offer in that case is not=20 > really kosher. > >>>>>>>> You are required to ignore parameters you do not > >> understand. > >>>>>>>> > >>>>>>>> If you reject something because you don't like the > >>> parameters > >>>>> it > >>>>>>>> contains, then that is an implicit=20 > statement that you > >>>>> understand > >>>>>>>> those parameters well enough to decide to=20 > reject them. > >>>>>>>> > >>>>>>>> As far as I know, you are always free to reject=20 > offers, and it > >>>>>>> doesn't > >>>>>>>> really imply anything when you do that.. Whether it=20 > is wise is > >>>>>>> perhaps > >>>>>>>> a different question. > >>>>>>>> Stephen Botzko > >>>>>>> > >>>>>>> Certainly you are always free to reject an offer. > >>>>>>> In general I don't know for certain the reason why,=20 > and so if I > >>> give > >>>>>>> you > >>>>>>> the benefit of the doubt I will assume you have a=20 > valid reason - > >>>>>>> perhaps > >>>>>>> just policy. > >>>>>>> > >>>>>>> But if the reason you reject the offer is based on=20 > your violating > >> a > >>>>>>> spec, then you are non-conforming, whether I can determine you > > are > >>>>>>> non-conforming or not. Whether being non-conforming is just > >>> un-wise, > >>>>> or > >>>>>>> something stronger, is a separate discussion. The=20 > IETF does not > >>> levy > >>>>>>> any > >>>>>>> penalties for violating its specs. But sometimes the=20 > market does. > >>>>> (And > >>>>>>> sometimes not.) But we don't need to endorse non-conforming > >>> behavior > >>>>> in > >>>>>>> our documents. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>> > >>>>>> > >>>> > >>>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From stephen.botzko@gmail.com Fri May 20 03:11:46 2011 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 1BBD6E0770 for ; Fri, 20 May 2011 03:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 4JVJMsLI5-WE for ; Fri, 20 May 2011 03:11:44 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4E99E0768 for ; Fri, 20 May 2011 03:11:43 -0700 (PDT) Received: by vws12 with SMTP id 12so3067440vws.31 for ; Fri, 20 May 2011 03:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hn69N8wIpvkjbtDVuD3HmeCpg/xRmYOEncAJ8D/ylEA=; b=yA/MEnUj0SaVFR/bbDuiu0Zqn5LaC3Sr7hXX7uu9AZ48cWzZa6qLT88972E4scfnNz raJkHkC7CyABAme1stKM2txNRpPNE4ShHCSj6KzM+VSq5LxlxgtinXxWrUEA9koEw6le pedRLEbGaItPRYO3DyS3MjxKL6UbvCoUqq7+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PR990LR5ZDpTC9ilwUeXzBFlGokmKih2HEYW7pnEsG5glcq6cZLSUA0nUeNsTN9agj B9GioMrLl//dWArrw50BpKjywp+ZpPRX21IUnOUjVZWQGUKnEgKGl0bIfH6c2g3wqvlP SqObvqOkmCtBtD5d4uHiZaSPi2uOP0Lgh2tH0= MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr890494vdb.116.1305886299876; Fri, 20 May 2011 03:11:39 -0700 (PDT) Received: by 10.52.115.165 with HTTP; Fri, 20 May 2011 03:11:39 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Date: Fri, 20 May 2011 06:11:39 -0400 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf307cfdd4056c5d04a3b259b8 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 20 May 2011 10:11:46 -0000 --20cf307cfdd4056c5d04a3b259b8 Content-Type: text/plain; charset=ISO-8859-1 in-line Stephen Botzko On Fri, May 20, 2011 at 4:27 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 19 May 2011 15:08 > > To: Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > Mike, > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > Paul, > > > > > > What I am trying to say is that Telepresence is all about > > the end-user > > > experience, and that with multiple microphones, speakers, cameras, > > > displays, and data feeds there is more complexity and > > chance to screw > > > that up. And a key point is that spatial relationships are > > significant > > > to the user experience. As a result, more rigor is needed > > to design the > > > system to ensure that backward compatible means that legacy > > systems are > > > handled as such. > > > > > > I am not sure if the protocol design is far enough along to analyze > > > whether correct protocol operation still results in bad > > user experience, > > > but would suggest that if certain key concepts like spatial > > awareness > > > are not understood, then that leg needs to devolve to a known legacy > > > state and handled by the MCU as such. That might mean tagging some > > > parameters as mandatory to understand to force the > > determination and not > > > leave it ambiguous. > > > > > > I believe some current systems treat legacy systems differently and > > > don't expect them to behave like ones that understands the dynamic > > > speaker controls. > > > > I suspect we are talking past each other and are not really > > in disagreement. > > > > I expect that the clue specs, whatever they turn out to be, > > will require > > support for a bunch of existing sip/sdp mechanisms that are generally > > optional and not widely implemented in lower end devices. > > > > If so, then if we have two clueful systems attempting to connect, we > > will be in the realm of negotiating using syntax that both > > understand. > > In that case, this discussion of how to behave when something *isn't* > > understood is moot. Rather that situation will arise when we have a > > clueful system attempting to connect to a clueless system, or visa > > versa. That is where my focus is in this discussion. > [JRE] And furthermore, we might have a conference comprising a number of > CLUEful endpoints and a number of CLUEless endpoints. We would ideally like > to be in a position where the CLUEful endpoint users can share a > telepresence experience, and yet the CLUEless endpoint users can still > participate meaningfully in the conference. > John > [SB]Agreed > > > > > > Further into the future, perhaps we will have clue_v2, > > clue_v3, etc. In > > that case, we may again be into a situation where we have a > > clue_v1_ful > > system that doesn't understand something coming from a clue_v2_ful > > system. When designing any new protocol for clue_v1, we > > should keep in > > mind to specify how to handle that which isn't understood in order to > > support that future scenario. > > > > Thanks, > > Paul > > > > > Mike > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat (pkyzivat) > > > Sent: Wednesday, May 18, 2011 7:38 PM > > > To: Mike Hammer (hmmr) > > > Cc: Roni Even; clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > > >> Paul, > > >> > > >> Murphy's Law says that if it is possible to put something > > together the > > >> wrong way, > > >> probability says it will go the wrong way sooner or later. > > LTC Murphy > > >> had a > > >> young enlisted guy that always found that wrong way to do things. > > >> System-wise, > > >> the black-swan events occur unless you do your best to design them > > > out. > > >> > > >> Machines are often designed so that there is exactly one > > way to do it. > > >> > > >> We want flexibility in software, but sometimes too much is not so > > > good. > > >> Hopefully, proper operation of the protocol won't look > > like an error. > > > > > > Mike, > > > > > > I don't understand the point you are trying to make in the > > context of > > > this conversation. > > > > > > This started out as a discussion of whether it was > > acceptable to reject > > > an offer because it contains stuff (for the sake of argument lets > > > restrict it to a-lines for now) the the answerer doesn't > > understand/know > > > > > > anything about. > > > > > > Clearly its *possible* for a UA to do that. And since a UA > > can reject > > > things for policy reasons, it may be undecidable whether it rejected > > > because of the unknown lines or for some more justifed reason. > > > > > > But still, I think we can *expect* a UA to refrain from doing that. > > > > > > That doesn't mean they all will. But when they don't, its a > > bug, not a > > > valid implementation choice. > > > > > > Thanks, > > > Paul > > > > > >> Mike > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat (pkyzivat) > > >> Sent: Wednesday, May 18, 2011 1:09 PM > > >> To: Mike Hammer (hmmr) > > >> Cc: Roni Even; clue@ietf.org > > >> Subject: Re: [clue] legacy support in requirements > > >> > > >> > > >> > > >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > > >>> Paul, > > >>> > > >>> I would agree that if the offer-answer model semantic is that here > > > are > > >>> several options and any subset of options is acceptable. > > >>> > > >>> However, if there is any grouping involved such that you > > need to have > > >> a > > >>> video and audio feed integrated to make sense then watch out. > > >>> > > >>> For example, I wouldn't want to end up with the result of a man's > > >> video > > >>> paired with a woman's voice. That could be rather comical. > > >> > > >> Well, SDP defines that you should ignore what you don't > > understand and > > >> operate on what is left. > > >> > > >> So someone constructing an SDP with grouping issues such > > as you define > > >> ought to keep in mind that this could happen, and set things up so > > > that > > >> something reasonable happens. You can't expect the dumb > > legacy device > > > to > > >> > > >> figure out much. > > >> > > >> For your example, the result may be far from ideal, but it still is > > >> likely to be better than no call at all. And if not, there > > is always > > > the > > >> > > >> option of hanging up. But better, presumably the offer > > could have been > > >> constructed in a way that produced a better result. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Mike > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > >> Of > > >>> Paul Kyzivat (pkyzivat) > > >>> Sent: Tuesday, May 17, 2011 7:45 PM > > >>> To: Roni Even > > >>> Cc: clue@ietf.org > > >>> Subject: Re: [clue] legacy support in requirements > > >>> > > >>> > > >>> > > >>> On 5/17/2011 6:05 PM, Roni Even wrote: > > >>>> Paul, > > >>>> I think we read it differently. > > >>>> If the answerer does not support the group attribute and > > the offer > > >> had > > >>> the > > >>>> fid semantics it may look to the answerer as an offer > > with multiple > > >>> m-lines > > >>>> of the same media tyoe. In this case an implementation might also > > >>> decide to > > >>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > >>> Acceptable), > > >>>> because it contains several "m" lines of the same media type. > > >>> > > >>> That is a slightly different story. > > >>> > > >>> Then the reason for rejection is not because it saw an > > attribute it > > >>> didn't understand - its because it didn't like something it *did* > > >>> understand. > > >>> > > >>>> This is very relevant to the multiple streams case and we should > > > look > > >>> if we > > >>>> state this behavior or we will look at providing an approach that > > >> will > > >>> allow > > >>>> the answerer to choose one m-line that the offerer > > prefers even of > > > it > > >>> does > > >>>> not understand CLUE. > > >>> > > >>> IMO (lets see if others differ), if a UA receives an offer with at > > >> least > > >>> > > >>> one m-line it is happy with, then it should not reject the call > > >> because > > >>> there are others that it does not "understand". > > >>> > > >>> Here "understand" means something different - presumably it does > > >>> understand the direct meaning of the additional m-line, it just > > >> doesn't > > >>> understand the *significance* or use of it. > > >>> > > >>> I see little difference to getting to audio m-lines and > > only wanting > > >>> one, and getting one audio and one video and only > > supporting audio. > > > In > > >>> general you should not reject an audio/video call just because you > > >> only > > >>> support audio. > > >>> > > >>> I think it will behoove clue to strongly recommend that > > the m-lines > > > in > > >>> an offer be arranged so the first ones are the ones it most wants > > > used > > >>> if not all are. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>>> Roni > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>> Sent: Wednesday, May 18, 2011 12:37 AM > > >>>>> To: Roni Even > > >>>>> Cc: 'Stephen Botzko'; clue@ietf.org > > >>>>> Subject: Re: [clue] legacy support in requirements > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 5/17/2011 5:20 PM, Roni Even wrote: > > >>>>>> Paul, > > >>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > >> example > > >>>>>> Roni > > >>>>> > > >>>>> OK, I looked. It is consistent with what I said. > > >>>>> Either a=group: is understood, or not. If not, its > > ignored, and not > > >>> put > > >>>>> in the answer. Same with a=mid: > > >>>>> > > >>>>> If a=group: *is* understood, but some parameter within > > it is not, > > >>> there > > >>>>> are explicit rules for what to do. > > >>>>> > > >>>>> AFAICT there are no examples in this document where failure to > > >>>>> understand an a-line in total (or even in part) results in > > > rejecting > > >>>>> the > > >>>>> offer. > > >>>>> > > >>>>> Thanks, > > >>>>> Paul > > >>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > >>> Behalf > > >>>>> Of > > >>>>>>> Paul Kyzivat > > >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > > >>>>>>> To: Stephen Botzko > > >>>>>>> Cc: clue@ietf.org > > >>>>>>> Subject: Re: [clue] legacy support in requirements > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > >>>>>>> > > >>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > >>>>>>> > > >>>>>>>> When the offer includes parameters that > > the answerer > > >>> does > > >>>>> not > > >>>>>>>> understand > > >>>>>>>> there are two options, he can ignore the unknown > > >>>>> parameters > > >>>>>>> or > > >>>>>>>> reject > > >>>>>>>> the offer. > > >>>>>>>> Rejecting the offer in that case is not > > really kosher. > > >>>>>>>> You are required to ignore parameters you do not > > >> understand. > > >>>>>>>> > > >>>>>>>> If you reject something because you don't like the > > >>> parameters > > >>>>> it > > >>>>>>>> contains, then that is an implicit > > statement that you > > >>>>> understand > > >>>>>>>> those parameters well enough to decide to > > reject them. > > >>>>>>>> > > >>>>>>>> As far as I know, you are always free to reject > > offers, and it > > >>>>>>> doesn't > > >>>>>>>> really imply anything when you do that.. Whether it > > is wise is > > >>>>>>> perhaps > > >>>>>>>> a different question. > > >>>>>>>> Stephen Botzko > > >>>>>>> > > >>>>>>> Certainly you are always free to reject an offer. > > >>>>>>> In general I don't know for certain the reason why, > > and so if I > > >>> give > > >>>>>>> you > > >>>>>>> the benefit of the doubt I will assume you have a > > valid reason - > > >>>>>>> perhaps > > >>>>>>> just policy. > > >>>>>>> > > >>>>>>> But if the reason you reject the offer is based on > > your violating > > >> a > > >>>>>>> spec, then you are non-conforming, whether I can determine you > > > are > > >>>>>>> non-conforming or not. Whether being non-conforming is just > > >>> un-wise, > > >>>>> or > > >>>>>>> something stronger, is a separate discussion. The > > IETF does not > > >>> levy > > >>>>>>> any > > >>>>>>> penalties for violating its specs. But sometimes the > > market does. > > >>>>> (And > > >>>>>>> sometimes not.) But we don't need to endorse non-conforming > > >>> behavior > > >>>>> in > > >>>>>>> our documents. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Paul > > >>>>>>> _______________________________________________ > > >>>>>>> clue mailing list > > >>>>>>> clue@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> clue mailing list > > >>> clue@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307cfdd4056c5d04a3b259b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen Botzko

On Fri, May 20= , 2011 at 4:27 AM, Elwell, John <john.elwell@siemens-enterprise.com>= wrote:


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 19 May 2011 15:08
> To: Mike Hammer (hmmr)
> Cc: clue@ietf.org
> Subject: Re: [clue] legacy support in requirements >
> Mike,
>
> On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote:
> > Paul,
> >
> > What I am trying to say is that Telepresence is all about
> the end-user
> > experience, and that with multiple microphones, speakers, cameras= ,
> > displays, and data feeds there is more complexity and
> chance to screw
> > that up. =A0And a key point is that spatial relationships are
> significant
> > to the user experience. =A0As a result, more rigor is needed
> to design the
> > system to ensure that backward compatible means that legacy
> systems are
> > handled as such.
> >
> > I am not sure if the protocol design is far enough along to analy= ze
> > whether correct protocol operation still results in bad
> user experience,
> > but would suggest that if certain key concepts like spatial
> awareness
> > are not understood, then that leg needs to devolve to a known leg= acy
> > state and handled by the MCU as such. =A0That might mean tagging = some
> > parameters as mandatory to understand to force the
> determination and not
> > leave it ambiguous.
> >
> > I believe some current systems treat legacy systems differently a= nd
> > don't expect them to behave like ones that understands the dy= namic
> > speaker controls.
>
> I suspect we are talking past each other and are not really
> in disagreement.
>
> I expect that the clue specs, whatever they turn out to be,
> will require
> support for a bunch of existing sip/sdp mechanisms that are generally<= br> > optional and not widely implemented in lower end devices.
>
> If so, then if we have two clueful systems attempting to connect, we > will be in the realm of negotiating using syntax that both
> understand.
> In that case, this discussion of how to behave when something *isn'= ;t*
> understood is moot. Rather that situation will arise when we have a > clueful system attempting to connect to a clueless system, or visa
> versa. That is where my focus is in this discussion.
[JRE] And furthermore, we might have a conference comprising a = number of CLUEful endpoints and a number of CLUEless endpoints. We would id= eally like to be in a position where the CLUEful endpoint users can share a= telepresence experience, and yet the CLUEless endpoint users can still par= ticipate meaningfully in the conference.=A0

John
[SB]Agreed
=A0


>
> Further into the future, perhaps we will have clue_v2,
> clue_v3, etc. In
> that case, we may again be into a situation where we have a
> clue_v1_ful
> system that doesn't understand something coming from a clue_v2_ful=
> system. When designing any new protocol for clue_v1, we
> should keep in
> mind to specify how to handle that which isn't understood in order= to
> support that future scenario.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Mike
> >
> >
> > -----Original Message-----
> > From: Paul Kyzivat (pkyzivat)
> > Sent: Wednesday, May 18, 2011 7:38 PM
> > To: Mike Hammer (hmmr)
> > Cc: Roni Even; clue@ietf.org=
> > Subject: Re: [clue] legacy support in requirements
> >
> >
> >
> > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote:
> >> Paul,
> >>
> >> Murphy's Law says that if it is possible to put something=
> together the
> >> wrong way,
> >> probability says it will go the wrong way sooner or later. > =A0LTC Murphy
> >> had a
> >> young enlisted guy that always found that wrong way to do thi= ngs.
> >> System-wise,
> >> the black-swan events occur unless you do your best to design= them
> > out.
> >>
> >> Machines are often designed so that there is exactly one
> way to do it.
> >>
> >> We want flexibility in software, but sometimes too much is no= t so
> > good.
> >> Hopefully, proper operation of the protocol won't look > like an error.
> >
> > Mike,
> >
> > I don't understand the point you are trying to make in the > context of
> > this conversation.
> >
> > This started out as a discussion of whether it was
> acceptable to reject
> > an offer because it contains stuff (for the sake of argument lets=
> > restrict it to a-lines for now) the the answerer doesn't
> understand/know
> >
> > anything about.
> >
> > Clearly its *possible* for a UA to do that. And since a UA
> can reject
> > things for policy reasons, it may be undecidable whether it rejec= ted
> > because of the unknown lines or for some more justifed reason. > >
> > But still, I think we can *expect* a UA to refrain from doing tha= t.
> >
> > That doesn't mean they all will. But when they don't, its= a
> bug, not a
> > valid implementation choice.
> >
> > =A0 =A0 Thanks,
> > =A0 =A0 Paul
> >
> >> Mike
> >>
> >> -----Original Message-----
> >> From: Paul Kyzivat (pkyzivat)
> >> Sent: Wednesday, May 18, 2011 1:09 PM
> >> To: Mike Hammer (hmmr)
> >> Cc: Roni Even; clue@ietf.org=
> >> Subject: Re: [clue] legacy support in requirements
> >>
> >>
> >>
> >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote:
> >>> Paul,
> >>>
> >>> I would agree that if the offer-answer model semantic is = that here
> > are
> >>> several options and any subset of options is acceptable.<= br> > >>>
> >>> However, if there is any grouping involved such that you<= br> > need to have
> >> a
> >>> video and audio feed integrated to make sense then watch = out.
> >>>
> >>> For example, I wouldn't want to end up with the resul= t of a man's
> >> video
> >>> paired with a woman's voice. =A0That could be rather = comical.
> >>
> >> Well, SDP defines that you should ignore what you don't > understand and
> >> operate on what is left.
> >>
> >> So someone constructing an SDP with grouping issues such
> as you define
> >> ought to keep in mind that this could happen, and set things = up so
> > that
> >> something reasonable happens. You can't expect the dumb > legacy device
> > to
> >>
> >> figure out much.
> >>
> >> For your example, the result may be far from ideal, but it st= ill is
> >> likely to be better than no call at all. And if not, there > is always
> > the
> >>
> >> option of hanging up. But better, presumably the offer
> could have been
> >> constructed in a way that produced a better result.
> >>
> >> =A0 =A0Thanks,
> >> =A0 =A0Paul
> >>
> >>> Mike
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: clue-bounc= es@ietf.org
> [mailto:clue-bounces@ietf.org= ] On Behalf
> >> Of
> >>> Paul Kyzivat (pkyzivat)
> >>> Sent: Tuesday, May 17, 2011 7:45 PM
> >>> To: Roni Even
> >>> Cc: clue@ietf.org > >>> Subject: Re: [clue] legacy support in requirements
> >>>
> >>>
> >>>
> >>> On 5/17/2011 6:05 PM, Roni Even wrote:
> >>>> Paul,
> >>>> I think we read it differently.
> >>>> If the answerer does not support the group attribute = and
> the offer
> >> had
> >>> the
> >>>> fid semantics it may look to the answerer as an offer=
> with multiple
> >>> m-lines
> >>>> of the same media tyoe. In this case an implementatio= n might also
> >>> decide to
> >>>> refuse the request (e.g., 488 Not Acceptable Here, or= 606 Not
> >>> Acceptable),
> >>>> because it contains several "m" lines of th= e same media type.
> >>>
> >>> That is a slightly different story.
> >>>
> >>> Then the reason for rejection is not because it saw an > attribute it
> >>> didn't understand - its because it didn't like so= mething it *did*
> >>> understand.
> >>>
> >>>> This is very relevant to the multiple streams case an= d we should
> > look
> >>> if we
> >>>> state this behavior or we will look at providing an a= pproach that
> >> will
> >>> allow
> >>>> the answerer to choose one m-line that the offerer > prefers even of
> > it
> >>> does
> >>>> not understand CLUE.
> >>>
> >>> IMO (lets see if others differ), if a UA receives an offe= r with at
> >> least
> >>>
> >>> one m-line it is happy with, then it should not reject th= e call
> >> because
> >>> there are others that it does not "understand".=
> >>>
> >>> Here "understand" means something different - p= resumably it does
> >>> understand the direct meaning of the additional m-line, i= t just
> >> doesn't
> >>> understand the *significance* or use of it.
> >>>
> >>> I see little difference to getting to audio m-lines and > only wanting
> >>> one, and getting one audio and one video and only
> supporting audio.
> > In
> >>> general you should not reject an audio/video call just be= cause you
> >> only
> >>> support audio.
> >>>
> >>> I think it will behoove clue to strongly recommend that > the m-lines
> > in
> >>> an offer be arranged so the first ones are the ones it mo= st wants
> > used
> >>> if not all are.
> >>>
> >>> =A0 Thanks,
> >>> =A0 Paul
> >>>
> >>>> Roni
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>>> Sent: Wednesday, May 18, 2011 12:37 AM
> >>>>> To: Roni Even
> >>>>> Cc: 'Stephen Botzko'; clue@ietf.org
> >>>>> Subject: Re: [clue] legacy support in requirement= s
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 5/17/2011 5:20 PM, Roni Even wrote:
> >>>>>> Paul,
> >>>>>> Look at http://tools.ietf.org/html/rfc588= 8#section-9.4.2 for
> >> example
> >>>>>> Roni
> >>>>>
> >>>>> OK, I looked. It is consistent with what I said.<= br> > >>>>> Either a=3Dgroup: is understood, or not. If not, = its
> ignored, and not
> >>> put
> >>>>> in the answer. Same with a=3Dmid:
> >>>>>
> >>>>> If a=3Dgroup: *is* understood, but some parameter= within
> it is not,
> >>> there
> >>>>> are explicit rules for what to do.
> >>>>>
> >>>>> AFAICT there are no examples in this document whe= re failure to
> >>>>> understand an a-line in total (or even in part) r= esults in
> > rejecting
> >>>>> the
> >>>>> offer.
> >>>>>
> >>>>> =A0 =A0 =A0 =A0 Thanks,
> >>>>> =A0 =A0 =A0 =A0 Paul
> >>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> >>> Behalf
> >>>>> Of
> >>>>>>> Paul Kyzivat
> >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM
> >>>>>>> To: Stephen Botzko
> >>>>>>> Cc: clue= @ietf.org
> >>>>>>> Subject: Re: [clue] legacy support in req= uirements
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wro= te:
> >>>>>>>
> >>>>>>>> =A0 =A0 =A0 =A0 =A0On 5/17/2011 2:24 = AM, Roni Even wrote:
> >>>>>>>
> >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0When the o= ffer includes parameters that
> the answerer
> >>> does
> >>>>> not
> >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0understand=
> >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0there are = two options, he can ignore the unknown
> >>>>> parameters
> >>>>>>> or
> >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0reject
> >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0the offer.=
> >>>>>>>> =A0 =A0 =A0 =A0 =A0Rejecting the offe= r in that case is not
> really kosher.
> >>>>>>>> =A0 =A0 =A0 =A0 =A0You are required t= o ignore parameters you do not
> >> understand.
> >>>>>>>>
> >>>>>>>> =A0 =A0 =A0 =A0 =A0If you reject some= thing because you don't like the
> >>> parameters
> >>>>> it
> >>>>>>>> =A0 =A0 =A0 =A0 =A0contains, then tha= t is an implicit
> statement that you
> >>>>> understand
> >>>>>>>> =A0 =A0 =A0 =A0 =A0those parameters w= ell enough to decide to
> reject them.
> >>>>>>>>
> >>>>>>>> As far as I know, you are always free= to reject
> offers, and it
> >>>>>>> doesn't
> >>>>>>>> really imply anything when you do tha= t.. =A0Whether it
> is wise is
> >>>>>>> perhaps
> >>>>>>>> a different question.
> >>>>>>>> Stephen Botzko
> >>>>>>>
> >>>>>>> Certainly you are always free to reject a= n offer.
> >>>>>>> In general I don't know for certain t= he reason why,
> and so if I
> >>> give
> >>>>>>> you
> >>>>>>> the benefit of the doubt I will assume yo= u have a
> valid reason -
> >>>>>>> perhaps
> >>>>>>> just policy.
> >>>>>>>
> >>>>>>> But if the reason you reject the offer is= based on
> your violating
> >> a
> >>>>>>> spec, then you are non-conforming, whethe= r I can determine you
> > are
> >>>>>>> non-conforming or not. Whether being non-= conforming is just
> >>> un-wise,
> >>>>> or
> >>>>>>> something stronger, is a separate discuss= ion. The
> IETF does not
> >>> levy
> >>>>>>> any
> >>>>>>> penalties for violating its specs. But so= metimes the
> market does.
> >>>>> (And
> >>>>>>> sometimes not.) But we don't need to = endorse non-conforming
> >>> behavior
> >>>>> in
> >>>>>>> our documents.
> >>>>>>>
> >>>>>>> =A0 =A0 =A0 Thanks,
> >>>>>>> =A0 =A0 =A0 Paul
> >>>>>>> _________________________________________= ______
> >>>>>>> clue mailing list
> >>>>>>> clue@iet= f.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/clue<= /a>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> clue mailing list
> >>> clue@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/clue
> >>>
> >>
> >
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307cfdd4056c5d04a3b259b8-- From mary.ietf.barnes@gmail.com Tue May 24 10:13:04 2011 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 00737E0785 for ; Tue, 24 May 2011 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 F7e0wQtn1sRL for ; Tue, 24 May 2011 10:13:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1DE0784 for ; Tue, 24 May 2011 10:13:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so6160667vxg.31 for ; Tue, 24 May 2011 10:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=RmaMGelKN6t2ozlc/Den4rkrU5GqkW8oQ6NE+zeLkaw=; b=CASGLqocBmroS9y3MEZgczyGan7B17nX76ErhylvCVOotj1EHn4Bb7rJlbQ8xahleV yHl6oKdM1sPSkiJ9Akg7VJiO1/EMahipb9Z4ggOwgiAtKT66TtxYRKbxthx9Langr2Fw UnF9gkPV0VRHixGRfb03IuQ7+MhYKUzZI/8hU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=m2k3EUgxU5l3rCo709yyF5m2gW86lpIsfPkoJnlQpEbLYUn763D41KbEiNKyecP140 aYRgo0JXG8WHwdDXA53Lu8cDkD8Uv5G7mwpFQGwsaPQytrsA8u2Dv6VYW2ywknp0YI50 ncw97hvoYjIjnw2xJ/74Ynfgf1NMi8qE6FaqM= MIME-Version: 1.0 Received: by 10.52.96.9 with SMTP id do9mr2554170vdb.263.1306257182743; Tue, 24 May 2011 10:13:02 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Tue, 24 May 2011 10:13:02 -0700 (PDT) Date: Tue, 24 May 2011 12:13:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d06625cdadf04a408b368 Subject: [clue] Minutes available for the CLUE Interim on May 12th, 2011 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, 24 May 2011 17:13:04 -0000 --20cf307d06625cdadf04a408b368 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I have uploaded the complete meeting minutes for the Interim meeting on May 12th, 2011: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Minutes-May-12-2011/CLUE-interim-minutes-80.5.txt Please send any additional comments to the mailing list or the chairs, so we can make sure that they get update before we submit to the official repository. Regards, Mary CLUE WG co-chair --20cf307d06625cdadf04a408b368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I have uploaded the complete meeting minutes f= or the Interim meeting on May 12th, 2011:

Please send any additional comments to the mailing list= or the chairs, so we can make sure that they get update before we submit t= o the official repository. =A0

Regards,
Mary=A0
CLUE WG co-chair
--20cf307d06625cdadf04a408b368-- From mary.ietf.barnes@gmail.com Tue May 24 10:22:19 2011 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 26D4C130021 for ; Tue, 24 May 2011 10:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.170, 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 ze75Bis0I8qv for ; Tue, 24 May 2011 10:22:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9713B13001A for ; Tue, 24 May 2011 10:22:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so6169841vxg.31 for ; Tue, 24 May 2011 10:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=vlCt57PPLWYFK1HhvxalYh7VGXhWvRM8ubOLaRNlGEw=; b=lhsAzt9fhzubDnIWQIVrszZhC9L3GT7+lVdvHjCLg8S8IcNIEJVUlfTspuW3RiWDQc iCNHvlRFzMB7cAT/LrWjZjoM3Sp1R5PUZFhyjTPrTa8n2o3BVDWGrf45XYMmUM97H2uL OS9gERidewECPuddzpzk/NayJBDflzBz2zyJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=np1HjgSjzYlUyHVWmgc/tZzjXFNnBfU9t+a6FOxMzIzDFI3qxxhk9jomm1CV2zzT9X WKR/Q+dV1jCMdZ48BOGuEsRbDdqL11bCDV1q4H53ZibfQEraSWjeXt/ah9SfwCQ5hFLT nEQdCYfR/FUN59asWzaD76DireidKFsHU6X/Q= MIME-Version: 1.0 Received: by 10.52.185.231 with SMTP id ff7mr5909108vdc.103.1306257736845; Tue, 24 May 2011 10:22:16 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Tue, 24 May 2011 10:22:16 -0700 (PDT) Date: Tue, 24 May 2011 12:22:16 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec548a6cd63c80204a408d430 Subject: [clue] CLUE WG interim - Save the Date, June 23rd, 10am-noon Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:22:19 -0000 --bcaec548a6cd63c80204a408d430 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Based on the doodle, the best day for the next interim meeting is June 23rd, 2011: http://www.doodle.com/uxr58upmwc3783n7 I have updated the CLUE (and RAI) wikis with the information and will post the Webex details to the mailing list and on the wiki as soon as available. http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary CLUE WG co-chair --bcaec548a6cd63c80204a408d430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,=A0

Based on the doodle, the best day for the n= ext interim meeting is June 23rd, 2011:=A0http://www.doodle.com/uxr58upmwc3783n7<= /a>

I have updated the CLUE (and RAI) wikis with the inform= ation and will post the Webex details to the mailing list and on the wiki a= s soon as available.

Regards,
Mary=A0
CLUE WG co-chair

--bcaec548a6cd63c80204a408d430-- From wwwrun@ietfa.amsl.com Tue May 24 14:45:18 2011 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id C750AE06C0; Tue, 24 May 2011 14:45:18 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110524214518.C750AE06C0@ietfa.amsl.com> Date: Tue, 24 May 2011 14:45:18 -0700 (PDT) Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting on June 23, 2011 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, 24 May 2011 21:45:18 -0000 The CLUE WG will hold an interim virtual meeting on: 2011-06-23, 15.00-17.00 GMT (starting at 8.00 Pacific, 10.00 Central, 11.00 Eastern) Agenda and details will be announced on the CLUE WG mailing list (http://www.ietf.org/mail-archive/web/clue/) as soon as available. From mary.ietf.barnes@gmail.com Tue May 24 15:01:32 2011 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 22A1DE07AB for ; Tue, 24 May 2011 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.121, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eORbp+BycGD for ; Tue, 24 May 2011 15:01:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2D38E07B7 for ; Tue, 24 May 2011 15:01:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so6435960vxg.31 for ; Tue, 24 May 2011 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fiQqaT0tihzMywyqqzKMTLjNiRwcp2c0xuuSk9pS7YM=; b=Suk8LC48m6yh6P0nFpynrkFpw/MvUoNKPTJswV+ZxNg0XICd9bqU76azY1nY811Wtw zrRJ2XgGn5O54buykT4dbDvX0HARYOKgJxdx9h1+NHdLDUDx1n9lo/bmo7s9/H66hnST JWghwGrAUKY5K1DJLXezo+ZfZynBdHX6wddLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=U+W++16GwUs29CCmNMy8lrL4FKDoHCSfgdLY6ZjRojgEsJZdr5YEj8eo8OLHUBwNzg S9lDIsAQSyQ714pekRWDG2dHuV3wO/V7o7pgpbeMYhPpN3MFdxWI1V7Jb7CJ7cXfH06Y 9msmk2Tv8YBTeaMsRUxODN3Dyf0xupzhajziw= MIME-Version: 1.0 Received: by 10.52.98.33 with SMTP id ef1mr1520313vdb.23.1306274486023; Tue, 24 May 2011 15:01:26 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Tue, 24 May 2011 15:01:26 -0700 (PDT) In-Reply-To: <211379916.1306271565254.JavaMail.nobody@jsj2wl011.webex.com> References: <211379916.1306271565254.JavaMail.nobody@jsj2wl011.webex.com> Date: Tue, 24 May 2011 17:01:26 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307f354ab7f7ca04a40cba6d Subject: [clue] Fwd: Meeting invitation: CLUE WG Interim Virtual 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, 24 May 2011 22:01:32 -0000 --20cf307f354ab7f7ca04a40cba6d Content-Type: text/plain; charset=ISO-8859-1 Here's the webex information for the meeting. I'll add a link to this email to the CLUE WG wiki. Thanks, Mary. ---------- Forwarded message ---------- From: Cindy Morgan Date: Tue, May 24, 2011 at 4:12 PM Subject: Meeting invitation: CLUE WG Interim Virtual Meeting To: mary.ietf.barnes@gmail.com Hello , Cindy Morgan invites you to attend this online meeting. Topic: CLUE WG Interim Virtual Meeting Date: Thursday, June 23, 2011 Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 966 811 351 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=153507457&UID=1213420297&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=153507457&UID=1213420297&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=153507457&tollFree=0 Access code:966 811 351 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=153507457&UID=1213420297&ICS=MI&LD=1&RD=2&ST=1&SHA2=OsxLmHq0G/LcQtX3PrE4z4mau1wwgX70snj8ZhGedoM=&RT=MiM0 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://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x966811351# 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. --20cf307f354ab7f7ca04a40cba6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's the webex information for the meeting. =A0I'll add a link to= this email to the CLUE WG wiki.

Thanks,
Mary.= =A0

---------- Forwarded message --------= --
From: Cindy Morgan <= messenger@webex.com>Date: Tue, May 24, 2011 at 4:12 PM
Subject: Meeting invitation: CLUE W= G Interim Virtual Meeting
To: mary.ietf.barnes@gmail.co= m



Hello ,

Cindy Morgan invites you to attend this= online meeting.

Topic: CLUE WG Interim Virtual Meeting
Date: Thursday, June 23, = 2011
Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) <= br> Meeting Number: 966 811 351
Meeting Password: (This meeting does n= ot require a password.)


-------------------------------------------------------
To = join the online meeting (Now from mobile devices!)
-------------------= ------------------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?ED= =3D153507457&UID=3D1213420297&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: (This meeting does not require a p= assword.)
4. Click "Join".

To view in other time z= ones or languages, please click the link:
https://workgreen.webex.= com/workgreen/j.php?ED=3D153507457&UID=3D1213420297&ORT=3DMiM0 =

-------------------------------------------------------
To join the audio conference only
-----------------------------------= --------------------
To receive a call back, provide your phone number= when you join the meeting, or call the number below and enter the access c= ode.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbe= rs: https://= workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D15= 3507457&tollFree=3D0

Access code:966 811 351

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

You ca= n contact me at:
cmorgan@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft O= utlook), click this link:
https://workgreen.webex.com/workgreen/j.p= hp?ED=3D153507457&UID=3D1213420297&ICS=3DMI&LD=3D1&RD=3D2&a= mp;ST=3D1&SHA2=3DOsxLmHq0G/LcQtX3PrE4z4mau1wwgX70snj8ZhGedoM=3D&RT= =3DMiM0

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://workgreen.webex.com/workgreen/systemd= iagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+14087926300x966811351#

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.

--20cf307f354ab7f7ca04a40cba6d-- From Even.roni@huawei.com Tue May 24 23:00:39 2011 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 0BED513000A for ; Tue, 24 May 2011 23:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LzFucbvNtkwy for ; Tue, 24 May 2011 23:00:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CC7EAE065B for ; Tue, 24 May 2011 23:00:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00EPBM0X0W@szxga05-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 14:00:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ0020YM0W8M@szxga05-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 14:00:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-31-209.red.bezeqint.net [79.182.31.209]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLQ00CMXM0OEM@szxml11-in.huawei.com>; Wed, 25 May 2011 14:00:32 +0800 (CST) Date: Wed, 25 May 2011 08:58:34 +0300 From: Roni Even In-reply-to: To: 'Stephan Wenger' , clue@ietf.org Message-id: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UkxZpPfKb84zEkVeSEFoSw)" Content-language: en-us Thread-index: AcwWR1wQOFeZgic4SES38N2qxOTWswEWRSPg References: Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 06:00:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_UkxZpPfKb84zEkVeSEFoSw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left" Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt --Boundary_(ID_UkxZpPfKb84zEkVeSEFoSw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Stephan,

About the =
left right directions you suggested 
Left: to =
be interpreted as a stage direction, see =
also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage)<=
/span> 
When =
looking at the reference it looks to me that we were proposing what is =
called "house left" and not "stage =
left"
 =

Roni

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 = AM
To: clue@ietf.org
Subject: [clue] Definitions-00 = posted

 

Hi all,

I just posted the –00 draft, reflecting (hopefully) the outcome = of the discussions of the last six days as well as (hopefully) = addressing most typos.  Comments = welcome.

Stephan

 

http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt

= --Boundary_(ID_UkxZpPfKb84zEkVeSEFoSw)-- From haibin.song@huawei.com Tue May 24 23:45:58 2011 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 0CC85E07BD for ; Tue, 24 May 2011 23:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 mHBp6WAduIkL for ; Tue, 24 May 2011 23:45:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 19B3EE07CB for ; Tue, 24 May 2011 23:45:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ007LMO1F2K@szxga04-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 14:44:03 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00DJBO0QV7@szxga04-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 14:44:03 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 14:43:38 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 25 May 2011 14:43:40 +0800 Date: Wed, 25 May 2011 06:43:40 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.119] To: "Elwell, John" , Paul Kyzivat , "Mike Hammer (hmmr)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [clue] legacy support in requirements Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGA= X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AEFj A7Au FrlQ HGZv Hk8/ JidN MYEE MhJk NJHo Z2eI Z27t aq+t g1vx g+8X ieR8 jFoS; 4; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGgAbQBtAHIAQABjAGkAcwBjAG8ALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBwAGsAeQB6AGkAdgBhAHQAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {AA558C15-ACB5-480B-95C2-9F0018A47E40}; aABhAGkAYgBpAG4ALgBzAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 25 May 2011 06:43:34 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAGwAZQBnAGEAYwB5ACAAcwB1AHAAcABvAHIAdAAgAGkAbgAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzAA== x-cr-puzzleid: {AA558C15-ACB5-480B-95C2-9F0018A47E40} References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 25 May 2011 06:45:58 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Friday, May 20, 2011 4:27 PM > To: Paul Kyzivat; Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 19 May 2011 15:08 > > To: Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > Mike, > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > Paul, > > > > > > What I am trying to say is that Telepresence is all about > > the end-user > > > experience, and that with multiple microphones, speakers, cameras, > > > displays, and data feeds there is more complexity and > > chance to screw > > > that up. And a key point is that spatial relationships are > > significant > > > to the user experience. As a result, more rigor is needed > > to design the > > > system to ensure that backward compatible means that legacy > > systems are > > > handled as such. > > > > > > I am not sure if the protocol design is far enough along to analyze > > > whether correct protocol operation still results in bad > > user experience, > > > but would suggest that if certain key concepts like spatial > > awareness > > > are not understood, then that leg needs to devolve to a known legacy > > > state and handled by the MCU as such. That might mean tagging some > > > parameters as mandatory to understand to force the > > determination and not > > > leave it ambiguous. > > > > > > I believe some current systems treat legacy systems differently and > > > don't expect them to behave like ones that understands the dynamic > > > speaker controls. > > > > I suspect we are talking past each other and are not really > > in disagreement. > > > > I expect that the clue specs, whatever they turn out to be, > > will require > > support for a bunch of existing sip/sdp mechanisms that are generally > > optional and not widely implemented in lower end devices. > > > > If so, then if we have two clueful systems attempting to connect, we > > will be in the realm of negotiating using syntax that both > > understand. > > In that case, this discussion of how to behave when something *isn't* > > understood is moot. Rather that situation will arise when we have a > > clueful system attempting to connect to a clueless system, or visa > > versa. That is where my focus is in this discussion. > [JRE] And furthermore, we might have a conference comprising a number of > CLUEful endpoints and a number of CLUEless endpoints. We would ideally like > to be in a position where the CLUEful endpoint users can share a telepresence > experience, and yet the CLUEless endpoint users can still participate > meaningfully in the conference. > > John > I think this is out of the scope of CLUE WG. > > > > > Further into the future, perhaps we will have clue_v2, > > clue_v3, etc. In > > that case, we may again be into a situation where we have a > > clue_v1_ful > > system that doesn't understand something coming from a clue_v2_ful > > system. When designing any new protocol for clue_v1, we > > should keep in > > mind to specify how to handle that which isn't understood in order to > > support that future scenario. > > I think this will be in the scope of CLUE WG, of course, in the future. -Haibin > > Thanks, > > Paul > > > > > Mike > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat (pkyzivat) > > > Sent: Wednesday, May 18, 2011 7:38 PM > > > To: Mike Hammer (hmmr) > > > Cc: Roni Even; clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote: > > >> Paul, > > >> > > >> Murphy's Law says that if it is possible to put something > > together the > > >> wrong way, > > >> probability says it will go the wrong way sooner or later. > > LTC Murphy > > >> had a > > >> young enlisted guy that always found that wrong way to do things. > > >> System-wise, > > >> the black-swan events occur unless you do your best to design them > > > out. > > >> > > >> Machines are often designed so that there is exactly one > > way to do it. > > >> > > >> We want flexibility in software, but sometimes too much is not so > > > good. > > >> Hopefully, proper operation of the protocol won't look > > like an error. > > > > > > Mike, > > > > > > I don't understand the point you are trying to make in the > > context of > > > this conversation. > > > > > > This started out as a discussion of whether it was > > acceptable to reject > > > an offer because it contains stuff (for the sake of argument lets > > > restrict it to a-lines for now) the the answerer doesn't > > understand/know > > > > > > anything about. > > > > > > Clearly its *possible* for a UA to do that. And since a UA > > can reject > > > things for policy reasons, it may be undecidable whether it rejected > > > because of the unknown lines or for some more justifed reason. > > > > > > But still, I think we can *expect* a UA to refrain from doing that. > > > > > > That doesn't mean they all will. But when they don't, its a > > bug, not a > > > valid implementation choice. > > > > > > Thanks, > > > Paul > > > > > >> Mike > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat (pkyzivat) > > >> Sent: Wednesday, May 18, 2011 1:09 PM > > >> To: Mike Hammer (hmmr) > > >> Cc: Roni Even; clue@ietf.org > > >> Subject: Re: [clue] legacy support in requirements > > >> > > >> > > >> > > >> On 5/18/2011 9:41 AM, Mike Hammer (hmmr) wrote: > > >>> Paul, > > >>> > > >>> I would agree that if the offer-answer model semantic is that here > > > are > > >>> several options and any subset of options is acceptable. > > >>> > > >>> However, if there is any grouping involved such that you > > need to have > > >> a > > >>> video and audio feed integrated to make sense then watch out. > > >>> > > >>> For example, I wouldn't want to end up with the result of a man's > > >> video > > >>> paired with a woman's voice. That could be rather comical. > > >> > > >> Well, SDP defines that you should ignore what you don't > > understand and > > >> operate on what is left. > > >> > > >> So someone constructing an SDP with grouping issues such > > as you define > > >> ought to keep in mind that this could happen, and set things up so > > > that > > >> something reasonable happens. You can't expect the dumb > > legacy device > > > to > > >> > > >> figure out much. > > >> > > >> For your example, the result may be far from ideal, but it still is > > >> likely to be better than no call at all. And if not, there > > is always > > > the > > >> > > >> option of hanging up. But better, presumably the offer > > could have been > > >> constructed in a way that produced a better result. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Mike > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > >> Of > > >>> Paul Kyzivat (pkyzivat) > > >>> Sent: Tuesday, May 17, 2011 7:45 PM > > >>> To: Roni Even > > >>> Cc: clue@ietf.org > > >>> Subject: Re: [clue] legacy support in requirements > > >>> > > >>> > > >>> > > >>> On 5/17/2011 6:05 PM, Roni Even wrote: > > >>>> Paul, > > >>>> I think we read it differently. > > >>>> If the answerer does not support the group attribute and > > the offer > > >> had > > >>> the > > >>>> fid semantics it may look to the answerer as an offer > > with multiple > > >>> m-lines > > >>>> of the same media tyoe. In this case an implementation might also > > >>> decide to > > >>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > >>> Acceptable), > > >>>> because it contains several "m" lines of the same media type. > > >>> > > >>> That is a slightly different story. > > >>> > > >>> Then the reason for rejection is not because it saw an > > attribute it > > >>> didn't understand - its because it didn't like something it *did* > > >>> understand. > > >>> > > >>>> This is very relevant to the multiple streams case and we should > > > look > > >>> if we > > >>>> state this behavior or we will look at providing an approach that > > >> will > > >>> allow > > >>>> the answerer to choose one m-line that the offerer > > prefers even of > > > it > > >>> does > > >>>> not understand CLUE. > > >>> > > >>> IMO (lets see if others differ), if a UA receives an offer with at > > >> least > > >>> > > >>> one m-line it is happy with, then it should not reject the call > > >> because > > >>> there are others that it does not "understand". > > >>> > > >>> Here "understand" means something different - presumably it does > > >>> understand the direct meaning of the additional m-line, it just > > >> doesn't > > >>> understand the *significance* or use of it. > > >>> > > >>> I see little difference to getting to audio m-lines and > > only wanting > > >>> one, and getting one audio and one video and only > > supporting audio. > > > In > > >>> general you should not reject an audio/video call just because you > > >> only > > >>> support audio. > > >>> > > >>> I think it will behoove clue to strongly recommend that > > the m-lines > > > in > > >>> an offer be arranged so the first ones are the ones it most wants > > > used > > >>> if not all are. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>>> Roni > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>> Sent: Wednesday, May 18, 2011 12:37 AM > > >>>>> To: Roni Even > > >>>>> Cc: 'Stephen Botzko'; clue@ietf.org > > >>>>> Subject: Re: [clue] legacy support in requirements > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 5/17/2011 5:20 PM, Roni Even wrote: > > >>>>>> Paul, > > >>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > >> example > > >>>>>> Roni > > >>>>> > > >>>>> OK, I looked. It is consistent with what I said. > > >>>>> Either a=group: is understood, or not. If not, its > > ignored, and not > > >>> put > > >>>>> in the answer. Same with a=mid: > > >>>>> > > >>>>> If a=group: *is* understood, but some parameter within > > it is not, > > >>> there > > >>>>> are explicit rules for what to do. > > >>>>> > > >>>>> AFAICT there are no examples in this document where failure to > > >>>>> understand an a-line in total (or even in part) results in > > > rejecting > > >>>>> the > > >>>>> offer. > > >>>>> > > >>>>> Thanks, > > >>>>> Paul > > >>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > >>> Behalf > > >>>>> Of > > >>>>>>> Paul Kyzivat > > >>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > > >>>>>>> To: Stephen Botzko > > >>>>>>> Cc: clue@ietf.org > > >>>>>>> Subject: Re: [clue] legacy support in requirements > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > >>>>>>> > > >>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > >>>>>>> > > >>>>>>>> When the offer includes parameters that > > the answerer > > >>> does > > >>>>> not > > >>>>>>>> understand > > >>>>>>>> there are two options, he can ignore the unknown > > >>>>> parameters > > >>>>>>> or > > >>>>>>>> reject > > >>>>>>>> the offer. > > >>>>>>>> Rejecting the offer in that case is not > > really kosher. > > >>>>>>>> You are required to ignore parameters you do not > > >> understand. > > >>>>>>>> > > >>>>>>>> If you reject something because you don't like the > > >>> parameters > > >>>>> it > > >>>>>>>> contains, then that is an implicit > > statement that you > > >>>>> understand > > >>>>>>>> those parameters well enough to decide to > > reject them. > > >>>>>>>> > > >>>>>>>> As far as I know, you are always free to reject > > offers, and it > > >>>>>>> doesn't > > >>>>>>>> really imply anything when you do that.. Whether it > > is wise is > > >>>>>>> perhaps > > >>>>>>>> a different question. > > >>>>>>>> Stephen Botzko > > >>>>>>> > > >>>>>>> Certainly you are always free to reject an offer. > > >>>>>>> In general I don't know for certain the reason why, > > and so if I > > >>> give > > >>>>>>> you > > >>>>>>> the benefit of the doubt I will assume you have a > > valid reason - > > >>>>>>> perhaps > > >>>>>>> just policy. > > >>>>>>> > > >>>>>>> But if the reason you reject the offer is based on > > your violating > > >> a > > >>>>>>> spec, then you are non-conforming, whether I can determine you > > > are > > >>>>>>> non-conforming or not. Whether being non-conforming is just > > >>> un-wise, > > >>>>> or > > >>>>>>> something stronger, is a separate discussion. The > > IETF does not > > >>> levy > > >>>>>>> any > > >>>>>>> penalties for violating its specs. But sometimes the > > market does. > > >>>>> (And > > >>>>>>> sometimes not.) But we don't need to endorse non-conforming > > >>> behavior > > >>>>> in > > >>>>>>> our documents. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Paul > > >>>>>>> _______________________________________________ > > >>>>>>> clue mailing list > > >>>>>>> clue@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> clue mailing list > > >>> clue@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From haibin.song@huawei.com Wed May 25 00:02:25 2011 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 9C1A8E06B7 for ; Wed, 25 May 2011 00:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mjDIAiSLmeGR for ; Wed, 25 May 2011 00:02:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 53E84E069A for ; Wed, 25 May 2011 00:02:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ001C3OU6B9@szxga03-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 15:01:18 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00BU7OU6LM@szxga03-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 15:01:18 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 15:01:14 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 25 May 2011 15:01:17 +0800 Date: Wed, 25 May 2011 07:01:17 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.119] To: Mary Barnes , CLUE Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0bSQiscp9+RPty0DLZLLSA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [clue] CLUE WG interim - Save the Date, June 23rd, 10am-noon Central Thread-index: AQHMGjduF62Y608aAkK8QD3kZb6j2pSdHM+g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [clue] CLUE WG interim - Save the Date, June 23rd, 10am-noon Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 07:02:25 -0000 --Boundary_(ID_0bSQiscp9+RPty0DLZLLSA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mary, When deciding the time for the virtual meeting, I mean for the next time, would you please also consider the convenience of people who may also be interested in the discussion but are from the Asia Pacific countries? If the time will be one or two hours earlier, I guess it will be better, although it is still very late in the evening. BR, -Haibin From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, May 25, 2011 1:22 AM To: CLUE Subject: [clue] CLUE WG interim - Save the Date, June 23rd, 10am-noon Central Hi folks, Based on the doodle, the best day for the next interim meeting is June 23rd, 2011: http://www.doodle.com/uxr58upmwc3783n7 I have updated the CLUE (and RAI) wikis with the information and will post the Webex details to the mailing list and on the wiki as soon as available. http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary CLUE WG co-chair --Boundary_(ID_0bSQiscp9+RPty0DLZLLSA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Mary,

 

When deciding the time for the virtual meeting, I mean for the next time, would you please also consider the convenience of people who may also be interested in the discussion but are from the Asia Pacific countries? If the time will be one or two hours earlier, I guess it will be better, although it is still very late in the evening.

 

BR,

-Haibin

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Wednesday, May 25, 2011 1:22 AM
To: CLUE
Subject: [clue] CLUE WG interim - Save the Date, June 23rd, 10am-noon Central

 

Hi folks, 

 

Based on the doodle, the best day for the next interim meeting is June 23rd, 2011: http://www.doodle.com/uxr58upmwc3783n7

 

I have updated the CLUE (and RAI) wikis with the information and will post the Webex details to the mailing list and on the wiki as soon as available.

 

Regards,

Mary 

CLUE WG co-chair

 

--Boundary_(ID_0bSQiscp9+RPty0DLZLLSA)-- From haibin.song@huawei.com Wed May 25 00:20:59 2011 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 C129FE06B2 for ; Wed, 25 May 2011 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 hfe+trdJLQzw for ; Wed, 25 May 2011 00:20:54 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3CE06C4 for ; Wed, 25 May 2011 00:20:54 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ0099DPO81N@szxga05-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 15:19:20 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00KI3PO7E4@szxga05-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 15:19:20 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 15:19:15 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 25 May 2011 15:19:18 +0800 Date: Wed, 25 May 2011 07:19:18 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.119] To: Stephan Wenger , "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Definitions-00 posted Thread-index: AQHMFkdcf8pxJxvtvUWY2iOao8Hw2JSdKdRA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 07:20:59 -0000 Hi Stephan, Thanks for the good draft. When reading about the definition for the "endpoint". It says: The logical point of final termination through receiving, decoding and rend= ering, and/or initiation through capturing, encoding, and sending of media= streams.An endpoint consists of one or more physical devices which source = and sink media streams, and exactly one [RFC4353] Participant (which, in tu= rn, includes exactly one SIP User Agent)... So here what is the definition for "Participant"? Is it a person, a device,= or an endpoint? I think it should mean endpoint. But the text is confusing= . BR, -Haibin From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Thursday, May 19, 2011 4:08 PM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the disc= ussions of the last six days as well as (hopefully) addressing most typos. = =A0Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt From pkyzivat@cisco.com Wed May 25 05:40:33 2011 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 7E07DE0657 for ; Wed, 25 May 2011 05:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.277 X-Spam-Level: X-Spam-Status: No, score=-110.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UqobG5dvuxV9 for ; Wed, 25 May 2011 05:40:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D5253E0723 for ; Wed, 25 May 2011 05:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1298; q=dns/txt; s=iport; t=1306327232; x=1307536832; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F9jWB9t+v0fEuPDCr/5ubo6sHMK5V5c27F70OECzZN0=; b=IjHHjOZjoz8l8GRmX1YpZnskCPBqPwYcBMBWJLCiDbEUOiaDGP7vY+3R gZC6rhF83nq6gnOnKtLA1ajR13pgncBMERt+48ctFenKK2PyrpKd7hPFC jci0gzFBg1lcS2mddvj+ahWFbIbyA7tO9DyBrNJ3SOxeKxJ7SquJIPPOG 0=; X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="363932248" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 25 May 2011 12:40:31 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4PCeUxZ024493; Wed, 25 May 2011 12:40:31 GMT Message-ID: <4DDCF8BE.8050007@cisco.com> Date: Wed, 25 May 2011 08:40:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Songhaibin References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.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] legacy support in requirements 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, 25 May 2011 12:40:33 -0000 Songhaibin, On 5/25/2011 2:43 AM, Songhaibin wrote: >>> I suspect we are talking past each other and are not really >>> in disagreement. >>> >>> I expect that the clue specs, whatever they turn out to be, >>> will require >>> support for a bunch of existing sip/sdp mechanisms that are generally >>> optional and not widely implemented in lower end devices. >>> >>> If so, then if we have two clueful systems attempting to connect, we >>> will be in the realm of negotiating using syntax that both >>> understand. >>> In that case, this discussion of how to behave when something *isn't* >>> understood is moot. Rather that situation will arise when we have a >>> clueful system attempting to connect to a clueless system, or visa >>> versa. That is where my focus is in this discussion. >> [JRE] And furthermore, we might have a conference comprising a number of >> CLUEful endpoints and a number of CLUEless endpoints. We would ideally like >> to be in a position where the CLUEful endpoint users can share a telepresence >> experience, and yet the CLUEless endpoint users can still participate >> meaningfully in the conference. > I think this is out of the scope of CLUE WG. Can you be more precise? Exactly what do you think is out of scope? Thanks, Paul From john.elwell@siemens-enterprise.com Wed May 25 06:59:51 2011 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 A65FBE0714 for ; Wed, 25 May 2011 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 PIvLgpmJ1RWH for ; Wed, 25 May 2011 06:59:51 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id B3961E0697 for ; Wed, 25 May 2011 06:59:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1306331989!6069491!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 29440 invoked from network); 25 May 2011 13:59:49 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-216.messagelabs.com with SMTP; 25 May 2011 13:59:49 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6BD071EB83D3; Wed, 25 May 2011 15:59:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 25 May 2011 15:59:49 +0200 From: "Elwell, John" To: Songhaibin , Paul Kyzivat , "Mike Hammer (hmmr)" Date: Wed, 25 May 2011 15:59:47 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGD/7v0yMA== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 25 May 2011 13:59:51 -0000 =20 > -----Original Message----- > From: Songhaibin [mailto:haibin.song@huawei.com]=20 > Sent: 25 May 2011 07:44 > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 > On Behalf Of > > Elwell, John > > Sent: Friday, May 20, 2011 4:27 PM > > To: Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: 19 May 2011 15:08 > > > To: Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > Mike, > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > Paul, > > > > > > > > What I am trying to say is that Telepresence is all about > > > the end-user > > > > experience, and that with multiple microphones,=20 > speakers, cameras, > > > > displays, and data feeds there is more complexity and > > > chance to screw > > > > that up. And a key point is that spatial relationships are > > > significant > > > > to the user experience. As a result, more rigor is needed > > > to design the > > > > system to ensure that backward compatible means that legacy > > > systems are > > > > handled as such. > > > > > > > > I am not sure if the protocol design is far enough=20 > along to analyze > > > > whether correct protocol operation still results in bad > > > user experience, > > > > but would suggest that if certain key concepts like spatial > > > awareness > > > > are not understood, then that leg needs to devolve to a=20 > known legacy > > > > state and handled by the MCU as such. That might mean=20 > tagging some > > > > parameters as mandatory to understand to force the > > > determination and not > > > > leave it ambiguous. > > > > > > > > I believe some current systems treat legacy systems=20 > differently and > > > > don't expect them to behave like ones that understands=20 > the dynamic > > > > speaker controls. > > > > > > I suspect we are talking past each other and are not really > > > in disagreement. > > > > > > I expect that the clue specs, whatever they turn out to be, > > > will require > > > support for a bunch of existing sip/sdp mechanisms that=20 > are generally > > > optional and not widely implemented in lower end devices. > > > > > > If so, then if we have two clueful systems attempting to=20 > connect, we > > > will be in the realm of negotiating using syntax that both > > > understand. > > > In that case, this discussion of how to behave when=20 > something *isn't* > > > understood is moot. Rather that situation will arise when=20 > we have a > > > clueful system attempting to connect to a clueless system, or visa > > > versa. That is where my focus is in this discussion. > > [JRE] And furthermore, we might have a conference=20 > comprising a number of > > CLUEful endpoints and a number of CLUEless endpoints. We=20 > would ideally like > > to be in a position where the CLUEful endpoint users can=20 > share a telepresence > > experience, and yet the CLUEless endpoint users can still=20 > participate > > meaningfully in the conference. > >=20 > > John > >=20 >=20 > I think this is out of the scope of CLUE WG. [JRE] I don't know why you say that. In fact it is covered in the use cases= draft, section 4.5. John From stewe@stewe.org Wed May 25 07:21:09 2011 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 1F4F213002F for ; Wed, 25 May 2011 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, 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 QQJHeNHa4LsK for ; Wed, 25 May 2011 07:21:07 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9005E130024 for ; Wed, 25 May 2011 07:21:07 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4557-1743317 for multiple; Wed, 25 May 2011 16:21:05 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 25 May 2011 07:21:00 -0700 From: Stephan Wenger To: Songhaibin , "clue@ietf.org" Message-ID: Thread-Topic: Definitions-00 posted In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 14:21:09 -0000 I tought that, by having the reference [RFC4353] right next to "Participant", it would be clear from context that one has to use the definition of Participant of RFC4353. Isn't it? Stephan On 5.25.2011 00:19 , "Songhaibin" wrote: >Hi Stephan, > >Thanks for the good draft. > >When reading about the definition for the "endpoint". It says: > >The logical point of final termination through receiving, decoding and >rendering, and/or initiation through capturing, encoding, and sending of >media streams.An endpoint consists of one or more physical devices which >source and sink media streams, and exactly one [RFC4353] Participant >(which, in turn, includes exactly one SIP User Agent)... > >So here what is the definition for "Participant"? Is it a person, a >device, or an endpoint? I think it should mean endpoint. But the text is >confusing. > >BR, >-Haibin > > > > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Stephan Wenger >Sent: Thursday, May 19, 2011 4:08 PM >To: clue@ietf.org >Subject: [clue] Definitions-00 posted > >Hi all, >I just posted the -00 draft, reflecting (hopefully) the outcome of the >discussions of the last six days as well as (hopefully) addressing most >typos. Comments welcome. >Stephan > >http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt From stewe@stewe.org Wed May 25 07:23:24 2011 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 8C5C6130034 for ; Wed, 25 May 2011 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 7+-QYQS+9ZhQ for ; Wed, 25 May 2011 07:23:23 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6174F13002F for ; Wed, 25 May 2011 07:23:22 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4559-1743317 for multiple; Wed, 25 May 2011 16:23:21 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 25 May 2011 07:23:15 -0700 From: Stephan Wenger To: Roni Even , Message-ID: Thread-Topic: [clue] Definitions-00 posted In-Reply-To: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389153000_9518976" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 14:23:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389153000_9518976 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Would like to hear Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as long as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure tha= t the RFC editor will let us get away with unstable wikipedia references=8A) Stephan From: Roni Even Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger , Subject: RE: [clue] Definitions-00 posted Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left" =20 Roni =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted =20 Hi all, I just posted the =AD00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan =20 http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt --B_3389153000_9518976 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Would like to hear Steve Bot= zko's opinion here, as I believe to recall he suggested the use of "stage le= ft" first.
I personally don't care whether we take "stage" or "hou= se" viewpoint, as long as we pick one of the two.
(Has anyone a mo= re stable reference for stage directions?  I'm not sure that the RFC ed= itor will let us get away with unstable wikipedia references…)
Stephan


Fr= om: Roni Even <Even.roni@hu= awei.com>
Date: Wed, 25 May= 2011 08:58:34 +0300
To: Stephan W= enger <stewe@stewe.org>, <clue@ietf.org>
Subject: RE: [clue] Definitions-00 posted

<= /div>

Hi Stephan,

About the left right directions you suggested 
L=
eft: to be interpreted as a stage direction, see also[StageDirection(Wikipad=
ia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When looking at the reference it looks to me that we were p=
roposing what is called "house left" and not "stage left"<=
/pre>
=
 
Roni
 <=
/span>
 
 
--B_3389153000_9518976-- From stephen.botzko@gmail.com Wed May 25 07:41:48 2011 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 690EDE074A for ; Wed, 25 May 2011 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=0.354, 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 za4YlUWNMAAs for ; Wed, 25 May 2011 07:41:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25434E0747 for ; Wed, 25 May 2011 07:41:47 -0700 (PDT) Received: by vxg33 with SMTP id 33so7054543vxg.31 for ; Wed, 25 May 2011 07:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GUZRZ7enTQM667BxCcbJTBkXqd+3JQLYJV/15iRjb8A=; b=EBfuRK3o0sROoZboJG8iQC+DuU6jTNv6s3wN7WtyzqnLdQlqBPsyuYvk/wAfneJcpi gol35XWAnWAmAkIyDdf/9pMImqjgHWwrnrxZxo9zZpd3wfj8oUETHi8Mb7+2eRi3/W6z 3fKq5fIMNkA6Xsuvcly3Bn5QKRW4B6m8JgQZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NqKU5QzOuc1iHqH/bkFjdFnMKskmRq1Jo+k5tU6XnYf3iFyUrfl7kMQSwy7VlN/LrS muCbMe8B5zv2/udUkiHCd9nulXIrwrDYy+v4tOs30wbyY1jZDin9TZoJbuykOGgoZQXg UKerPDo9s95a6TZ14p1PSMLcceZWA0tlOuleo= MIME-Version: 1.0 Received: by 10.52.176.10 with SMTP id ce10mr7247182vdc.280.1306334506504; Wed, 25 May 2011 07:41:46 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 07:41:46 -0700 (PDT) In-Reply-To: References: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> Date: Wed, 25 May 2011 10:41:46 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=bcaec51a818437d28104a41ab4be Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 14:41:48 -0000 --bcaec51a818437d28104a41ab4be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural. "House Left" is more natural if you want to describe spatial relationships from the perspective of humans in the receiving room. Though since we are unlikely to have a lot of normative text for rendering in receivers, "Stage Left" seems more useful to me. However, I have no objection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote: > Would like to hear Steve Botzko's opinion here, as I believe to recall he > suggested the use of "stage left" first. > I personally don't care whether we take "stage" or "house" viewpoint, as > long as we pick one of the two. > (Has anyone a more stable reference for stage directions? I'm not sure > that the RFC editor will let us get away with unstable wikipedia > references=85) > Stephan > > > From: Roni Even > Date: Wed, 25 May 2011 08:58:34 +0300 > To: Stephan Wenger , > Subject: RE: [clue] Definitions-00 posted > > Hi Stephan, > > About the left right directions you suggested > > Left: to be interpreted as a stage direction, see also[StageDirection(Wik= ipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) > > When looking at the reference it looks to me that we were proposing what = is called "house left" and not "stage left" > > > > Roni > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Stephan Wenger > *Sent:* Thursday, May 19, 2011 11:08 AM > *To:* clue@ietf.org > *Subject:* [clue] Definitions-00 posted > > > > Hi all, > > I just posted the =9600 draft, reflecting (hopefully) the outcome of the > discussions of the last six days as well as (hopefully) addressing most > typos. Comments welcome. > > Stephan > > > > http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec51a818437d28104a41ab4be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you want to describe the spatial relationships from a perspective of a s= ender (more precisely a human in the sending room), then "stage left&q= uot; is more natural.

"House Left"=A0 is more natural if y= ou want to describe spatial relationships from the perspective of humans in= the receiving room.=A0

Though since we are unlikely to have a lot of normative text for render= ing in receivers, "Stage Left" seems more useful to me.=A0 Howeve= r, I have no objection to defining both terms.

Steve B,



On Wed, May 25, 2011 at 10:23 AM, Stephan We= nger <stewe@stewe.o= rg> wrote:
Would like to hear Steve Botzko's opini= on here, as I believe to recall he suggested the use of "stage left&qu= ot; first.
I personally don't care whether we take "stage" or "= ;house" viewpoint, as long as we pick one of the two.
(Has a= nyone a more stable reference for stage directions? =A0I'm not sure tha= t the RFC editor will let us get away with unstable wikipedia references=85= )
Stephan


From: Roni Even <Even.roni@huawei.com>Date: Wed, 25 May 2011 08:58:34 += 0300
To: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: RE: [clue] Definitions-00 po= sted

Hi Stephan,

About t=
he left right directions you suggested 
Left: to be interpreted as a s=
tage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When lo=
oking at the reference it looks to me that we were proposing what is called=
 "house left" and not "stage left"
=A0

Roni
=A0
=A0<=
/span>


=A0


From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan W=
enger

Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: [cl=
ue] Definitions-00 posted
=A0<=
/p>


Hi all,
I just posted the =9600 draft, reflecting (hopefully) the outcome of th=
e discussions of the last six days as well as (hopefully) addressing most t=
ypos. =A0Comments welcome.


Stephan
=A0

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


--bcaec51a818437d28104a41ab4be-- From stephen.botzko@gmail.com Wed May 25 07:53:28 2011 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 5AFD213006A for ; Wed, 25 May 2011 07:53:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tfHqRPiumv9 for ; Wed, 25 May 2011 07:53:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B222130061 for ; Wed, 25 May 2011 07:53:27 -0700 (PDT) Received: by vxg33 with SMTP id 33so7065801vxg.31 for ; Wed, 25 May 2011 07:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6i83toRT0NdZY0BsypOKbgNVxQS6uFJUEAFXtKM5HIU=; b=b21Uoxb2+8Ns57kBzh4sGjHBZ75SJh2z+n4kZNdQU4mzk1UPdYRuVn2Vg98oOgjtup a6pGhUaMzPif4wIkWuAU5Y88hhAOZkJQDztumanDhaCE6Nlju3P2AMiCFn0k0CEUQ/Gd zPSIIqiZGKjZoQkZf7XZdWtGF2zKnGX7rmH8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qIyS2q4zalISNyDBonW7290nTA7pIq3x5FX31ORwt0HXMB8pUPZgfVXqxwSqqA5DlL zRxHKYw+pwXqNpgUoF2/kiBM+iDhpevP7pE+DNUwGlByGmJh/ytzbEx9kEl2T3QxCehs SwkdccTMtAMFkxTcZXM8XFuKI4McrFtotoKQY= MIME-Version: 1.0 Received: by 10.52.76.4 with SMTP id g4mr56787vdw.40.1306335206829; Wed, 25 May 2011 07:53:26 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 07:53:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2011 10:53:26 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=20cf3071cdaef5ee0a04a41add94 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 14:53:28 -0000 --20cf3071cdaef5ee0a04a41add94 Content-Type: text/plain; charset=ISO-8859-1 The current draft of the use case document uses word "participants" to mean persons. There are likely to be related requirements that also need to refer to human participants. In any event, we will need a consistent way to distinguish people who are participating in the conference from devices and endpoints. "Remote participant" sounds more natural to native English speakers than using "remote person" or "remote human". Stephen Botzko On Wed, May 25, 2011 at 10:21 AM, Stephan Wenger wrote: > I tought that, by having the reference [RFC4353] right next to > "Participant", it would be clear from context that one has to use the > definition of Participant of RFC4353. Isn't it? > Stephan > > > On 5.25.2011 00:19 , "Songhaibin" wrote: > > >Hi Stephan, > > > >Thanks for the good draft. > > > >When reading about the definition for the "endpoint". It says: > > > >The logical point of final termination through receiving, decoding and > >rendering, and/or initiation through capturing, encoding, and sending of > >media streams.An endpoint consists of one or more physical devices which > >source and sink media streams, and exactly one [RFC4353] Participant > >(which, in turn, includes exactly one SIP User Agent)... > > > >So here what is the definition for "Participant"? Is it a person, a > >device, or an endpoint? I think it should mean endpoint. But the text is > >confusing. > > > >BR, > >-Haibin > > > > > > > > > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >Stephan Wenger > >Sent: Thursday, May 19, 2011 4:08 PM > >To: clue@ietf.org > >Subject: [clue] Definitions-00 posted > > > >Hi all, > >I just posted the -00 draft, reflecting (hopefully) the outcome of the > >discussions of the last six days as well as (hopefully) addressing most > >typos. Comments welcome. > >Stephan > > > >http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3071cdaef5ee0a04a41add94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The current draft of the use case document uses word "participants&quo= t; to mean persons.=A0 There are likely to be related requirements that als= o need to refer to human participants.

In any event, we will need a = consistent way to distinguish people=A0 who are participating in the confer= ence from devices and endpoints. "Remote participant" sounds more= natural to native=20 English speakers than using "remote person" or "remote human= ".

Stephen Botzko


On Wed, May 25, 2011 at 10:21 AM, Stepha= n Wenger <stewe@ste= we.org> wrote:
I tought that, by having the reference [RFC4353] right next to
"Participant", it would be clear from context that one has to use= the
definition of Participant of RFC4353. =A0Isn't it?
Stephan


On 5.25.2011 00:19 , "Songhaibin" <haibin.song@huawei.com> wrote:

>Hi Stephan,
>
>Thanks for the good draft.
>
>When reading about the definition for the "endpoint". It says= :
>
>The logical point of final termination through receiving, decoding and<= br> >rendering, and/or initiation through =A0capturing, encoding, and sendin= g of
>media streams.An endpoint consists of one or more physical devices whic= h
>source and sink media streams, and exactly one [RFC4353] Participant >(which, in turn, includes exactly one SIP User Agent)...
>
>So here what is the definition for "Participant"? Is it a per= son, a
>device, or an endpoint? I think it should mean endpoint. But the text i= s
>confusing.
>
>BR,
>-Haibin
>
>
>
>
>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>Stephan Wenger
>Sent: Thursday, May 19, 2011 4:08 PM
>To: clue@ietf.org
>Subject: [clue] Definitions-00 posted
>
>Hi all,
>I just posted the -00 draft, reflecting (hopefully) the outcome of the<= br> >discussions of the last six days as well as (hopefully) addressing most=
>typos. =A0Comments welcome.
>Stephan
>
>http://www.ietf.org/id/draft-wenger-clue-definitions-00.= txt


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

--20cf3071cdaef5ee0a04a41add94-- From Even.roni@huawei.com Wed May 25 08:46:38 2011 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 C99AD130055 for ; Wed, 25 May 2011 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TmZTsuVg9PYv for ; Wed, 25 May 2011 08:46:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 41140130035 for ; Wed, 25 May 2011 08:46:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLR00IK2D5GU7@szxga03-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 23:46:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLR003THD5GLL@szxga03-in.huawei.com> for clue@ietf.org; Wed, 25 May 2011 23:46:28 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-31-209.red.bezeqint.net [79.182.31.209]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLR00JFJD56PK@szxml12-in.huawei.com>; Wed, 25 May 2011 23:46:28 +0800 (CST) Date: Wed, 25 May 2011 18:44:27 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' , 'Stephan Wenger' Message-id: <01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/related; boundary="Boundary_(ID_x5j4w/ReHkqp7D/cwnFfEg)" Content-language: en-us Thread-index: Acwa6fNjBivnUU3GRWmkVtrhvH+QEQAB6lQg References: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 15:46:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_x5j4w/ReHkqp7D/cwnFfEg) Content-type: multipart/alternative; boundary="Boundary_(ID_8OHNDw7bwmNhRWeOLOa8AQ)" --Boundary_(ID_8OHNDw7bwmNhRWeOLOa8AQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Steve, According to Wikipedia Monitor 1 Monitor 2 Monitor 3 Participant Here monitor 1 is house left and stage right. Monitor 3 is house right and stage left. Assuming that the local participant is the house. I do not care which one we pick, I just thought that during the conference call we mentioned using house left and right Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 25, 2011 5:42 PM To: Stephan Wenger Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Definitions-00 posted If you want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural. "House Left" is more natural if you want to describe spatial relationships from the perspective of humans in the receiving room. Though since we are unlikely to have a lot of normative text for rendering in receivers, "Stage Left" seems more useful to me. However, I have no objection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote: Would like to hear Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as long as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure that the RFC editor will let us get away with unstable wikipedia references.) Stephan From: Roni Even Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger , Subject: RE: [clue] Definitions-00 posted Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left" Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_8OHNDw7bwmNhRWeOLOa8AQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Steve,

 

According to Wikipedia

 

 

 


Monitor =    1         =             &= nbsp;           &n= bsp;       Monitor = 2            =             &= nbsp;           &n= bsp;       Monitor = 3            =             &= nbsp;    

 

 

 


           &nbs= p;            = ;            =             =

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   Participant

 

Here monitor 1 is house left and stage right. Monitor 3 is house = right and stage left.  Assuming that the local participant is the = house.

I do not care which one we pick, I just thought that during the = conference call we mentioned using house left and = right

 

Roni

 

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Wednesday, May 25, 2011 5:42 PM
To: Stephan = Wenger
Cc: Roni Even; clue@ietf.org
Subject: Re: = [clue] Definitions-00 posted

 

If you want to describe the spatial = relationships from a perspective of a sender (more precisely a human in = the sending room), then "stage left" is more = natural.

"House Left"  is more natural if you want = to describe spatial relationships from the perspective of humans in the = receiving room. 

Though since we are unlikely to have a lot = of normative text for rendering in receivers, "Stage Left" = seems more useful to me.  However, I have no objection to defining = both terms.

Steve B,


On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger = <stewe@stewe.org> = wrote:

Would like to hear Steve Botzko's opinion here, as I believe to recall = he suggested the use of "stage left" = first.

I personally don't care whether we take "stage" or = "house" viewpoint, as long as we pick one of the = two.

(Has anyone a more stable reference for stage directions?  I'm not = sure that the RFC editor will let us get away with unstable wikipedia = references…)

Stephan

 

 

From: Roni Even <Even.roni@huawei.com>
Date: Wed, 25 = May 2011 08:58:34 +0300
To: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: RE: [clue] = Definitions-00 posted

 

Hi Stephan,

About the left right directions you suggested 
Left: to be interpreted as a stage direction, see =
also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage)<=
/span> 
When looking at the reference it looks to me that we were proposing =
what is called "house left" and not "stage =
left"
 
Roni

 

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 = AM
To: clue@ietf.org
Subject: [clue] = Definitions-00 posted

 

Hi all,

I just posted the –00 draft, reflecting (hopefully) the outcome = of the discussions of the last six days as well as (hopefully) = addressing most typos.  Comments welcome.

Stephan

 


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

 

= --Boundary_(ID_8OHNDw7bwmNhRWeOLOa8AQ)-- --Boundary_(ID_x5j4w/ReHkqp7D/cwnFfEg) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --Boundary_(ID_x5j4w/ReHkqp7D/cwnFfEg) Content-id: Content-type: image/png; name=image002.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image002.png iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --Boundary_(ID_x5j4w/ReHkqp7D/cwnFfEg)-- From keith.drage@alcatel-lucent.com Wed May 25 08:55:18 2011 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 8C21EE068C for ; Wed, 25 May 2011 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.038 X-Spam-Level: X-Spam-Status: No, score=-105.038 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, 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 yOYpsyuiJVDk for ; Wed, 25 May 2011 08:55:16 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id A17DCE067C for ; Wed, 25 May 2011 08:55:15 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4PFt88a010500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 17:55:09 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 May 2011 17:55:09 +0200 From: "DRAGE, Keith (Keith)" To: Roni Even , "'Stephen Botzko'" , "'Stephan Wenger'" Date: Wed, 25 May 2011 17:55:07 +0200 Thread-Topic: [clue] Definitions-00 posted Thread-Index: Acwa6fNjBivnUU3GRWmkVtrhvH+QEQAB6lQgAABwfmA= Message-ID: References: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> <01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> In-Reply-To: <01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 15:55:18 -0000 --_005_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_ Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_" --_000_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note that in theatre parlance "house left" and "house right" are not genera= lly used in the UK. Generally we refer to "auditorium left" and "auditorium= right". Note that "stage house" refers to everything behind the proscenium= so use of "house" can be confusing in this context. Of course we could always use "prompt side (PS) " and "off prompt (OP)"!!! Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 25 May 2011 16:44 To: 'Stephen Botzko'; 'Stephan Wenger' Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted Steve, According to Wikipedia [cid:image001.gif@01CC1AFC.803D8D20] [cid:image001.gif@01CC1AFC.803D8D20] [cid:image0= 01.gif@01CC1AFC.803D8D20] Monitor 1 Monitor 2 = Monitor 3 [cid:image002.gif@01CC1AFC.803D8D20] Participant Here monitor 1 is house left and stage right. Monitor 3 is house right and = stage left. Assuming that the local participant is the house. I do not care which one we pick, I just thought that during the conference = call we mentioned using house left and right Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 25, 2011 5:42 PM To: Stephan Wenger Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Definitions-00 posted If you want to describe the spatial relationships from a perspective of a s= ender (more precisely a human in the sending room), then "stage left" is mo= re natural. "House Left" is more natural if you want to describe spatial relationships= from the perspective of humans in the receiving room. Though since we are unlikely to have a lot of normative text for rendering = in receivers, "Stage Left" seems more useful to me. However, I have no obj= ection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger > wrote: Would like to hear Steve Botzko's opinion here, as I believe to recall he s= uggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as lo= ng as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure tha= t the RFC editor will let us get away with unstable wikipedia references...= ) Stephan From: Roni Even > Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger >, > Subject: RE: [clue] Definitions-00 posted Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikip= adia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is= called "house left" and not "stage left" Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the disc= ussions of the last six days as well as (hopefully) addressing most typos. = Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note that in theatre parlance “h= ouse left” and “house right” are not generally used in the UK. Generally we refer to = 220;auditorium left” and “auditorium right”. Note that “stage hous= e” refers to everything behind the proscenium so use of “house” can be confusing in thi= s context.

 

Of course we could always use “p= rompt side (PS) ” and “off prompt (OP)”!!!<= /p>

 

Keith

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 25 May 2011 16:44
To: 'Stephen Botzko'; 'Steph= an Wenger'
Cc: clue@ietf.org
Subject: Re: [clue] Definiti= ons-00 posted

 

Steve,

 

According to Wikipedia

 

 

 


Monitor    1         &n= bsp;            = ;            &n= bsp;      Monitor 2            &n= bsp;            = ;            &n= bsp;      Monitor 3            &n= bsp;            = ;    

 

 

 


  &n= bsp;            = ;            &n= bsp;            = ;       

  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           Participant

 

Here monitor 1= is house left and stage right. Monitor 3 is house right and stage left.  Assuming that the local participant is the house. <= /font>

I do not care = which one we pick, I just thought that during the conference call we mentioned us= ing house left and right

 

Roni

 

 

From:= Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, May 25, 201= 1 5:42 PM
To: Stephan Wenger
Cc: Roni Even; clue@ietf.org=
Subject: Re: [clue] Definiti= ons-00 posted

 

If y= ou want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural.

"House Left"  is more natural if you want to describe spatia= l relationships from the perspective of humans in the receiving room.  <= br>
Though since we are unlikely to have a lot of normative text for rendering = in receivers, "Stage Left" seems more useful to me.  However, I have no objection to defining both terms.

Steve B,

On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger= <stewe@stewe.org> wrote:

Would like to he= ar Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first.

I personally don= 't care whether we take "stage" or "house" viewpoint, as l= ong as we pick one of the two.

(Has anyone a mo= re stable reference for stage directions?  I'm not sure that the RFC edit= or will let us get away with unstable wikipedia references…)<= /span>

Stephan

 

 

From: Roni Even <Even.roni@huawei.com= >
Date: Wed, 25 May 2011 08:58= :34 +0300
To: Stephan Wenger <stewe@stewe.org>, = <clue@ietf.org>
Subject: RE: [clue] Definiti= ons-00 posted

 

Hi Stephan,

About the left right directions you=
 suggested 
Left: to be interpreted as a stage directi=
on, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki=
/Blocking_(stage) 
When looking at the reference it looks to =
me that we were proposing what is called "house left" and not &qu=
ot;stage left"
 
Roni

 

 =

 =

From: clue-bounces@ietf.org [mailto:clue-bounces= @ietf.org] On Behalf Of Stephan Wenger<= br> Sent: Thursday, May 19, 2011= 11:08 AM
To: clue@ietf.org
Subject: [clue] Definitions-= 00 posted

 

Hi all,<= span lang=3DEN-US style=3D'color:black'>

I just posted the –00 draft, reflect= ing (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos.  Comments welcome.

Stephan<= span lang=3DEN-US style=3D'color:black'>

 


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

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_-- --_005_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=199; creation-date="Wed, 25 May 2011 17:55:07 GMT"; modification-date="Wed, 25 May 2011 17:55:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhVAAnAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAABT ACYAgQAAAAAAAP///wECAwJ6RI6py+0PoxK02ouz3rz7enziSJZYaKbqSqHsC3NuTNdzjbN3zpd7 D/T8gsTMsIhsBZLM07IJFRyjvSk1Z73antpitgv7gnXccbVsxqLTW/bZzRPDR/L5p27v4PObPd+4 9mfiJ2hBWKiEuHKIyFjoKAj5J0FZaXnpUAAAOw== --_005_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=169; creation-date="Wed, 25 May 2011 17:55:07 GMT"; modification-date="Wed, 25 May 2011 17:55:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhJAAVAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAj ABMAgQAAAAAAAM3Nzf///wJchI8Qy90JIxu0WssiXLd7umhK8JVemJDm2gWI2nKn3BrwFQj6DeoC X3EBgzRcEadgKWfLJibpbAqjUiiV5bKChqVj1hbjboHfw3HsOA9QEvGKLRq5MfD4K42PFwAAOw== --_005_EDC0A1AE77C57744B664A310A0B23AE21F9D10ADFRMRSSXCHMBSC3d_-- From stephen.botzko@gmail.com Wed May 25 09:02:12 2011 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 5D701E0774 for ; Wed, 25 May 2011 09:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 MMOb6PDd0lR3 for ; Wed, 25 May 2011 09:02:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41756E0763 for ; Wed, 25 May 2011 09:02:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so7130309vxg.31 for ; Wed, 25 May 2011 09:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ln36VZBOg2DVM90RWL8xr9WtoYruy2B6KH7RY6ZLtBY=; b=rcXMJlZxpxdGVfh25eit0UFTWxiIQkDv9d1nVERNagmMUPppD2LmRPEghP858ruuX6 wocdGe+XHgcvaB4GFmGlaJs0ul/tseD43Yq1UFdy2ECwQ82WM+4so5xL2Pml3yZC4brp a2w2D0FdQIX69wmauf6aaWecB5mCv5PQC2KKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vTwdHoIFTVF5n8Z4OIRgQz9LohHJ6g4MUjShFNf9liqERaEtpOomURJt3qt0GjIn/1 4z+PIh4wlfWDRVll6mlNTBVNlpMAuBzMZdqkcGZ44keosFc5pheFwBfkLjOSmRZIHO0d B7adfvThS1qD1SGIwZHT4rZVyfXZ16j4LRwvA= MIME-Version: 1.0 Received: by 10.52.98.198 with SMTP id ek6mr7749197vdb.240.1306339330667; Wed, 25 May 2011 09:02:10 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 09:02:10 -0700 (PDT) In-Reply-To: <01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> References: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com> <01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> Date: Wed, 25 May 2011 12:02:10 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/related; boundary=20cf307abdebc2b67c04a41bd308 Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 16:02:12 -0000 --20cf307abdebc2b67c04a41bd308 Content-Type: multipart/alternative; boundary=20cf307abdebc2b67804a41bd307 --20cf307abdebc2b67804a41bd307 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This depends on where you think the stage is! Though I agree that monitor 3 is house right, and that the stream it is displaying is stage left. BTW, I don't recall a "house left" discussion in the conference call, but perhaps I missed it. Steve B. On Wed, May 25, 2011 at 11:44 AM, Roni Even wrote: > Steve, > > > > According to Wikipedia > > > > > > > > Monitor 1 Monitor > 2 Monitor > 3 > > > > > > > > > > > Participa= nt > > > > Here monitor 1 is house left and stage right. Monitor 3 is house right an= d > stage left. Assuming that the local participant is the house. > > I do not care which one we pick, I just thought that during the conferenc= e > call we mentioned using house left and right > > > > Roni > > > > > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, May 25, 2011 5:42 PM > *To:* Stephan Wenger > *Cc:* Roni Even; clue@ietf.org > *Subject:* Re: [clue] Definitions-00 posted > > > > If you want to describe the spatial relationships from a perspective of a > sender (more precisely a human in the sending room), then "stage left" is > more natural. > > "House Left" is more natural if you want to describe spatial relationshi= ps > from the perspective of humans in the receiving room. > > Though since we are unlikely to have a lot of normative text for renderin= g > in receivers, "Stage Left" seems more useful to me. However, I have no > objection to defining both terms. > > Steve B, > > > On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote: > > Would like to hear Steve Botzko's opinion here, as I believe to recall he > suggested the use of "stage left" first. > > I personally don't care whether we take "stage" or "house" viewpoint, as > long as we pick one of the two. > > (Has anyone a more stable reference for stage directions? I'm not sure > that the RFC editor will let us get away with unstable wikipedia > references=85) > > Stephan > > > > > > *From: *Roni Even > *Date: *Wed, 25 May 2011 08:58:34 +0300 > *To: *Stephan Wenger , > *Subject: *RE: [clue] Definitions-00 posted > > > > Hi Stephan, > > About the left right directions you suggested > > Left: to be interpreted as a stage direction, see also[StageDirection(Wik= ipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) > > When looking at the reference it looks to me that we were proposing what = is called "house left" and not "stage left" > > > > Roni > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Stephan Wenger > *Sent:* Thursday, May 19, 2011 11:08 AM > *To:* clue@ietf.org > *Subject:* [clue] Definitions-00 posted > > > > Hi all, > > I just posted the =9600 draft, reflecting (hopefully) the outcome of the > discussions of the last six days as well as (hopefully) addressing most > typos. Comments welcome. > > Stephan > > > > http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > --20cf307abdebc2b67804a41bd307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This depends on where you think the stage is!=A0=A0 Though I agree that mon= itor 3 is house right, and that the stream it is displaying is stage left.<= br>
BTW, I don't recall a "house left"=A0 discussion in th= e conference call, but perhaps I missed it.

Steve B.


On Wed, May 25, 2011 at = 11:44 AM, Roni Even <Even.roni@huawei.com> wrote:

Steve,

=A0

According to Wikipedia

=A0

=A0

=A0


Monitor =A0=A0=A01=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 Monitor 2=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 Monit= or 3=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

<= /tr>
=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 Participant

=A0

Here monitor 1 is house left and stage right. Monitor 3 is house right = and stage left. =A0Assuming that the local participant is the house.

I do = not care which one we pick, I just thought that during the conference call = we mentioned using house left and right

=A0

Roni<= /span>

=A0

=A0

From: Stephen Botzko [mail= to:stephen.bo= tzko@gmail.com]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stephan WengerCc: Roni Even; = clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

=A0

If you want to descr= ibe the spatial relationships from a perspective of a sender (more precisel= y a human in the sending room), then "stage left" is more natural= .

"House Left"=A0 is more natural if you want to describe spati= al relationships from the perspective of humans in the receiving room.=A0 <= br>
Though since we are unlikely to have a lot of normative text for ren= dering in receivers, "Stage Left" seems more useful to me.=A0 How= ever, I have no objection to defining both terms.

Steve B,


On Wed, May 25, 201= 1 at 10:23 AM, Stephan Wenger <stewe@stewe.org> wrote:

Would like to hear Steve Botzk= o's opinion here, as I believe to recall he suggested the use of "= stage left" first.

I personally don't care whether w= e take "stage" or "house" viewpoint, as long as we pick= one of the two.

(Has anyone a more stable reference for stage directions? =A0I'm no= t sure that the RFC editor will let us get away with unstable wikipedia ref= erences=85)

Stephan

=A0

<= span style=3D"font-size:10.5pt;color:black">=A0

From: Ro= ni Even <Even.= roni@huawei.com>
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wenger &= lt;stewe@stewe.org= >, <clue@ietf.org<= /a>>
Subject: RE: [clue] Definitions-00 posted

=

= =A0

Hi Stephan,<= /span>

About the left right dire=
ctions you suggested 
<=
span style=3D"font-size:11.0pt;color:black">Left: to be interpreted as a st=
age direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When looking at the refer=
ence it looks to me that we were proposing what is called "house left&=
quot; and not "stage left"
=A0
Roni

=A0

=A0

=A0

From: clue-bounces@= ietf.org [ma= ilto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: [cl= ue] Definitions-00 posted

=A0

Hi all= ,

I just posted the =9600 = draft, reflecting (hopefully) the outcome of the discussions of the last si= x days as well as (hopefully) addressing most typos. =A0Comments welcome.

Stephan

=A0


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

=A0


--20cf307abdebc2b67804a41bd307-- --20cf307abdebc2b67c04a41bd308 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: c12f968778fc1fb1_0.2 iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --20cf307abdebc2b67c04a41bd308 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: c12f968778fc1fb1_0.1 iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --20cf307abdebc2b67c04a41bd308-- From stewe@stewe.org Wed May 25 09:17:51 2011 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 B9D2BE0771 for ; Wed, 25 May 2011 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396] 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 bvbV3ps4W31o for ; Wed, 25 May 2011 09:17:49 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 623C6E0722 for ; Wed, 25 May 2011 09:17:48 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4599-1743317 for multiple; Wed, 25 May 2011 18:17:47 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 25 May 2011 09:17:36 -0700 From: Stephan Wenger To: Stephen Botzko , Roni Even Message-ID: Thread-Topic: [clue] Definitions-00 posted In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3389159865_9975090" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 16:17:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389159865_9975090 Content-type: multipart/alternative; boundary="B_3389159865_9938471" --B_3389159865_9938471 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I don't recall discussion about "house left" either. Steve, take a look at the wikipedia page mentioned. It may be that wikipedia and you disagree about what "stage left" actually is. From what = I understood there (which is consistent with what I thought during the call): stage directions are from the viewpoint of an actor facing the crowd, not from the crowd's viewpoint. Stephan From: Stephen Botzko Date: Wed, 25 May 2011 12:02:10 -0400 To: Roni Even Cc: Stephan Wenger , Subject: Re: [clue] Definitions-00 posted This depends on where you think the stage is! Though I agree that monitor 3 is house right, and that the stream it is displaying is stage left. BTW, I don't recall a "house left" discussion in the conference call, but perhaps I missed it. Steve B. On Wed, May 25, 2011 at 11:44 AM, Roni Even wrote: > Steve, > =20 > According to Wikipedia > =20 > =20 > =20 >=20 >=20 > Monitor 1 Monitor 2 > Monitor 3 =20 > =20 > =20 > =20 >=20 >=20 > =20 > Participa= nt > =20 > Here monitor 1 is house left and stage right. Monitor 3 is house right an= d > stage left. Assuming that the local participant is the house. > I do not care which one we pick, I just thought that during the conferenc= e > call we mentioned using house left and right > =20 > Roni > =20 > =20 >=20 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, May 25, 2011 5:42 PM > To: Stephan Wenger > Cc: Roni Even; clue@ietf.org > Subject: Re: [clue] Definitions-00 posted >=20 > =20 > If you want to describe the spatial relationships from a perspective of a > sender (more precisely a human in the sending room), then "stage left" is= more > natural. >=20 > "House Left" is more natural if you want to describe spatial relationshi= ps > from the perspective of humans in the receiving room. >=20 > Though since we are unlikely to have a lot of normative text for renderin= g in > receivers, "Stage Left" seems more useful to me. However, I have no obje= ction > to defining both terms. >=20 > Steve B, >=20 >=20 > On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote: >=20 > Would like to hear Steve Botzko's opinion here, as I believe to recall he > suggested the use of "stage left" first. >=20 > I personally don't care whether we take "stage" or "house" viewpoint, as = long > as we pick one of the two. >=20 > (Has anyone a more stable reference for stage directions? I'm not sure t= hat > the RFC editor will let us get away with unstable wikipedia references=8A) >=20 > Stephan >=20 > =20 >=20 > =20 >=20 > From: Roni Even > Date: Wed, 25 May 2011 08:58:34 +0300 > To: Stephan Wenger , > Subject: RE: [clue] Definitions-00 posted >=20 > =20 >=20 > Hi Stephan, > About the left right directions you suggested > Left: to be interpreted as a stage direction, see > also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(s= tage) > > When looking at the reference it looks to me that we were proposing what = is > called "house left" and not "stage left" > =20 > Roni > =20 > =20 > =20 >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Thursday, May 19, 2011 11:08 AM > To: clue@ietf.org > Subject: [clue] Definitions-00 posted > =20 >=20 > Hi all, >=20 > I just posted the =AD00 draft, reflecting (hopefully) the outcome of the > discussions of the last six days as well as (hopefully) addressing most t= ypos. > Comments welcome. >=20 > Stephan >=20 > =20 >=20 > http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =20 >=20 >=20 --B_3389159865_9938471 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I don't recall discussion ab= out "house left" either.
Steve, take a look at the wikipedia page = mentioned.  It may be that wikipedia and you disagree about what "stage= left" actually is.  From what I understood there (which is consistent = with what I thought during the call): stage directions are from the viewpoin= t of an actor facing the crowd, not from the crowd's viewpoint.
St= ephan


From: <= /span> Stephen Botzko <stephen.= botzko@gmail.com>
Date: Wed= , 25 May 2011 12:02:10 -0400
To: R= oni Even <Even.roni@huawei.com&= gt;
Cc: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: <= /span> Re: [clue] Definitions-00 posted

This depends= on where you think the stage is!   Though I agree that monitor 3 = is house right, and that the stream it is displaying is stage left.

B= TW, I don't recall a "house left"  discussion in the conference call, b= ut perhaps I missed it.

Steve B.


= On Wed, May 25, 2011 at 11:44 AM, Roni Even <Even.roni@huawei.com> wrote:

Steve,=

 =

According to Wikipedia

=  

 

 =


Monitor    1      &nb= sp;            &= nbsp;            = ;         Monitor 2   = ;            &nb= sp;            &= nbsp;            = ;   Monitor 3         = ;            &nb= sp;       

 

 

 <= p>


          &nbs= p;            &n= bsp;            =            

 &n= bsp;            =             &nbs= p;            &n= bsp;            =             Participa= nt

 

Here monitor 1 is house left and stage right. Monitor 3 is house r= ight and stage left.  Assuming that the local participant is the house.=

I do not care which one we pick, I just thought that during the conference= call we mentioned using house left and right

 

Roni

 

<= p class=3D"MsoNormal"> 

= From: Stephen Botzko [mailto:stephen.botzko@gmail.co= m]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stepha= n Wenger
Cc: Roni Even; clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

&n= bsp;

If you want to des= cribe the spatial relationships from a perspective of a sender (more precise= ly a human in the sending room), then "stage left" is more natural.

"= House Left"  is more natural if you want to describe spatial relationsh= ips from the perspective of humans in the receiving room. 

Thou= gh since we are unlikely to have a lot of normative text for rendering in re= ceivers, "Stage Left" seems more useful to me.  However, I have no obje= ction to defining both terms.

Steve B,


On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger <stewe@stewe.org> wrote:

=

Would l= ike to hear Steve Botzko's opinion here, as I believe to recall he suggested= the use of "stage left" first.

I personally don't care whether we = take "stage" or "house" viewpoint, as long as we pick one of the two.=

(Has anyone a more stable reference for stage directions?  I'm not s= ure that the RFC editor will let us get away with unstable wikipedia referen= ces…)

Stephan

 

 

Fr= om: Roni Even <Even.roni@huawei.com&g= t;
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wen= ger <stewe@stewe.org= >, <clue@ietf.org&g= t;
Subject: RE: [clue] Definitions-00 posted

=

&n= bsp;

Hi Stephan,<= /p>

About the left right dire=
ctions you suggested 
Left: to be interpreted as a stage di=
rection, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
=
When looking at the reference it looks to me that we were proposing what is =
called "house left" and not "stage left"
 
Roni

&= nbsp;

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of= Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 AM
To= : clue@ietf.org
Subject: [clue] Definitions-00 posted<= /span>

 <= /span>

Hi all,

I just posted the ̵= 1;00 draft, reflecting (hopefully) the outcome of the discussions of the las= t six days as well as (hopefully) addressing most typos.  Comments welc= ome.

Stephan


_______________= ________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listi= nfo/clue

 


--B_3389159865_9938471-- --B_3389159865_9975090 Content-type: image/png; name="image002.png" Content-ID: Content-disposition: inline; filename="image002.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlz AAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALD SURBVEjHxVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo 5FBoJjPWrY6ObpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0 /OS4Kg83sSZsNlvbarX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0 NG61WtTtdkmt9Ho9gk8ikbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oS EIvAV/IOKYfza8lgMKCDg4PRzs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dS gMvLSzo5OaFqtUrTqTLuer0u2uK5qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6d nVE0GhVt8czn84qgarXazGKxvJ8nRyNwB/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+ VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiLpxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYB ZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBgGmBELfLQ7t7e3lcwqFQwiwqFwlozTK5D wUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMGpUiQ6CCo9Krhj+/4kVQqRW63m3w+ H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZVdMdfBXB8B3BkRC7rj2PD4XDc LIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmVAYHUEKJU4IMrBvFxNqf8 sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDSnWm+N2fnzCqnhbmN ad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --B_3389159865_9975090 Content-type: image/png; name="image001.png" Content-ID: Content-disposition: inline; filename="image001.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlz AAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABp SURBVGje7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUo UKBABRQoUAEFClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K 8pZyQ1kAAAAASUVORK5CYII= --B_3389159865_9975090-- From hmmr@cisco.com Wed May 25 09:33:01 2011 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 84BF0E0814 for ; Wed, 25 May 2011 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.124 X-Spam-Level: X-Spam-Status: No, score=-9.124 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 GSCcuMIDGT+J for ; Wed, 25 May 2011 09:32:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E6A8EE074E for ; Wed, 25 May 2011 09:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=32254; q=dns/txt; s=iport; t=1306341178; x=1307550778; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=vi7TK+L6OOOXXg14kjPw0dNMVZZOQt8vLCKxFkJWC/Y=; b=f5qSki4VO4VkID9Nptak2ylBh2E4cdlldVZ1OHRNiKMG+eRGF+jtRYjd /RRA7WBHuiSCj+hWRv5B98YsfWhrL8AVLBtd4tf04ZM/HU1bn1ZT8B9rC CklJLfm9BCe9tFKR+LRoaEJnDQHpGTMFn+lALyx7SP8xhTKW0w2J910TX 0=; X-Files: image003.png, image004.png : 233, 835 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncCAGMu3U2tJV2Z/2dsb2JhbACCElSVAYZxh1R4p26deIYcBIZbjhSEGIZN X-IronPort-AV: E=Sophos;i="4.65,268,1304294400"; d="png'150?scan'150,208,217,150";a="323400524" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 25 May 2011 16:32:57 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4PGWviJ008850; Wed, 25 May 2011 16:32:57 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 11:32:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC1AF9.6736F6C5" Date: Wed, 25 May 2011 11:32:55 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions-00 posted Thread-Index: Acwa6fNjBivnUU3GRWmkVtrhvH+QEQAB6lQgAABwfmAAAXKPMA== References: <018a01cc1aa0$cc74fbd0$655ef370$%roni@huawei.com><01fc01cc1af2$a5d3c9f0$f17b5dd0$%roni@huawei.com> From: "Mike Hammer (hmmr)" To: "DRAGE, Keith (Keith)" , "Roni Even" , "Stephen Botzko" , "Stephan Wenger" X-OriginalArrivalTime: 25 May 2011 16:32:57.0024 (UTC) FILETIME=[675D2C00:01CC1AF9] Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 16:33:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1AF9.6736F6C5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC1AF9.6736F6C5" ------_=_NextPart_002_01CC1AF9.6736F6C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, =20 And we could always table this. ;) =20 How about viewer left and viewer right? That should be self-explanatory. =20 Sorry, I was not a theater major in college. =20 Mike =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, May 25, 2011 11:55 AM To: Roni Even; 'Stephen Botzko'; 'Stephan Wenger' Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted =20 Note that in theatre parlance "house left" and "house right" are not generally used in the UK. Generally we refer to "auditorium left" and "auditorium right". Note that "stage house" refers to everything behind the proscenium so use of "house" can be confusing in this context.=20 =20 Of course we could always use "prompt side (PS) " and "off prompt (OP)"!!! =20 Keith =20 ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 25 May 2011 16:44 To: 'Stephen Botzko'; 'Stephan Wenger' Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted =20 Steve, =20 According to Wikipedia =09 =09 =09 =09 =20 =20 =20 Monitor 1 Monitor 2 Monitor 3 =20 =20 =20 =09 =09 =20 =20 =20 Participant =20 Here monitor 1 is house left and stage right. Monitor 3 is house right and stage left. Assuming that the local participant is the house.=20 I do not care which one we pick, I just thought that during the conference call we mentioned using house left and right =20 Roni =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, May 25, 2011 5:42 PM To: Stephan Wenger Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Definitions-00 posted =20 If you want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural. "House Left" is more natural if you want to describe spatial relationships from the perspective of humans in the receiving room. =20 Though since we are unlikely to have a lot of normative text for rendering in receivers, "Stage Left" seems more useful to me. However, I have no objection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote: Would like to hear Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as long as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure that the RFC editor will let us get away with unstable wikipedia references...) Stephan =20 =20 From: Roni Even Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger , Subject: RE: [clue] Definitions-00 posted =20 Hi Stephan, About the left right directions you suggested=20 Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)].=20 http://en.wikipedia.org/wiki/Blocking_(stage) =20 When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left" =20 Roni =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted =20 Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan =20 http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_002_01CC1AF9.6736F6C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

 

And we = could always table this. ;)

 

How = about viewer left and viewer right?  That should be = self-explanatory.

 

Sorry, = I was not a theater major in college.

 

Mike

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = DRAGE, Keith (Keith)
Sent: Wednesday, May 25, 2011 11:55 = AM
To: Roni Even; 'Stephen Botzko'; 'Stephan = Wenger'
Cc: clue@ietf.org
Subject: Re: [clue] = Definitions-00 posted

 

No= te that in theatre parlance “house left” and “house = right” are not generally used in the UK. Generally we refer to = “auditorium left” and “auditorium right”. Note = that “stage house” refers to everything behind the = proscenium so use of “house” can be confusing in this = context.

 

Of= course we could always use “prompt side (PS) ” and = “off prompt (OP)”!!!

 

Ke= ith

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: 25 May 2011 16:44
To: 'Stephen = Botzko'; 'Stephan Wenger'
Cc: clue@ietf.org
Subject: = Re: [clue] Definitions-00 posted

 

Steve,

 

According to Wikipedia

 

 

 


Monitor =    1         =             &= nbsp;           &n= bsp;       Monitor = 2            =             &= nbsp;           &n= bsp;       Monitor = 3            =             &= nbsp;    

 

 

 


           &nbs= p;            = ;            =             =

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   Participant

 

Here monitor 1 is house left and stage right. Monitor 3 is house = right and stage left.  Assuming that the local participant is the = house.

I do not care which one we pick, I just thought that during the = conference call we mentioned using house left and = right

 

Roni

 

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Wednesday, May 25, 2011 5:42 PM
To: Stephan = Wenger
Cc: Roni Even; clue@ietf.org
Subject: Re: = [clue] Definitions-00 posted

 

If you want to describe the spatial = relationships from a perspective of a sender (more precisely a human in = the sending room), then "stage left" is more = natural.

"House Left"  is more natural if you want = to describe spatial relationships from the perspective of humans in the = receiving room. 

Though since we are unlikely to have a lot = of normative text for rendering in receivers, "Stage Left" = seems more useful to me.  However, I have no objection to defining = both terms.

Steve B,

On = Wed, May 25, 2011 at 10:23 AM, Stephan Wenger <stewe@stewe.org> = wrote:

Would like to hear Steve Botzko's opinion here, as I believe to recall = he suggested the use of "stage left" = first.

I personally don't care whether we take "stage" or = "house" viewpoint, as long as we pick one of the = two.

(Has anyone a more stable reference for stage directions?  I'm not = sure that the RFC editor will let us get away with unstable wikipedia = references…)

Stephan

 

 

From: Roni Even <Even.roni@huawei.com>
Date: Wed, 25 = May 2011 08:58:34 +0300
To: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: RE: [clue] = Definitions-00 posted

 

Hi Stephan,

About the left right directions you suggested 
Left: to be interpreted as a stage direction, see =
also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage)<=
/span> 
When looking at the reference it looks to me that we were proposing =
what is called "house left" and not "stage =
left"
 
Roni

 

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 = AM
To: clue@ietf.org
Subject: [clue] = Definitions-00 posted

 

Hi all,

I just posted the –00 draft, reflecting (hopefully) the outcome = of the discussions of the last six days as well as (hopefully) = addressing most typos.  Comments welcome.

Stephan

 


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

 

------_=_NextPart_002_01CC1AF9.6736F6C5-- ------_=_NextPart_001_01CC1AF9.6736F6C5 Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.png Content-Location: image003.png iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= ------_=_NextPart_001_01CC1AF9.6736F6C5 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== ------_=_NextPart_001_01CC1AF9.6736F6C5-- From stephen.botzko@gmail.com Wed May 25 10:48:26 2011 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 7A82FE06A1 for ; Wed, 25 May 2011 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 a5ob-gnhv5aZ for ; Wed, 25 May 2011 10:48:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3034E0686 for ; Wed, 25 May 2011 10:48:24 -0700 (PDT) Received: by vws12 with SMTP id 12so7248363vws.31 for ; Wed, 25 May 2011 10:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kqcF9TPoFWwyd1r8YJ6TC11c1BOntnbZsbH0xQGBjjU=; b=NmNyaFftEgcLV9bKjbZr/t4G/C/Clg0aLh0ujNTVRBVlp2KKvz60TB1WCbaQim/wv+ MokTUbvqrOmJPpidJGne0blXmZBX0CR3th5CTI0j4KYL3zuSdzQ0pvWYFaZw6il5XmAT 8vQuYuBHTYjgxc2Ty1xlOaEt8oBROGcc49jLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j4KTRII5B014iKo0ekPlmd42DWVn3XUjBur56v93+KT7cS+/rAKI/sVFqkg/OhwRDx VALxCrmVTqCnvGD2vaZCn3xTccXcqYAbMpbkZYr5FD0RoUl/wjPa3pccGIIIHzUfBMnM jE/0GDMS5CEM3IqjcwDLDA4eRyhCxkuyPfWQY= MIME-Version: 1.0 Received: by 10.52.184.98 with SMTP id et2mr529886vdc.285.1306345704009; Wed, 25 May 2011 10:48:24 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 10:48:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2011 13:48:23 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/related; boundary=bcaec548a067a4320504a41d4fee Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 17:48:26 -0000 --bcaec548a067a4320504a41d4fee Content-Type: multipart/alternative; boundary=bcaec548a067a431f804a41d4fed --bcaec548a067a431f804a41d4fed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I agree that "stage left" is from the viewpoint of the actor (which I am interpreting as the sending human participant). So if you are seated in the center, and I am on your left, then I am "stage left" (and in a 3-strea= m telepresence system, I would be carried in the "left" stream, and displayed on Monitor 3 in Roni's diagram). Whether it is actually necessary to describe Monitor 3 as left or right is unclear to me; I am thinking we are mostly describing spatial relationships of streams, not display devices. However, from a receiving perspective, th= e monitors represent the far-end stage. So it would be sensible to label the monitor as "audience right". What's tricky here is that there are two "stages", one at each end of the call. So we don't want to call Monitor 3 the "stage left" monitor, since i= t is on the right of the local "stage". Maybe consistently using "stage left" for streams and sending, and "audienc= e right" or "house right" for receiving and rendering of the"stage left" stream is the best answer. It does make the required reversal explicit. Stephen Botzko On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger wrote: > I don't recall discussion about "house left" either. > Steve, take a look at the wikipedia page mentioned. It may be that > wikipedia and you disagree about what "stage left" actually is. From wha= t I > understood there (which is consistent with what I thought during the call= ): > stage directions are from the viewpoint of an actor facing the crowd, not > from the crowd's viewpoint. > Stephan > > > From: Stephen Botzko > Date: Wed, 25 May 2011 12:02:10 -0400 > To: Roni Even > Cc: Stephan Wenger , > > Subject: Re: [clue] Definitions-00 posted > > This depends on where you think the stage is! Though I agree that monit= or > 3 is house right, and that the stream it is displaying is stage left. > > BTW, I don't recall a "house left" discussion in the conference call, bu= t > perhaps I missed it. > > Steve B. > > > On Wed, May 25, 2011 at 11:44 AM, Roni Even wrote: > >> Steve, >> >> >> >> According to Wikipedia >> >> >> >> >> >> >> >> Monitor 1 Monitor >> 2 Monitor >> 3 >> >> >> >> >> >> >> >> >> >> >> >> Participant >> >> >> >> Here monitor 1 is house left and stage right. Monitor 3 is house right a= nd >> stage left. Assuming that the local participant is the house. >> >> I do not care which one we pick, I just thought that during the conferen= ce >> call we mentioned using house left and right >> >> >> >> Roni >> >> >> >> >> >> *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Wednesday, May 25, 2011 5:42 PM >> *To:* Stephan Wenger >> *Cc:* Roni Even; clue@ietf.org >> *Subject:* Re: [clue] Definitions-00 posted >> >> >> >> If you want to describe the spatial relationships from a perspective of = a >> sender (more precisely a human in the sending room), then "stage left" i= s >> more natural. >> >> "House Left" is more natural if you want to describe spatial >> relationships from the perspective of humans in the receiving room. >> >> Though since we are unlikely to have a lot of normative text for renderi= ng >> in receivers, "Stage Left" seems more useful to me. However, I have no >> objection to defining both terms. >> >> Steve B, >> >> >> On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger wrote= : >> >> Would like to hear Steve Botzko's opinion here, as I believe to recall h= e >> suggested the use of "stage left" first. >> >> I personally don't care whether we take "stage" or "house" viewpoint, as >> long as we pick one of the two. >> >> (Has anyone a more stable reference for stage directions? I'm not sure >> that the RFC editor will let us get away with unstable wikipedia >> references=85) >> >> Stephan >> >> >> >> >> >> *From: *Roni Even >> *Date: *Wed, 25 May 2011 08:58:34 +0300 >> *To: *Stephan Wenger , >> *Subject: *RE: [clue] Definitions-00 posted >> >> >> >> Hi Stephan, >> >> About the left right directions you suggested >> >> Left: to be interpreted as a stage direction, see also[StageDirection(Wi= kipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) >> >> When looking at the reference it looks to me that we were proposing what= is called "house left" and not "stage left" >> >> >> >> Roni >> >> >> >> >> >> >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] >> *On Behalf Of *Stephan Wenger >> *Sent:* Thursday, May 19, 2011 11:08 AM >> *To:* clue@ietf.org >> *Subject:* [clue] Definitions-00 posted >> >> >> >> Hi all, >> >> I just posted the =9600 draft, reflecting (hopefully) the outcome of the >> discussions of the last six days as well as (hopefully) addressing most >> typos. Comments welcome. >> >> Stephan >> >> >> >> http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> > > --bcaec548a067a431f804a41d4fed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I agree that "stage left" is from the viewpoint of the actor= (which I am interpreting as the sending human participant).=A0 So if you a= re seated in the center, and I am on your left, then I am "stage left&= quot; (and in a 3-stream telepresence system, I would be carried in the &qu= ot;left" stream, and displayed on Monitor 3 in Roni's diagram).
Whether it is actually necessary to describe Monitor 3 as left or right= is unclear to me; I am thinking we are mostly describing spatial relations= hips of streams, not display devices.=A0 However, from a receiving perspect= ive, the monitors represent the far-end stage.=A0 So it would be sensible t= o label the monitor as "audience right".=A0

What's tricky here is that there are two "stages", one at= each end of the call.=A0 So we don't want to call Monitor 3 the "= stage left" monitor, since it is on the right of the local "stage= ".=A0

Maybe consistently using "stage left" for streams and sending= , and "audience right" or "house right" for receiving a= nd rendering of the"stage left" stream is the best answer.=A0 It = does make the required reversal explicit.

Stephen Botzko


On Wed, May 25, 20= 11 at 12:17 PM, Stephan Wenger <stewe@stewe.org> wrote:
I don't recall discussion about "h= ouse left" either.
Steve, take a look at the wikipedia page = mentioned. =A0It may be that wikipedia and you disagree about what "st= age left" actually is. =A0From what I understood there (which is consi= stent with what I thought during the call): stage directions are from the v= iewpoint of an actor facing the crowd, not from the crowd's viewpoint.<= /div>
Stephan


From: Stephen Botzko <stephen.botzko@gmail= .com>
Date: Wed, 25 May = 2011 12:02:10 -0400
To: Roni Even <Even.roni@huawei.com>
<= span style=3D"font-weight:bold">Cc: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>

Subject: = Re: [clue] Definitions-00 posted

This depends on where you think the sta= ge is!=A0=A0 Though I agree that monitor 3 is house right, and that the str= eam it is displaying is stage left.

BTW, I don't recall a "house left"=A0 discussion in the c= onference call, but perhaps I missed it.

Steve B.


On Wed, May 25, 2011 at 11:44 AM, Roni Even <Even= .roni@huawei.com> wrote:

Steve,

=A0

According to Wikipedia

=
=
=A0

= =A0

=A0


Monitor =A0=A0=A01=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 Monitor 2=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 Monitor 3=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

<= /tr>
=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 Participant

=A0

Here monitor 1 is house left and stage right. Monitor 3 is house right = and stage left. =A0Assuming that the local participant is the house.

I do = not care which one we pick, I just thought that during the conference call = we mentioned using house left and right

=A0

Roni<= /span>

=A0

=A0

From: Stephen Botzko [mail= to:stephen.bo= tzko@gmail.com]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stephan WengerCc: Roni Even; = clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

=A0

If you want to describe the spati= al relationships from a perspective of a sender (more precisely a human in = the sending room), then "stage left" is more natural.

"House Left"=A0 is more natural if you want to describe spati= al relationships from the perspective of humans in the receiving room.=A0 <= br>
Though since we are unlikely to have a lot of normative text for ren= dering in receivers, "Stage Left" seems more useful to me.=A0 How= ever, I have no objection to defining both terms.

Steve B,


On Wed, May 25, 201= 1 at 10:23 AM, Stephan Wenger <stewe@stewe.org> wrote:

Would like to hear Steve Botzk= o's opinion here, as I believe to recall he suggested the use of "= stage left" first.

I personally don't care whether w= e take "stage" or "house" viewpoint, as long as we pick= one of the two.

(Has anyone a more stable reference for stage directions? =A0I'm no= t sure that the RFC editor will let us get away with unstable wikipedia ref= erences=85)

Stephan

=A0

<= span style=3D"font-size:10.5pt;color:black">=A0

From: Ro= ni Even <Even.= roni@huawei.com>
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wenger &= lt;stewe@stewe.org= >, <clue@ietf.org<= /a>>
Subject: RE: [clue] Definitions-00 posted

=

= =A0

Hi Stephan,<= /span>

About the left right dire=
ctions you suggested 
<=
span style=3D"font-size:11.0pt;color:black">Left: to be interpreted as a st=
age direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When looking at the refer=
ence it looks to me that we were proposing what is called "house left&=
quot; and not "stage left"
=A0
Roni

=A0

=A0

=A0

From: clue-bounces@= ietf.org [ma= ilto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: [cl= ue] Definitions-00 posted

=A0

Hi all= ,

I just posted the =9600 = draft, reflecting (hopefully) the outcome of the discussions of the last si= x days as well as (hopefully) addressing most typos. =A0Comments welcome.

Stephan

=A0


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

=A0


<= /span>

--bcaec548a067a431f804a41d4fed-- --bcaec548a067a4320504a41d4fee Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 3610b922eabdd6d5_0.1 iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --bcaec548a067a4320504a41d4fee Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 3610b922eabdd6d5_0.2 iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --bcaec548a067a4320504a41d4fee-- From mark.gorzynski@hp.com Wed May 25 11:20:22 2011 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 B5737E0756 for ; Wed, 25 May 2011 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.77 X-Spam-Level: X-Spam-Status: No, score=-105.77 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 J1UfjI64jQCR for ; Wed, 25 May 2011 11:20:16 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9ABE0717 for ; Wed, 25 May 2011 11:20:16 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 888E714E5D for ; Wed, 25 May 2011 18:20:15 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 18:19:46 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.240]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Wed, 25 May 2011 18:19:45 +0000 From: "Gorzynski, Mark E (The Right One)" To: "clue@ietf.org" Date: Wed, 25 May 2011 18:19:39 +0000 Thread-Topic: [clue] Definitions-00 posted Thread-Index: AcwbBAP8XkgH+Rz3TDuLu5PPgxPumwAA31ZQ Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B77BC831@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 18:20:22 -0000 --_005_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_ Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_" --_000_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My concern is establishing a convention for spatial order. As I am writing= this text, I am writing from left to right, top to bottom. That simple co= nvention for ASCII characters allows us all to read this. It is not the on= ly convention and perhaps not even the best but it is one we share. It is insufficient to specify order without the receiver knowing the sense = of the order for reproduction. I suggest that left is the participant's left as that person views the repr= oduction. I further suggest that spatial order be defined as left to right= . (you can add top to bottom if you wish). Thus receiving streams labeled [0, 1, 2, ..] would be interpreted as starti= ng on the left and tiled in raster fashion to the right. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: Wednesday, May 25, 2011 10:48 AM To: Stephan Wenger Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted Yes, I agree that "stage left" is from the viewpoint of the actor (which I = am interpreting as the sending human participant). So if you are seated in= the center, and I am on your left, then I am "stage left" (and in a 3-stre= am telepresence system, I would be carried in the "left" stream, and displa= yed on Monitor 3 in Roni's diagram). Whether it is actually necessary to describe Monitor 3 as left or right is = unclear to me; I am thinking we are mostly describing spatial relationships= of streams, not display devices. However, from a receiving perspective, t= he monitors represent the far-end stage. So it would be sensible to label = the monitor as "audience right". What's tricky here is that there are two "stages", one at each end of the c= all. So we don't want to call Monitor 3 the "stage left" monitor, since it= is on the right of the local "stage". Maybe consistently using "stage left" for streams and sending, and "audienc= e right" or "house right" for receiving and rendering of the"stage left" st= ream is the best answer. It does make the required reversal explicit. Stephen Botzko On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger > wrote: I don't recall discussion about "house left" either. Steve, take a look at the wikipedia page mentioned. It may be that wikiped= ia and you disagree about what "stage left" actually is. From what I under= stood there (which is consistent with what I thought during the call): stag= e directions are from the viewpoint of an actor facing the crowd, not from = the crowd's viewpoint. Stephan From: Stephen Botzko > Date: Wed, 25 May 2011 12:02:10 -0400 To: Roni Even > Cc: Stephan Wenger >, > Subject: Re: [clue] Definitions-00 posted This depends on where you think the stage is! Though I agree that monitor= 3 is house right, and that the stream it is displaying is stage left. BTW, I don't recall a "house left" discussion in the conference call, but = perhaps I missed it. Steve B. On Wed, May 25, 2011 at 11:44 AM, Roni Even > wrote: Steve, According to Wikipedia [cid:image001.png@01CC1ACD.985D7020] [cid:image001.png@01CC1ACD.985D7020] [cid:image001.png@01CC1ACD.985D7020] Monitor 1 Monitor 2 = Monitor 3 [cid:image002.png@01CC1ACD.985D7020] Participant Here monitor 1 is house left and stage right. Monitor 3 is house right and = stage left. Assuming that the local participant is the house. I do not care which one we pick, I just thought that during the conference = call we mentioned using house left and right Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 25, 2011 5:42 PM To: Stephan Wenger Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Definitions-00 posted If you want to describe the spatial relationships from a perspective of a s= ender (more precisely a human in the sending room), then "stage left" is mo= re natural. "House Left" is more natural if you want to describe spatial relationships= from the perspective of humans in the receiving room. Though since we are unlikely to have a lot of normative text for rendering = in receivers, "Stage Left" seems more useful to me. However, I have no obj= ection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger > wrote: Would like to hear Steve Botzko's opinion here, as I believe to recall he s= uggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as lo= ng as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure tha= t the RFC editor will let us get away with unstable wikipedia references...= ) Stephan From: Roni Even > Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger >, > Subject: RE: [clue] Definitions-00 posted Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikip= adia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is= called "house left" and not "stage left" Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the disc= ussions of the last six days as well as (hopefully) addressing most typos. = Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My concer= n is establishing a convention for spatial order.  As I am writing thi= s text, I am writing from left to right, top to bottom.  That simple c= onvention for ASCII characters allows us all to read this.  It is not = the only convention and perhaps not even the best but it is one we share.

 

It is insufficient to specify order without th= e receiver knowing the sense of the order for reproduction.  

 

I suggest that left is the participant’s left a= s that person views the reproduction.  I further suggest that spatial = order be defined as left to right.  (you can add top to bottom if you = wish).

 

Thus receiving streams labeled [0, 1, = 2, ..] would be interpreted as starting on the left and tiled in raster fas= hion to the right.

&n= bsp;

Mark

=

 

From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesda= y, May 25, 2011 10:48 AM
To: Stephan Wenger
Cc: clue@ie= tf.org
Subject: Re: [clue] Definitions-00 posted

 

Yes, I agree that "stage left" is from = the viewpoint of the actor (which I am interpreting as the sending human pa= rticipant).  So if you are seated in the center, and I am on your left= , then I am "stage left" (and in a 3-stream telepresence system, = I would be carried in the "left" stream, and displayed on Monitor= 3 in Roni's diagram).

Whether it is actually necessary to describe = Monitor 3 as left or right is unclear to me; I am thinking we are mostly de= scribing spatial relationships of streams, not display devices.  Howev= er, from a receiving perspective, the monitors represent the far-end stage.=   So it would be sensible to label the monitor as "audience right= ". 

What's tricky here is that there are two "stages= ", one at each end of the call.  So we don't want to call Monitor= 3 the "stage left" monitor, since it is on the right of the loca= l "stage". 

Maybe consistently using "stage lef= t" for streams and sending, and "audience right" or "ho= use right" for receiving and rendering of the"stage left" st= ream is the best answer.  It does make the required reversal explicit.=

Stephen Botzko

On W= ed, May 25, 2011 at 12:17 PM, Stephan Wenger <stewe@stewe.org> wrote:

I don't recall discussion about "house left" eithe= r.

Steve, take a = look at the wikipedia page mentioned.  It may be that wikipedia and yo= u disagree about what "stage left" actually is.  From what I= understood there (which is consistent with what I thought during the call)= : stage directions are from the viewpoint of an actor facing the crowd, not= from the crowd's viewpoint.

Stephan

 

&= nbsp;

From: Stephen Botzko <stephen.botzko@gmail.com>
Date: Wed, 25= May 2011 12:02:10 -0400
To: Roni Even <Even.roni@huawei.com>
Cc: = Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>


Subject: Re: [clue] Definitions-00 posted

&= nbsp;

This depends on where you think the stage is!   Though = I agree that monitor 3 is house right, and that the stream it is displaying= is stage left.

BTW, I don't recall a "house left"  d= iscussion in the conference call, but perhaps I missed it.

Steve B.<= br>

On Wed, May 25,= 2011 at 11:44 AM, Roni Even <Even.roni@huawei.com> wrote:

Steve,=

 =

Acco= rding to Wikipedia

= <= td colspan=3D2 style=3D'padding:0in 0in 0in 0in;height:5.4pt'>

 

 

 


Monitor    = 1            &n= bsp;            = ;            &n= bsp;   Monitor 2        &= nbsp;           &nbs= p;            &= nbsp;          Monitor 3 =             &nb= sp;            =    

 

 <= /span>

 


=

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        

          =             &nb= sp;            =             &nb= sp;            =     Participant

 

Here monitor 1 is house left and stage rig= ht. Monitor 3 is house right and stage left.  Assuming that the local = participant is the house.

I do not care= which one we pick, I just thought that during the conference call we menti= oned using house left and right

 

Roni=

 

 

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stephan Wenger
Cc: Roni Even; clue@ietf.= org
Subject: Re: [clue] Definitions-00 posted

 

If you want to describe the spatial relationships from a perspective o= f a sender (more precisely a human in the sending room), then "stage l= eft" is more natural.

"House Left"  is more natu= ral if you want to describe spatial relationships from the perspective of h= umans in the receiving room. 

Though since we are unlikely to = have a lot of normative text for rendering in receivers, "Stage Left&q= uot; seems more useful to me.  However, I have no objection to definin= g both terms.

Steve B,

On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger &l= t;stewe@stewe.org&= gt; wrote:

Would like to hear Steve Botzko's opinion here, as I bel= ieve to recall he suggested the use of "stage left" first.=

I personally don't care whether we ta= ke "stage" or "house" viewpoint, as long as we pick one= of the two.

=

(Has anyone a more= stable reference for stage directions?  I'm not sure that the RFC edi= tor will let us get away with unstable wikipedia references…)<= span style=3D'color:black'>

Stephan

 

 

= From: Roni Even <Even.roni@huawei.com>
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wenger <stewe@stewe.org>, <= clue@ietf.org>Subject: RE: [clue] Definitions-00 posted

 =

Hi Stephan,

About the left ri=
ght directions you suggested =

Left: to be =
interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(st=
age)
= 
When looking at the refer=
ence it looks to me that we were proposing what is called "house left&=
quot; and not "stage left"
 =
;
Roni<=
o:p>

 

 <= /span>

 

From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger<= br>Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: = [clue] Definitions-00 posted<= /span>

 <= /span>

Hi all,<= /span>

<= span style=3D'font-size:10.5pt;color:black'>I just posted the –00 dra= ft, reflecting (hopefully) the outcome of the discussions of the last six d= ays as well as (hopefully) addressing most typos.  Comments welcome.

<= span style=3D'font-size:10.5pt;color:black'>Stephan

 

=


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

 

 

=

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_-- --_005_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=233; creation-date="Wed, 25 May 2011 18:19:43 GMT"; modification-date="Wed, 25 May 2011 18:19:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --_005_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=835; creation-date="Wed, 25 May 2011 18:19:44 GMT"; modification-date="Wed, 25 May 2011 18:19:44 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --_005_4168915E16BA9E47972F4A4B4EE3228276B77BC831GVW1096EXBame_-- From stephen.botzko@gmail.com Wed May 25 11:23:07 2011 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 A9D65130078 for ; Wed, 25 May 2011 11:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 mHBXXIllJzu3 for ; Wed, 25 May 2011 11:23:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2021013003D for ; Wed, 25 May 2011 11:23:06 -0700 (PDT) Received: by vxg33 with SMTP id 33so7276402vxg.31 for ; Wed, 25 May 2011 11:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J6tQEhywjVpsx7UVbOOiGKU1a+welP7xNRiIuQWLBYo=; b=F/29FFUNEvyaWW4vCOhYs+zVy07ypz9+mltKZ4t+c1F096SwJLvA1whIPw9GuTEFcT 7nWqMDhUoGCGJUpc7nN2wMTlSu5Ip2gAlwpQEErbClkjHb3xvjl4M1LMQG3wpWu2tztS aC7Te4KyJt7+nEfsa1JRFkNkzoXhIVS6q2VQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uXxac4wq67BS0NzIJHCsVS7b4Af9nUpQFFrThzReb4TpETTvm1lePNKEw3cBlvzhq9 yjkPOGfkCgUz5HcRMBS8Cs/3B7xbMTmch6NiTuaqW3mOucrXhV/U+41H3YTZaBt99qx/ zKrPAKFd0xeCnX4wdRSq8SG3NaEFpzo7lLlh0= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr3195172vdb.200.1306347785319; Wed, 25 May 2011 11:23:05 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 11:23:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2011 14:23:05 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/related; boundary=20cf307f34a6b2738904a41dcbf9 Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted 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, 25 May 2011 18:23:07 -0000 --20cf307f34a6b2738904a41dcbf9 Content-Type: multipart/alternative; boundary=20cf307f34a6b2736d04a41dcbf8 --20cf307f34a6b2736d04a41dcbf8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "sender left" and "sender right", "viewer left" and "viewer right" would also be equivalent, and avoid theatrics... Regards Stephen Botzko On Wed, May 25, 2011 at 1:48 PM, Stephen Botzko w= rote: > Yes, I agree that "stage left" is from the viewpoint of the actor (which = I > am interpreting as the sending human participant). So if you are seated = in > the center, and I am on your left, then I am "stage left" (and in a 3-str= eam > telepresence system, I would be carried in the "left" stream, and display= ed > on Monitor 3 in Roni's diagram). > > Whether it is actually necessary to describe Monitor 3 as left or right i= s > unclear to me; I am thinking we are mostly describing spatial relationshi= ps > of streams, not display devices. However, from a receiving perspective, = the > monitors represent the far-end stage. So it would be sensible to label t= he > monitor as "audience right". > > What's tricky here is that there are two "stages", one at each end of the > call. So we don't want to call Monitor 3 the "stage left" monitor, since= it > is on the right of the local "stage". > > Maybe consistently using "stage left" for streams and sending, and > "audience right" or "house right" for receiving and rendering of the"stag= e > left" stream is the best answer. It does make the required reversal > explicit. > > Stephen Botzko > > > > On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger wrote: > >> I don't recall discussion about "house left" either. >> Steve, take a look at the wikipedia page mentioned. It may be that >> wikipedia and you disagree about what "stage left" actually is. From wh= at I >> understood there (which is consistent with what I thought during the cal= l): >> stage directions are from the viewpoint of an actor facing the crowd, no= t >> from the crowd's viewpoint. >> Stephan >> >> >> From: Stephen Botzko >> Date: Wed, 25 May 2011 12:02:10 -0400 >> To: Roni Even >> Cc: Stephan Wenger , >> >> Subject: Re: [clue] Definitions-00 posted >> >> This depends on where you think the stage is! Though I agree that >> monitor 3 is house right, and that the stream it is displaying is stage >> left. >> >> BTW, I don't recall a "house left" discussion in the conference call, b= ut >> perhaps I missed it. >> >> Steve B. >> >> >> On Wed, May 25, 2011 at 11:44 AM, Roni Even wrote= : >> >>> Steve, >>> >>> >>> >>> According to Wikipedia >>> >>> >>> >>> >>> >>> >>> >>> Monitor 1 Monitor >>> 2 Monitor >>> 3 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Participant >>> >>> >>> >>> Here monitor 1 is house left and stage right. Monitor 3 is house right >>> and stage left. Assuming that the local participant is the house. >>> >>> I do not care which one we pick, I just thought that during the >>> conference call we mentioned using house left and right >>> >>> >>> >>> Roni >>> >>> >>> >>> >>> >>> *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Wednesday, May 25, 2011 5:42 PM >>> *To:* Stephan Wenger >>> *Cc:* Roni Even; clue@ietf.org >>> *Subject:* Re: [clue] Definitions-00 posted >>> >>> >>> >>> If you want to describe the spatial relationships from a perspective of= a >>> sender (more precisely a human in the sending room), then "stage left" = is >>> more natural. >>> >>> "House Left" is more natural if you want to describe spatial >>> relationships from the perspective of humans in the receiving room. >>> >>> Though since we are unlikely to have a lot of normative text for >>> rendering in receivers, "Stage Left" seems more useful to me. However,= I >>> have no objection to defining both terms. >>> >>> Steve B, >>> >>> >>> On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger >>> wrote: >>> >>> Would like to hear Steve Botzko's opinion here, as I believe to recall = he >>> suggested the use of "stage left" first. >>> >>> I personally don't care whether we take "stage" or "house" viewpoint, a= s >>> long as we pick one of the two. >>> >>> (Has anyone a more stable reference for stage directions? I'm not sure >>> that the RFC editor will let us get away with unstable wikipedia >>> references=85) >>> >>> Stephan >>> >>> >>> >>> >>> >>> *From: *Roni Even >>> *Date: *Wed, 25 May 2011 08:58:34 +0300 >>> *To: *Stephan Wenger , >>> *Subject: *RE: [clue] Definitions-00 posted >>> >>> >>> >>> Hi Stephan, >>> >>> About the left right directions you suggested >>> >>> Left: to be interpreted as a stage direction, see also[StageDirection(W= ikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) >>> >>> When looking at the reference it looks to me that we were proposing wha= t is called "house left" and not "stage left" >>> >>> >>> >>> Roni >>> >>> >>> >>> >>> >>> >>> >>> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] >>> *On Behalf Of *Stephan Wenger >>> *Sent:* Thursday, May 19, 2011 11:08 AM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Definitions-00 posted >>> >>> >>> >>> Hi all, >>> >>> I just posted the =9600 draft, reflecting (hopefully) the outcome of th= e >>> discussions of the last six days as well as (hopefully) addressing most >>> typos. Comments welcome. >>> >>> Stephan >>> >>> >>> >>> http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >> >> > --20cf307f34a6b2736d04a41dcbf8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "sender left" and "sender right", "viewer left&quo= t; and "viewer right" would also be equivalent, and avoid theatri= cs...

Regards
Stephen Botzko

On Wed, May 25, 2011 at 1:48 PM, Stephen Botzko <stephen.botzko@gma= il.com> wrote:
Yes, I agree that "stage left" is from the viewpoint of the actor= (which I am interpreting as the sending human participant).=A0 So if you a= re seated in the center, and I am on your left, then I am "stage left&= quot; (and in a 3-stream telepresence system, I would be carried in the &qu= ot;left" stream, and displayed on Monitor 3 in Roni's diagram).
Whether it is actually necessary to describe Monitor 3 as left or right= is unclear to me; I am thinking we are mostly describing spatial relations= hips of streams, not display devices.=A0 However, from a receiving perspect= ive, the monitors represent the far-end stage.=A0 So it would be sensible t= o label the monitor as "audience right".=A0

What's tricky here is that there are two "stages", one at= each end of the call.=A0 So we don't want to call Monitor 3 the "= stage left" monitor, since it is on the right of the local "stage= ".=A0

Maybe consistently using "stage left" for streams and sending= , and "audience right" or "house right" for receiving a= nd rendering of the"stage left" stream is the best answer.=A0 It = does make the required reversal explicit.

Stephen Botzko



On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger <stewe@stewe.org<= /a>> wrote:
I don't recall discussion about "h= ouse left" either.
Steve, take a look at the wikipedia page = mentioned. =A0It may be that wikipedia and you disagree about what "st= age left" actually is. =A0From what I understood there (which is consi= stent with what I thought during the call): stage directions are from the v= iewpoint of an actor facing the crowd, not from the crowd's viewpoint.<= /div>
Stephan


From: Stephen Botzko <stephen.botzko@gmail= .com>
Date: Wed, 25 May = 2011 12:02:10 -0400
To: Roni Even <Even.roni@huawei.com>
<= span style=3D"font-weight:bold">Cc: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>

Subject: Re: [= clue] Definitions-00 posted
=
This depends on where you think the stage is!=A0=A0 Though I agre= e that monitor 3 is house right, and that the stream it is displaying is st= age left.

BTW, I don't recall a "house left"=A0 discussion in the c= onference call, but perhaps I missed it.

Steve B.


On Wed, May 25, 2011 at 11:44 AM, Roni Even <Even= .roni@huawei.com> wrote:

Steve,

=A0

According to Wikipedia

=
=
=A0

= =A0

=A0


Monitor =A0=A0=A01=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 Monitor 2=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 Monitor 3=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

<= /tr>
=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 Participant

=A0

Here monitor 1 is house left and stage right. Monitor 3 is house right = and stage left. =A0Assuming that the local participant is the house.

I do = not care which one we pick, I just thought that during the conference call = we mentioned using house left and right

=A0

Roni<= /span>

=A0

=A0

From: Stephen Botzko [mail= to:stephen.bo= tzko@gmail.com]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stephan WengerCc: Roni Even; = clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

=A0

If you want to describe the spati= al relationships from a perspective of a sender (more precisely a human in = the sending room), then "stage left" is more natural.

"House Left"=A0 is more natural if you want to describe spati= al relationships from the perspective of humans in the receiving room.=A0 <= br>
Though since we are unlikely to have a lot of normative text for ren= dering in receivers, "Stage Left" seems more useful to me.=A0 How= ever, I have no objection to defining both terms.

Steve B,


On Wed, May 25, 201= 1 at 10:23 AM, Stephan Wenger <stewe@stewe.org> wrote:

Would like to hear Steve Botzk= o's opinion here, as I believe to recall he suggested the use of "= stage left" first.

I personally don't care whether w= e take "stage" or "house" viewpoint, as long as we pick= one of the two.

(Has anyone a more stable reference for stage directions? =A0I'm no= t sure that the RFC editor will let us get away with unstable wikipedia ref= erences=85)

Stephan

=A0

<= span style=3D"font-size:10.5pt;color:black">=A0

From: Ro= ni Even <Even.= roni@huawei.com>
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wenger &= lt;stewe@stewe.org= >, <clue@ietf.org<= /a>>
Subject: RE: [clue] Definitions-00 posted

=

= =A0

Hi Stephan,<= /span>

About the left right dire=
ctions you suggested 
<=
span style=3D"font-size:11.0pt;color:black">Left: to be interpreted as a st=
age direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When looking at the refer=
ence it looks to me that we were proposing what is called "house left&=
quot; and not "stage left"
=A0
Roni

=A0

=A0

=A0

From: clue-bounces@= ietf.org [ma= ilto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: [cl= ue] Definitions-00 posted

=A0

Hi all= ,

I just posted the =9600 = draft, reflecting (hopefully) the outcome of the discussions of the last si= x days as well as (hopefully) addressing most typos. =A0Comments welcome.

Stephan

=A0


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

=A0


<= /span>


--20cf307f34a6b2736d04a41dcbf8-- --20cf307f34a6b2738904a41dcbf9 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 3610b922eabdd6d5_0.1 iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --20cf307f34a6b2738904a41dcbf9 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 3610b922eabdd6d5_0.2 iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --20cf307f34a6b2738904a41dcbf9-- From haibin.song@huawei.com Wed May 25 18:51:02 2011 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 B36FAE06AC for ; Wed, 25 May 2011 18:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, 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 Vv5eg9YwM4dX for ; Wed, 25 May 2011 18:51:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 966CBE0695 for ; Wed, 25 May 2011 18:51:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00IU053GT9@szxga03-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 09:50:04 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00G9A53G2E@szxga03-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 09:50:04 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 09:50:00 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 26 May 2011 09:50:03 +0800 Date: Thu, 26 May 2011 01:50:03 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.119] To: "Elwell, John" , Paul Kyzivat , "Mike Hammer (hmmr)" , Paul Kyzivat Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [clue] legacy support in requirements Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGD/7v0yMP/dN4PA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 26 May 2011 01:51:02 -0000 Hi John and Paul, > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 25, 2011 10:00 PM > To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > > > > -----Original Message----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: 25 May 2011 07:44 > > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > On Behalf Of > > > Elwell, John > > > Sent: Friday, May 20, 2011 4:27 PM > > > To: Paul Kyzivat; Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat > > > > Sent: 19 May 2011 15:08 > > > > To: Mike Hammer (hmmr) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > Mike, > > > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > > Paul, > > > > > > > > > > What I am trying to say is that Telepresence is all about > > > > the end-user > > > > > experience, and that with multiple microphones, > > speakers, cameras, > > > > > displays, and data feeds there is more complexity and > > > > chance to screw > > > > > that up. And a key point is that spatial relationships are > > > > significant > > > > > to the user experience. As a result, more rigor is needed > > > > to design the > > > > > system to ensure that backward compatible means that legacy > > > > systems are > > > > > handled as such. > > > > > > > > > > I am not sure if the protocol design is far enough > > along to analyze > > > > > whether correct protocol operation still results in bad > > > > user experience, > > > > > but would suggest that if certain key concepts like spatial > > > > awareness > > > > > are not understood, then that leg needs to devolve to a > > known legacy > > > > > state and handled by the MCU as such. That might mean > > tagging some > > > > > parameters as mandatory to understand to force the > > > > determination and not > > > > > leave it ambiguous. > > > > > > > > > > I believe some current systems treat legacy systems > > differently and > > > > > don't expect them to behave like ones that understands > > the dynamic > > > > > speaker controls. > > > > > > > > I suspect we are talking past each other and are not really > > > > in disagreement. > > > > > > > > I expect that the clue specs, whatever they turn out to be, > > > > will require > > > > support for a bunch of existing sip/sdp mechanisms that > > are generally > > > > optional and not widely implemented in lower end devices. > > > > > > > > If so, then if we have two clueful systems attempting to > > connect, we > > > > will be in the realm of negotiating using syntax that both > > > > understand. > > > > In that case, this discussion of how to behave when > > something *isn't* > > > > understood is moot. Rather that situation will arise when > > we have a > > > > clueful system attempting to connect to a clueless system, or visa > > > > versa. That is where my focus is in this discussion. > > > [JRE] And furthermore, we might have a conference > > comprising a number of > > > CLUEful endpoints and a number of CLUEless endpoints. We > > would ideally like > > > to be in a position where the CLUEful endpoint users can > > share a telepresence > > > experience, and yet the CLUEless endpoint users can still > > participate > > > meaningfully in the conference. > > > > > > John > > > > > > > I think this is out of the scope of CLUE WG. > [JRE] I don't know why you say that. In fact it is covered in the use cases draft, > section 4.5. > > John IMHO, the interworking with the CLUEless endpoints may mostly rely on the existing standard for video conference, which will not be re-invented in this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand the existing standard in order to connect. What kind of signaling or parameters MUST be communicated between the CLUEful endpoints or between CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless endpoints? Can they also be done by the internal implementation in MCU or the endpoint? By the way, I am not an expert on telepresence, maybe the question seems stupid. Thanks, -Haibin From haibin.song@huawei.com Wed May 25 19:11:37 2011 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 34048130025 for ; Wed, 25 May 2011 19:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-2.311, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6] 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 iOJGIkPs1dZJ for ; Wed, 25 May 2011 19:11:33 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D9536130035 for ; Wed, 25 May 2011 19:11:31 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS001G863446@szxga05-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 10:11:29 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS006I5634HF@szxga05-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 10:11:28 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 10:11:22 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 26 May 2011 10:11:27 +0800 Date: Thu, 26 May 2011 02:11:27 +0000 From: Songhaibin In-reply-to: <4168915E16BA9E47972F4A4B4EE3228276B77BC831@GVW1096EXB.americas.hpqcorp.net> X-Originating-IP: [10.138.41.119] To: "Gorzynski, Mark E (The Right One)" , "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_vCZexh0qQA8MFC1hCHDvYA)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [clue] Definitions-00 posted Thread-index: AQHMFkdcf8pxJxvtvUWY2iOao8Hw2JScjuUAgACNAYCAAAUtAIAAnbMG//99EwCAABlegIAACLyAgAEI3/A= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <4168915E16BA9E47972F4A4B4EE3228276B77BC831@GVW1096EXB.americas.hpqcorp.net> Subject: Re: [clue] Definitions-00 posted 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, 26 May 2011 02:11:37 -0000 --Boundary_(ID_vCZexh0qQA8MFC1hCHDvYA) Content-type: multipart/alternative; boundary="Boundary_(ID_TkAU9Ayui0WFIHB6d5k8DQ)" --Boundary_(ID_TkAU9Ayui0WFIHB6d5k8DQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT >It is insufficient to specify order without the receiver knowing the sense of the order for reproduction. >I suggest that left is the participant's left as that person views the reproduction. I further suggest that spatial order be defined as left to right. (you can add top to bottom if you wish). > >Thus receiving streams labeled [0, 1, 2, ..] would be interpreted as starting on the left and tiled in raster fashion to the right. I agree with you. But now we can not use the term "participant" in your sentence(as it means software element as RFC 4353 defines) :) -Haibin From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gorzynski, Mark E (The Right One) Sent: Thursday, May 26, 2011 2:20 AM To: clue@ietf.org Subject: Re: [clue] Definitions-00 posted My concern is establishing a convention for spatial order. As I am writing this text, I am writing from left to right, top to bottom. That simple convention for ASCII characters allows us all to read this. It is not the only convention and perhaps not even the best but it is one we share. It is insufficient to specify order without the receiver knowing the sense of the order for reproduction. I suggest that left is the participant's left as that person views the reproduction. I further suggest that spatial order be defined as left to right. (you can add top to bottom if you wish). Thus receiving streams labeled [0, 1, 2, ..] would be interpreted as starting on the left and tiled in raster fashion to the right. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, May 25, 2011 10:48 AM To: Stephan Wenger Cc: clue@ietf.org Subject: Re: [clue] Definitions-00 posted Yes, I agree that "stage left" is from the viewpoint of the actor (which I am interpreting as the sending human participant). So if you are seated in the center, and I am on your left, then I am "stage left" (and in a 3-stream telepresence system, I would be carried in the "left" stream, and displayed on Monitor 3 in Roni's diagram). Whether it is actually necessary to describe Monitor 3 as left or right is unclear to me; I am thinking we are mostly describing spatial relationships of streams, not display devices. However, from a receiving perspective, the monitors represent the far-end stage. So it would be sensible to label the monitor as "audience right". What's tricky here is that there are two "stages", one at each end of the call. So we don't want to call Monitor 3 the "stage left" monitor, since it is on the right of the local "stage". Maybe consistently using "stage left" for streams and sending, and "audience right" or "house right" for receiving and rendering of the"stage left" stream is the best answer. It does make the required reversal explicit. Stephen Botzko On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger > wrote: I don't recall discussion about "house left" either. Steve, take a look at the wikipedia page mentioned. It may be that wikipedia and you disagree about what "stage left" actually is. From what I understood there (which is consistent with what I thought during the call): stage directions are from the viewpoint of an actor facing the crowd, not from the crowd's viewpoint. Stephan From: Stephen Botzko > Date: Wed, 25 May 2011 12:02:10 -0400 To: Roni Even > Cc: Stephan Wenger >, > Subject: Re: [clue] Definitions-00 posted This depends on where you think the stage is! Though I agree that monitor 3 is house right, and that the stream it is displaying is stage left. BTW, I don't recall a "house left" discussion in the conference call, but perhaps I missed it. Steve B. On Wed, May 25, 2011 at 11:44 AM, Roni Even > wrote: Steve, According to Wikipedia [cid:image001.png@01CC1B8D.45FD5230] [cid:image001.png@01CC1B8D.45FD5230] [cid:image001.png@01CC1B8D.45FD5230] Monitor 1 Monitor 2 Monitor 3 [cid:image002.png@01CC1B8D.45FD5230] Participant Here monitor 1 is house left and stage right. Monitor 3 is house right and stage left. Assuming that the local participant is the house. I do not care which one we pick, I just thought that during the conference call we mentioned using house left and right Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, May 25, 2011 5:42 PM To: Stephan Wenger Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Definitions-00 posted If you want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural. "House Left" is more natural if you want to describe spatial relationships from the perspective of humans in the receiving room. Though since we are unlikely to have a lot of normative text for rendering in receivers, "Stage Left" seems more useful to me. However, I have no objection to defining both terms. Steve B, On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger > wrote: Would like to hear Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first. I personally don't care whether we take "stage" or "house" viewpoint, as long as we pick one of the two. (Has anyone a more stable reference for stage directions? I'm not sure that the RFC editor will let us get away with unstable wikipedia references...) Stephan From: Roni Even > Date: Wed, 25 May 2011 08:58:34 +0300 To: Stephan Wenger >, > Subject: RE: [clue] Definitions-00 posted Hi Stephan, About the left right directions you suggested Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left" Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, May 19, 2011 11:08 AM To: clue@ietf.org Subject: [clue] Definitions-00 posted Hi all, I just posted the -00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos. Comments welcome. Stephan http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_TkAU9Ayui0WFIHB6d5k8DQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

>It is insufficient to specify order without the receiver knowing the sense of the order for reproduction.  

 

>I suggest that left is the participant’s left as that person views the reproduction.  I further suggest that spatial order be defined as left to right.  (you can add top to bottom if you wish).

> 

>Thus receiving streams labeled [0, 1, 2, ..] would be interpreted as starting on the left and tiled in raster fashion to the right.

 

 

I agree with you.

 

But now we can not use the term “participant” in your sentence(as it means software element as RFC 4353 defines)  J

 

 

-Haibin

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gorzynski, Mark E (The Right One)
Sent: Thursday, May 26, 2011 2:20 AM
To: clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

 

My concern is establishing a convention for spatial order.  As I am writing this text, I am writing from left to right, top to bottom.  That simple convention for ASCII characters allows us all to read this.  It is not the only convention and perhaps not even the best but it is one we share.

 

It is insufficient to specify order without the receiver knowing the sense of the order for reproduction.  

 

I suggest that left is the participant’s left as that person views the reproduction.  I further suggest that spatial order be defined as left to right.  (you can add top to bottom if you wish).

 

Thus receiving streams labeled [0, 1, 2, ..] would be interpreted as starting on the left and tiled in raster fashion to the right.

 

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, May 25, 2011 10:48 AM
To: Stephan Wenger
Cc: clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

 

Yes, I agree that "stage left" is from the viewpoint of the actor (which I am interpreting as the sending human participant).  So if you are seated in the center, and I am on your left, then I am "stage left" (and in a 3-stream telepresence system, I would be carried in the "left" stream, and displayed on Monitor 3 in Roni's diagram).

Whether it is actually necessary to describe Monitor 3 as left or right is unclear to me; I am thinking we are mostly describing spatial relationships of streams, not display devices.  However, from a receiving perspective, the monitors represent the far-end stage.  So it would be sensible to label the monitor as "audience right". 

What's tricky here is that there are two "stages", one at each end of the call.  So we don't want to call Monitor 3 the "stage left" monitor, since it is on the right of the local "stage". 

Maybe consistently using "stage left" for streams and sending, and "audience right" or "house right" for receiving and rendering of the"stage left" stream is the best answer.  It does make the required reversal explicit.

Stephen Botzko

On Wed, May 25, 2011 at 12:17 PM, Stephan Wenger <stewe@stewe.org> wrote:

I don't recall discussion about "house left" either.

Steve, take a look at the wikipedia page mentioned.  It may be that wikipedia and you disagree about what "stage left" actually is.  From what I understood there (which is consistent with what I thought during the call): stage directions are from the viewpoint of an actor facing the crowd, not from the crowd's viewpoint.

Stephan

 

 

From: Stephen Botzko <stephen.botzko@gmail.com>
Date: Wed, 25 May 2011 12:02:10 -0400
To: Roni Even <Even.roni@huawei.com>
Cc: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>


Subject: Re: [clue] Definitions-00 posted

 

This depends on where you think the stage is!   Though I agree that monitor 3 is house right, and that the stream it is displaying is stage left.

BTW, I don't recall a "house left"  discussion in the conference call, but perhaps I missed it.

Steve B.

On Wed, May 25, 2011 at 11:44 AM, Roni Even <Even.roni@huawei.com> wrote:

Steve,

 

According to Wikipedia

 

 

 


Monitor    1                                         Monitor 2                                            Monitor 3                             

 

 

 


                                               

                                                                Participant

 

Here monitor 1 is house left and stage right. Monitor 3 is house right and stage left.  Assuming that the local participant is the house.

I do not care which one we pick, I just thought that during the conference call we mentioned using house left and right

 

Roni

 

 

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, May 25, 2011 5:42 PM
To: Stephan Wenger
Cc: Roni Even; clue@ietf.org
Subject: Re: [clue] Definitions-00 posted

 

If you want to describe the spatial relationships from a perspective of a sender (more precisely a human in the sending room), then "stage left" is more natural.

"House Left"  is more natural if you want to describe spatial relationships from the perspective of humans in the receiving room. 

Though since we are unlikely to have a lot of normative text for rendering in receivers, "Stage Left" seems more useful to me.  However, I have no objection to defining both terms.

Steve B,

On Wed, May 25, 2011 at 10:23 AM, Stephan Wenger <stewe@stewe.org> wrote:

Would like to hear Steve Botzko's opinion here, as I believe to recall he suggested the use of "stage left" first.

I personally don't care whether we take "stage" or "house" viewpoint, as long as we pick one of the two.

(Has anyone a more stable reference for stage directions?  I'm not sure that the RFC editor will let us get away with unstable wikipedia references…)

Stephan

 

 

From: Roni Even <Even.roni@huawei.com>
Date: Wed, 25 May 2011 08:58:34 +0300
To: Stephan Wenger <stewe@stewe.org>, <clue@ietf.org>
Subject: RE: [clue] Definitions-00 posted

 

Hi Stephan,

About the left right directions you suggested 
Left: to be interpreted as a stage direction, see also[StageDirection(Wikipadia)]. http://en.wikipedia.org/wiki/Blocking_(stage) 
When looking at the reference it looks to me that we were proposing what is called "house left" and not "stage left"
 
Roni

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Thursday, May 19, 2011 11:08 AM
To: clue@ietf.org
Subject: [clue] Definitions-00 posted

 

Hi all,

I just posted the –00 draft, reflecting (hopefully) the outcome of the discussions of the last six days as well as (hopefully) addressing most typos.  Comments welcome.

Stephan

 


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

 

 

 

--Boundary_(ID_TkAU9Ayui0WFIHB6d5k8DQ)-- --Boundary_(ID_vCZexh0qQA8MFC1hCHDvYA) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.png; size=233; creation-date="Thu, 26 May 2011 02:11:27 GMT"; modification-date="Thu, 26 May 2011 02:11:27 GMT" Content-description: image001.png iVBORw0KGgoAAAANSUhEUgAAAFQAAAAnCAYAAACR3W+uAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAABpSURBVGje 7dvBCcAgEETRKWlb3ApTiiUkQUvQi/A+jLDXdzfdHTu3+VTVm8T29yzV/9B+ExUoUKBABRQoUAEF ClRAgQIFChQoUKACChSogAIFKqBAgQIVUKBABRQoUAEFejvo8OHgyMYHmX4K8pZyQ1kAAAAASUVO RK5CYII= --Boundary_(ID_vCZexh0qQA8MFC1hCHDvYA) Content-id: Content-type: image/png; name=image002.png Content-transfer-encoding: base64 Content-disposition: inline; filename=image002.png; size=835; creation-date="Thu, 26 May 2011 02:11:27 GMT"; modification-date="Thu, 26 May 2011 02:11:27 GMT" Content-description: image002.png iVBORw0KGgoAAAANSUhEUgAAACQAAAAVCAYAAAAuJkyQAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALDSURBVEjH xVY/aFpxEHYI+IL4X0MQI0IUBB0KDjpkcAk4hQwKTkEyiTiIFHEJKhKcROgiFEzo5FBoJjPWrY6O bpFOFkoxElPTOlzve5hiH8/nM3/qwfEej7v7fe9+d9+dplwua56iLG9YI0s0/OS4Kg83sSZsNlvb arX2+Z329/dvg8HgSE79fv8INmaz+QY+/J5k3X02IPwtB/y8vb39cHR0NG61WtTtdkmt9Ho9gk8i kbgzGo33HKvHMY/XBoSUwxl/e3V1RS8lnU6HDg8Pb/V6/Xc+I7oSEIvAV/IOKYfza8lgMKCDg4PR zs7OJ5SDLCCAcblcXyqVypT+kzSbzd9Op7O/COofMO12+5dSgMvLSzo5OaFqtUrTqTLuer0u2uK5 qs4WQYmABEF4m06nJ0qOFxcXSDOVSiWKxWIUj8eX2p6dnVE0GhVt8czn84qgarXazGKxvJ8nRyNw B/wYDoeKTv1+n/jOKRQKkd1uR7qX2qITH23xvL6+VoyNbHPtjkENYkehiNXcORxR7KvAQ0ajkWiL pxoBrYDrACh1enp6TxuWYrFIjKUEQFG04KYBZTKZB8aSFceCwWCYrOqa1xaQsDgHUdmocFT6psBg GmBELfLQ7t7e3lcwqFQwiwqFwlozTK5DwUeNRkO2+D0ezzfG4JMytdvr9Q6kB6OjQIThcJhMJhMG pUiQ6CCo9Krhj+/4kVQqRW63m3w+H2WzWRGYFGggEBhilVk2y9xYL3K53GRZK+OgZDJJkUhEVCZV dMdfBXB8B3BkRC7rj2PD4XDcLIJZOu05EyWsC+fn5zO1PKKWxwCSifVObrAq7kOoK+6+ular/YmV AYHUEKJU4IMrBvFxNqf8sx9wE8/dGI8RSKfTjbe2tmZoUfAGyExOeXaJNljs4MNd/HHOwsKLrLDS nWm+N2fnzCqnhbmNad34fwAr3hjwEHYjGwAAAABJRU5ErkJggg== --Boundary_(ID_vCZexh0qQA8MFC1hCHDvYA)-- From partr@cisco.com Wed May 25 19:17:49 2011 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 08829E06A3 for ; Wed, 25 May 2011 19:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.396 X-Spam-Level: X-Spam-Status: No, score=-10.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 aWBN77aPfl8T for ; Wed, 25 May 2011 19:17:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 98781E06F4 for ; Wed, 25 May 2011 19:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5757; q=dns/txt; s=iport; t=1306376267; x=1307585867; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tunOp0xR63TXEtCPyDR1gnDkzP53ddScHnx8CelWIPA=; b=O1s182AFlwOQvzQ9hQM0ePVvaw2dWgmQiq1u2tJJMewUZya6AgnYGN4P cv6bdmmwNUQB1v9QI/y8GbFLnkw88L/WdiPaaoq7mbvataULKcnJxomhX Kc38NZ9AKbZTWewolvR6KqatF7DXGvqWW7na1xGgWyvrh9VsKFEAgqaEH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBALq33U1Io8UR/2dsb2JhbACXdY5FeKhinViGHASGWo4cilI X-IronPort-AV: E=Sophos;i="4.65,270,1304294400"; d="scan'208";a="90762761" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 26 May 2011 02:17:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4Q2HiaV003756; Thu, 26 May 2011 02:17:44 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 07:47:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2011 07:47:40 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGD/7v0yMP/dN4PA/7pmLoA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><4DD3FD0E.8020503@cisco.com><4DD4584E.30405@cisco.com><4DD5244C.8090801@cisco.com> From: "Parthasarathi R (partr)" To: "Songhaibin" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "Mike Hammer (hmmr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 26 May 2011 02:17:44.0200 (UTC) FILETIME=[18F35880:01CC1B4B] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 26 May 2011 02:17:49 -0000 It is good to support legacy video (clueless) devices with clueful devices in the standard manner. There MUST be requirement to clarify how to interop with clueless devices. But it should not be mandated for all clueful devices to support clueless devices. It is possible to have two solution 1) clueful device solution 2) Interop solution for clueful and clueless solution. IMO, it is better for few devices (endpoint) compliance to solution 1 only, few other devices (middle-boxes) support both of the solutions by which end-to-end interop is feasible.=20 Thanks Partha -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Songhaibin Sent: Thursday, May 26, 2011 7:20 AM To: Elwell, John; Paul Kyzivat (pkyzivat); Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements Hi John and Paul, > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 25, 2011 10:00 PM > To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 >=20 >=20 > > -----Original Message----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: 25 May 2011 07:44 > > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > On Behalf Of > > > Elwell, John > > > Sent: Friday, May 20, 2011 4:27 PM > > > To: Paul Kyzivat; Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > > > > Behalf Of Paul Kyzivat > > > > Sent: 19 May 2011 15:08 > > > > To: Mike Hammer (hmmr) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > Mike, > > > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > > Paul, > > > > > > > > > > What I am trying to say is that Telepresence is all about > > > > the end-user > > > > > experience, and that with multiple microphones, > > speakers, cameras, > > > > > displays, and data feeds there is more complexity and > > > > chance to screw > > > > > that up. And a key point is that spatial relationships are > > > > significant > > > > > to the user experience. As a result, more rigor is needed > > > > to design the > > > > > system to ensure that backward compatible means that legacy > > > > systems are > > > > > handled as such. > > > > > > > > > > I am not sure if the protocol design is far enough > > along to analyze > > > > > whether correct protocol operation still results in bad > > > > user experience, > > > > > but would suggest that if certain key concepts like spatial > > > > awareness > > > > > are not understood, then that leg needs to devolve to a > > known legacy > > > > > state and handled by the MCU as such. That might mean > > tagging some > > > > > parameters as mandatory to understand to force the > > > > determination and not > > > > > leave it ambiguous. > > > > > > > > > > I believe some current systems treat legacy systems > > differently and > > > > > don't expect them to behave like ones that understands > > the dynamic > > > > > speaker controls. > > > > > > > > I suspect we are talking past each other and are not really in=20 > > > > disagreement. > > > > > > > > I expect that the clue specs, whatever they turn out to be, will > > > > require support for a bunch of existing sip/sdp mechanisms that > > are generally > > > > optional and not widely implemented in lower end devices. > > > > > > > > If so, then if we have two clueful systems attempting to > > connect, we > > > > will be in the realm of negotiating using syntax that both=20 > > > > understand. > > > > In that case, this discussion of how to behave when > > something *isn't* > > > > understood is moot. Rather that situation will arise when > > we have a > > > > clueful system attempting to connect to a clueless system, or=20 > > > > visa versa. That is where my focus is in this discussion. > > > [JRE] And furthermore, we might have a conference > > comprising a number of > > > CLUEful endpoints and a number of CLUEless endpoints. We > > would ideally like > > > to be in a position where the CLUEful endpoint users can > > share a telepresence > > > experience, and yet the CLUEless endpoint users can still > > participate > > > meaningfully in the conference. > > > > > > John > > > > > > > I think this is out of the scope of CLUE WG. > [JRE] I don't know why you say that. In fact it is covered in the use=20 > cases draft, section 4.5. >=20 > John IMHO, the interworking with the CLUEless endpoints may mostly rely on the existing standard for video conference, which will not be re-invented in this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand the existing standard in order to connect. What kind of signaling or parameters MUST be communicated between the CLUEful endpoints or between CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless endpoints? Can they also be done by the internal implementation in MCU or the endpoint? By the way, I am not an expert on telepresence, maybe the question seems stupid. Thanks, -Haibin _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Wed May 25 19:22:25 2011 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 26205E070F for ; Wed, 25 May 2011 19:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.281, 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 g43KOIkB0NK3 for ; Wed, 25 May 2011 19:22:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9886E06A3 for ; Wed, 25 May 2011 19:22:23 -0700 (PDT) Received: by vxg33 with SMTP id 33so245220vxg.31 for ; Wed, 25 May 2011 19:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yKwqDkMP7IHdQefG5S2aOUqi5EdYGn7X/e2U/iOsSI4=; b=m3euczW03aJHKIzBrDYhjJHF4BteqgSO7WKOGANzp1p4kpa7Sc0QDcyL7GJh+HI0Bs lAXsV5+wBPsr/tdGktMdwvai1oRul76+BKZyDggSA8nqjul7jtmXcwcId5xvE2CZT+SS fleCYIbS+K2nxw/oCGysYmeX3uVcgZBgTVgwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rgaphR83YMZmVJ/CQPpGTmkXcTlCzWbgDX+TFP9V7GMdheBIeah+W7jMh2rDI6Ve02 PJoB9dcchYdQVoexFYqtw+L5nOL7YWFS1Cq94tj4b/mu4Uka1uLniQWyGY458CAOD3S7 MAJlKXSAkN1x3B3G7wzLuM9vigvOLO3Hg74MU= MIME-Version: 1.0 Received: by 10.52.182.98 with SMTP id ed2mr430102vdc.120.1306376543050; Wed, 25 May 2011 19:22:23 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Wed, 25 May 2011 19:22:22 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Date: Wed, 25 May 2011 22:22:22 -0400 Message-ID: From: Stephen Botzko To: Songhaibin Content-Type: multipart/alternative; boundary=bcaec547c9d3ca9b5904a4247d7b Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 26 May 2011 02:22:25 -0000 --bcaec547c9d3ca9b5904a4247d7b Content-Type: text/plain; charset=ISO-8859-1 Hi Haibin Some ways of structuring the CLUE protocol might be very difficult for existing endpoints to deal with. Other ways might be more "legacy friendly", in the sense that the ability to negotiate a CLUEless call between a CLUEd endpoint and a normal SIP endpoint would be straightforward. I think the intent of the requirement is to make sure the protocol design takes the second path. The challenge is that AFAIK there is are no guarantees in SIP itself that assure any interoperability between the SIP endpoints. For example, there is nothing in the SIP RFCs that mandate common codecs. Since compliant SIP endpoints might not interoperate anyway, you can not guarantee that a CLUE endpoint can interoperate with them either. However, I think the intent is important, so we should try to craft wording that captures it. Regards, Stephen Botzko On Wed, May 25, 2011 at 9:50 PM, Songhaibin wrote: > Hi John and Paul, > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, May 25, 2011 10:00 PM > > To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > -----Original Message----- > > > From: Songhaibin [mailto:haibin.song@huawei.com] > > > Sent: 25 May 2011 07:44 > > > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > > On Behalf Of > > > > Elwell, John > > > > Sent: Friday, May 20, 2011 4:27 PM > > > > To: Paul Kyzivat; Mike Hammer (hmmr) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > > Behalf Of Paul Kyzivat > > > > > Sent: 19 May 2011 15:08 > > > > > To: Mike Hammer (hmmr) > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > Mike, > > > > > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > > > Paul, > > > > > > > > > > > > What I am trying to say is that Telepresence is all about > > > > > the end-user > > > > > > experience, and that with multiple microphones, > > > speakers, cameras, > > > > > > displays, and data feeds there is more complexity and > > > > > chance to screw > > > > > > that up. And a key point is that spatial relationships are > > > > > significant > > > > > > to the user experience. As a result, more rigor is needed > > > > > to design the > > > > > > system to ensure that backward compatible means that legacy > > > > > systems are > > > > > > handled as such. > > > > > > > > > > > > I am not sure if the protocol design is far enough > > > along to analyze > > > > > > whether correct protocol operation still results in bad > > > > > user experience, > > > > > > but would suggest that if certain key concepts like spatial > > > > > awareness > > > > > > are not understood, then that leg needs to devolve to a > > > known legacy > > > > > > state and handled by the MCU as such. That might mean > > > tagging some > > > > > > parameters as mandatory to understand to force the > > > > > determination and not > > > > > > leave it ambiguous. > > > > > > > > > > > > I believe some current systems treat legacy systems > > > differently and > > > > > > don't expect them to behave like ones that understands > > > the dynamic > > > > > > speaker controls. > > > > > > > > > > I suspect we are talking past each other and are not really > > > > > in disagreement. > > > > > > > > > > I expect that the clue specs, whatever they turn out to be, > > > > > will require > > > > > support for a bunch of existing sip/sdp mechanisms that > > > are generally > > > > > optional and not widely implemented in lower end devices. > > > > > > > > > > If so, then if we have two clueful systems attempting to > > > connect, we > > > > > will be in the realm of negotiating using syntax that both > > > > > understand. > > > > > In that case, this discussion of how to behave when > > > something *isn't* > > > > > understood is moot. Rather that situation will arise when > > > we have a > > > > > clueful system attempting to connect to a clueless system, or visa > > > > > versa. That is where my focus is in this discussion. > > > > [JRE] And furthermore, we might have a conference > > > comprising a number of > > > > CLUEful endpoints and a number of CLUEless endpoints. We > > > would ideally like > > > > to be in a position where the CLUEful endpoint users can > > > share a telepresence > > > > experience, and yet the CLUEless endpoint users can still > > > participate > > > > meaningfully in the conference. > > > > > > > > John > > > > > > > > > > I think this is out of the scope of CLUE WG. > > [JRE] I don't know why you say that. In fact it is covered in the use > cases draft, > > section 4.5. > > > > John > > IMHO, the interworking with the CLUEless endpoints may mostly rely on the > existing standard for video conference, which will not be re-invented in > this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand > the existing standard in order to connect. What kind of signaling or > parameters MUST be communicated between the CLUEful endpoints or between > CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless > endpoints? Can they also be done by the internal implementation in MCU or > the endpoint? > > > By the way, I am not an expert on telepresence, maybe the question seems > stupid. > > Thanks, > -Haibin > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec547c9d3ca9b5904a4247d7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Haibin

Some ways of structuring the CLUE protocol might be very d= ifficult for existing endpoints to deal with.=A0 Other ways might be more &= quot;legacy friendly", in the sense that the ability to negotiate a CL= UEless call between a CLUEd endpoint and a normal SIP endpoint would be str= aightforward.

I think the intent of the requirement is to make sure the protocol desi= gn takes the second path.

The challenge is that AFAIK there is are n= o guarantees in SIP itself that assure any interoperability between the SIP= endpoints.=A0 For example, there is nothing in the SIP RFCs that mandate c= ommon codecs. Since compliant SIP endpoints might not interoperate anyway, = you can not guarantee that a CLUE endpoint can interoperate with them eithe= r.=A0 However, I think the intent is important, so we should try to craft w= ording that captures it.

Regards,
Stephen Botzko



On= Wed, May 25, 2011 at 9:50 PM, Songhaibin <haibin.song@huawei.com> wrote:=
Hi John and Paul,

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> Sent: Wednesday, May 25, 2011 10:00 PM
> To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr)
> Cc: clue@ietf.org
> Subject: RE: [clue] legacy support in requirements
>
>
>
> > -----Original Message-----
> > From: Songhaibin [mailto:haibin.song@huawei.com]
> > Sent: 25 May 2011 07:44
> > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr)
> > Cc: clue@ietf.org
> > Subject: RE: [clue] legacy support in requirements
> >
> >
> >
> > > -----Original Message-----
> > > From: clue-bounces@= ietf.org [mailto:clue-bounces@= ietf.org]
> > On Behalf Of
> > > Elwell, John
> > > Sent: Friday, May 20, 2011 4:27 PM
> > > To: Paul Kyzivat; Mike Hammer (hmmr)
> > > Cc: clue@ietf.org
> > > Subject: Re: [clue] legacy support in requirements
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: clue-bou= nces@ietf.org [mailto:clue-bou= nces@ietf.org] On
> > > > Behalf Of Paul Kyzivat
> > > > Sent: 19 May 2011 15:08
> > > > To: Mike Hammer (hmmr)
> > > > Cc: clue@ietf.org<= br> > > > > Subject: Re: [clue] legacy support in requirements
> > > >
> > > > Mike,
> > > >
> > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote:
> > > > > Paul,
> > > > >
> > > > > What I am trying to say is that Telepresence is al= l about
> > > > the end-user
> > > > > experience, and that with multiple microphones, > > speakers, cameras,
> > > > > displays, and data feeds there is more complexity = and
> > > > chance to screw
> > > > > that up. =A0And a key point is that spatial relati= onships are
> > > > significant
> > > > > to the user experience. =A0As a result, more rigor= is needed
> > > > to design the
> > > > > system to ensure that backward compatible means th= at legacy
> > > > systems are
> > > > > handled as such.
> > > > >
> > > > > I am not sure if the protocol design is far enough=
> > along to analyze
> > > > > whether correct protocol operation still results i= n bad
> > > > user experience,
> > > > > but would suggest that if certain key concepts lik= e spatial
> > > > awareness
> > > > > are not understood, then that leg needs to devolve= to a
> > known legacy
> > > > > state and handled by the MCU as such. =A0That migh= t mean
> > tagging some
> > > > > parameters as mandatory to understand to force the=
> > > > determination and not
> > > > > leave it ambiguous.
> > > > >
> > > > > I believe some current systems treat legacy system= s
> > differently and
> > > > > don't expect them to behave like ones that und= erstands
> > the dynamic
> > > > > speaker controls.
> > > >
> > > > I suspect we are talking past each other and are not re= ally
> > > > in disagreement.
> > > >
> > > > I expect that the clue specs, whatever they turn out to= be,
> > > > will require
> > > > support for a bunch of existing sip/sdp mechanisms that=
> > are generally
> > > > optional and not widely implemented in lower end device= s.
> > > >
> > > > If so, then if we have two clueful systems attempting t= o
> > connect, we
> > > > will be in the realm of negotiating using syntax that b= oth
> > > > understand.
> > > > In that case, this discussion of how to behave when
> > something *isn't*
> > > > understood is moot. Rather that situation will arise wh= en
> > we have a
> > > > clueful system attempting to connect to a clueless syst= em, or visa
> > > > versa. That is where my focus is in this discussion. > > > [JRE] And furthermore, we might have a conference
> > comprising a number of
> > > CLUEful endpoints and a number of CLUEless endpoints. We
> > would ideally like
> > > to be in a position where the CLUEful endpoint users can
> > share a telepresence
> > > experience, and yet the CLUEless endpoint users can still > > participate
> > > meaningfully in the conference.
> > >
> > > John
> > >
> >
> > I think this is out of the scope of CLUE WG.
> [JRE] I don't know why you say that. In fact it is covered in the = use cases draft,
> section 4.5.
>
> John

IMHO, the interworking with the CLUEless endpoints may mostly r= ely on the existing standard for video conference, which will not be re-inv= ented in this WG. The CLUEful endpoints/MCU(maybe not all of them) need to = understand the existing standard in order to connect. What kind of signalin= g or parameters MUST be communicated between the CLUEful endpoints or betwe= en CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless end= points? Can they also be done by the internal implementation in MCU or the = endpoint?


By the way, I am not an expert on telepresence, maybe the question seems st= upid.

Thanks,
-Haibin

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

--bcaec547c9d3ca9b5904a4247d7b-- From haibin.song@huawei.com Wed May 25 20:53:50 2011 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 55599E06A3 for ; Wed, 25 May 2011 20:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, 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 OORuv2qDIEvT for ; Wed, 25 May 2011 20:53:49 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2AE0695 for ; Wed, 25 May 2011 20:53:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS002FPARPZ9@szxga04-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 11:52:37 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS0098PARO9F@szxga04-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 11:52:37 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 11:52:31 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 26 May 2011 11:52:36 +0800 Date: Thu, 26 May 2011 03:52:35 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.119] To: Stephen Botzko Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] legacy support in requirements Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGD/7v0yMP/dN4PA/7roOAD/dTTOEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 26 May 2011 03:53:50 -0000 Hi Stephen, I just would like to dig out that if there is much work to do from the prot= ocol perspective to make the CLUE "legacy friendly", or it can be just an = implementation issue. I understand that the intent is important, and I also think that the second= path makes more sense:) BR, -Haibin From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Thursday, May 26, 2011 10:22 AM To: Songhaibin Cc: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr); clue@ietf.org Subject: Re: [clue] legacy support in requirements Hi Haibin Some ways of structuring the CLUE protocol might be very difficult for exis= ting endpoints to deal with.=A0 Other ways might be more "legacy friendly",= in the sense that the ability to negotiate a CLUEless call between a CLUEd= endpoint and a normal SIP endpoint would be straightforward. I think the intent of the requirement is to make sure the protocol design t= akes the second path. The challenge is that AFAIK there is are no guarantees in SIP itself that a= ssure any interoperability between the SIP endpoints.=A0 For example, there= is nothing in the SIP RFCs that mandate common codecs. Since compliant SIP= endpoints might not interoperate anyway, you can not guarantee that a CLUE= endpoint can interoperate with them either.=A0 However, I think the intent= is important, so we should try to craft wording that captures it. Regards, Stephen Botzko On Wed, May 25, 2011 at 9:50 PM, Songhaibin wrote: Hi John and Paul, > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 25, 2011 10:00 PM > To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > > > > -----Original Message----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: 25 May 2011 07:44 > > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > On Behalf Of > > > Elwell, John > > > Sent: Friday, May 20, 2011 4:27 PM > > > To: Paul Kyzivat; Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat > > > > Sent: 19 May 2011 15:08 > > > > To: Mike Hammer (hmmr) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > Mike, > > > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > > Paul, > > > > > > > > > > What I am trying to say is that Telepresence is all about > > > > the end-user > > > > > experience, and that with multiple microphones, > > speakers, cameras, > > > > > displays, and data feeds there is more complexity and > > > > chance to screw > > > > > that up. =A0And a key point is that spatial relationships are > > > > significant > > > > > to the user experience. =A0As a result, more rigor is needed > > > > to design the > > > > > system to ensure that backward compatible means that legacy > > > > systems are > > > > > handled as such. > > > > > > > > > > I am not sure if the protocol design is far enough > > along to analyze > > > > > whether correct protocol operation still results in bad > > > > user experience, > > > > > but would suggest that if certain key concepts like spatial > > > > awareness > > > > > are not understood, then that leg needs to devolve to a > > known legacy > > > > > state and handled by the MCU as such. =A0That might mean > > tagging some > > > > > parameters as mandatory to understand to force the > > > > determination and not > > > > > leave it ambiguous. > > > > > > > > > > I believe some current systems treat legacy systems > > differently and > > > > > don't expect them to behave like ones that understands > > the dynamic > > > > > speaker controls. > > > > > > > > I suspect we are talking past each other and are not really > > > > in disagreement. > > > > > > > > I expect that the clue specs, whatever they turn out to be, > > > > will require > > > > support for a bunch of existing sip/sdp mechanisms that > > are generally > > > > optional and not widely implemented in lower end devices. > > > > > > > > If so, then if we have two clueful systems attempting to > > connect, we > > > > will be in the realm of negotiating using syntax that both > > > > understand. > > > > In that case, this discussion of how to behave when > > something *isn't* > > > > understood is moot. Rather that situation will arise when > > we have a > > > > clueful system attempting to connect to a clueless system, or visa > > > > versa. That is where my focus is in this discussion. > > > [JRE] And furthermore, we might have a conference > > comprising a number of > > > CLUEful endpoints and a number of CLUEless endpoints. We > > would ideally like > > > to be in a position where the CLUEful endpoint users can > > share a telepresence > > > experience, and yet the CLUEless endpoint users can still > > participate > > > meaningfully in the conference. > > > > > > John > > > > > > > I think this is out of the scope of CLUE WG. > [JRE] I don't know why you say that. In fact it is covered in the use cas= es draft, > section 4.5. > > John IMHO, the interworking with the CLUEless endpoints may mostly rely on the e= xisting standard for video conference, which will not be re-invented in thi= s WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand t= he existing standard in order to connect. What kind of signaling or paramet= ers MUST be communicated between the CLUEful endpoints or between CLUEful e= ndpoint and CLUEful MCU, for the interworking with CLUEless endpoints? Can = they also be done by the internal implementation in MCU or the endpoint? By the way, I am not an expert on telepresence, maybe the question seems st= upid. Thanks, -Haibin _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Thu May 26 01:14:06 2011 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 C0399E067B for ; Thu, 26 May 2011 01:14:06 -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.999, 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 nLl36aWUTryJ for ; Thu, 26 May 2011 01:14:05 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F7E0671 for ; Thu, 26 May 2011 01:14:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00EC4MT09E@szxga05-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 16:12:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00MKDMT0LU@szxga05-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 16:12:36 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-31-209.red.bezeqint.net [79.182.31.209]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLS0082WMSVGE@szxml12-in.huawei.com> for clue@ietf.org; Thu, 26 May 2011 16:12:36 +0800 (CST) Date: Thu, 26 May 2011 11:10:38 +0300 From: Roni Even To: clue@ietf.org Message-id: <02af01cc1b7c$68e3dc80$3aab9580$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acwa3nCJCfdSs9UxS+2exb36nm6+MQAnZQcw Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-use-cases-02.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, 26 May 2011 08:14:06 -0000 Hi, I have submitted a new version with minor editorial changes. The main change is to remove the text referring to the problem statement. We are looking for more use cases if people have some they think we should have. Roni Even -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, May 25, 2011 4:19 PM To: Even.roni@huawei.com Cc: marshall.eubanks@ilformata.com; mark.duckworth@polycom.com; allyn@cisco.com; stephen.botzko@polycom.com; Even.roni@huawei.com Subject: New Version Notification for draft-romanow-clue-telepresence-use-cases-02.txt A new version of I-D, draft-romanow-clue-telepresence-use-cases-02.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-romanow-clue-telepresence-use-cases Revision: 02 Title: Use Cases for Telepresence Multi-streams Creation date: 2011-05-25 WG ID: Individual Submission Number of pages: 15 Abstract: Telepresence conferencing systems seek to create the sense of really being present. 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 Secretariat From pkyzivat@cisco.com Thu May 26 06:36:31 2011 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 D7C4CE071E for ; Thu, 26 May 2011 06:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.295 X-Spam-Level: X-Spam-Status: No, score=-110.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lbAWoqnuRmXV for ; Thu, 26 May 2011 06:36:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1229EE06FC for ; Thu, 26 May 2011 06:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6846; q=dns/txt; s=iport; t=1306416990; x=1307626590; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ESCixmf3dsGr5AlNoBrvGh0N19RwiZRfUkmHrZUzoBE=; b=lrN2OvKKK++uz/be1Sm7GGtGxCb0YX1z1qNbye8s0/g+bFarrLWTHb5K sWVuCIQcRc4Xh/Swu8dOrrpmCY8au8FTlGnQJJ25va9zGDzKpzBokK61t Z484hyN2/ZgNXLrumobKLXOHyeIdAJ7mtg+9V3iZpyD3Vg/tGc2pI77iE Q=; X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="324097345" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-3.cisco.com with ESMTP; 26 May 2011 13:34:07 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4QDY6sO023919; Thu, 26 May 2011 13:34:06 GMT Message-ID: <4DDE56CE.4060908@cisco.com> Date: Thu, 26 May 2011 09:34:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Songhaibin References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.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] legacy support in requirements 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, 26 May 2011 13:36:32 -0000 Haibin, (speaking as individual) IMO the key issue here is likely to be how to structure the initial invite from a CLUEful device. Hopefully it will be structured so that when processed by a CLUEless device that ignores all it doesn't understand, what remains will "make sense" to devices that could plausibly interoperate. Invites *from* a CLUEless device to a CLUEful device should be less trouble. Then it should be straightforward for the clueful device to recognize the situation and take appropriate action. Thanks, Paul On 5/25/2011 11:52 PM, Songhaibin wrote: > Hi Stephen, > > I just would like to dig out that if there is much work to do from the protocol perspective to make the CLUE "legacy friendly", or it can be just an implementation issue. > > I understand that the intent is important, and I also think that the second path makes more sense:) > > BR, > -Haibin > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Thursday, May 26, 2011 10:22 AM > To: Songhaibin > Cc: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr); clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > Hi Haibin > > Some ways of structuring the CLUE protocol might be very difficult for existing endpoints to deal with. Other ways might be more "legacy friendly", in the sense that the ability to negotiate a CLUEless call between a CLUEd endpoint and a normal SIP endpoint would be straightforward. > > I think the intent of the requirement is to make sure the protocol design takes the second path. > > The challenge is that AFAIK there is are no guarantees in SIP itself that assure any interoperability between the SIP endpoints. For example, there is nothing in the SIP RFCs that mandate common codecs. Since compliant SIP endpoints might not interoperate anyway, you can not guarantee that a CLUE endpoint can interoperate with them either. However, I think the intent is important, so we should try to craft wording that captures it. > > Regards, > Stephen Botzko > > > On Wed, May 25, 2011 at 9:50 PM, Songhaibin wrote: > Hi John and Paul, > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Wednesday, May 25, 2011 10:00 PM >> To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) >> Cc: clue@ietf.org >> Subject: RE: [clue] legacy support in requirements >> >> >> >>> -----Original Message----- >>> From: Songhaibin [mailto:haibin.song@huawei.com] >>> Sent: 25 May 2011 07:44 >>> To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] >>> On Behalf Of >>>> Elwell, John >>>> Sent: Friday, May 20, 2011 4:27 PM >>>> To: Paul Kyzivat; Mike Hammer (hmmr) >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: 19 May 2011 15:08 >>>>> To: Mike Hammer (hmmr) >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> Mike, >>>>> >>>>> On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: >>>>>> Paul, >>>>>> >>>>>> What I am trying to say is that Telepresence is all about >>>>> the end-user >>>>>> experience, and that with multiple microphones, >>> speakers, cameras, >>>>>> displays, and data feeds there is more complexity and >>>>> chance to screw >>>>>> that up. And a key point is that spatial relationships are >>>>> significant >>>>>> to the user experience. As a result, more rigor is needed >>>>> to design the >>>>>> system to ensure that backward compatible means that legacy >>>>> systems are >>>>>> handled as such. >>>>>> >>>>>> I am not sure if the protocol design is far enough >>> along to analyze >>>>>> whether correct protocol operation still results in bad >>>>> user experience, >>>>>> but would suggest that if certain key concepts like spatial >>>>> awareness >>>>>> are not understood, then that leg needs to devolve to a >>> known legacy >>>>>> state and handled by the MCU as such. That might mean >>> tagging some >>>>>> parameters as mandatory to understand to force the >>>>> determination and not >>>>>> leave it ambiguous. >>>>>> >>>>>> I believe some current systems treat legacy systems >>> differently and >>>>>> don't expect them to behave like ones that understands >>> the dynamic >>>>>> speaker controls. >>>>> >>>>> I suspect we are talking past each other and are not really >>>>> in disagreement. >>>>> >>>>> I expect that the clue specs, whatever they turn out to be, >>>>> will require >>>>> support for a bunch of existing sip/sdp mechanisms that >>> are generally >>>>> optional and not widely implemented in lower end devices. >>>>> >>>>> If so, then if we have two clueful systems attempting to >>> connect, we >>>>> will be in the realm of negotiating using syntax that both >>>>> understand. >>>>> In that case, this discussion of how to behave when >>> something *isn't* >>>>> understood is moot. Rather that situation will arise when >>> we have a >>>>> clueful system attempting to connect to a clueless system, or visa >>>>> versa. That is where my focus is in this discussion. >>>> [JRE] And furthermore, we might have a conference >>> comprising a number of >>>> CLUEful endpoints and a number of CLUEless endpoints. We >>> would ideally like >>>> to be in a position where the CLUEful endpoint users can >>> share a telepresence >>>> experience, and yet the CLUEless endpoint users can still >>> participate >>>> meaningfully in the conference. >>>> >>>> John >>>> >>> >>> I think this is out of the scope of CLUE WG. >> [JRE] I don't know why you say that. In fact it is covered in the use cases draft, >> section 4.5. >> >> John > IMHO, the interworking with the CLUEless endpoints may mostly rely on the existing standard for video conference, which will not be re-invented in this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand the existing standard in order to connect. What kind of signaling or parameters MUST be communicated between the CLUEful endpoints or between CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless endpoints? Can they also be done by the internal implementation in MCU or the endpoint? > > > By the way, I am not an expert on telepresence, maybe the question seems stupid. > > Thanks, > -Haibin > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From allyn@cisco.com Thu May 26 12:08:32 2011 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 791B2E077B for ; Thu, 26 May 2011 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 XOt+azmoaUV3 for ; Thu, 26 May 2011 12:08:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 20719E0779 for ; Thu, 26 May 2011 12:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7658; q=dns/txt; s=iport; t=1306436905; x=1307646505; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZMByfa4YqKRYxccl4tbwoeT4h1J+GlIFxkoxk9ilN2U=; b=OQsgEXnY0e9bef30B8TeemEaT6T6aOCLga44DLlkFc9Y8ghC7XI+FGxK zXT5QD+eeK2/XnzgJXWRVY7ivEcMp8+MqO0bQsNEOXvUa8jFfubbqzk+j IUDCLs8s7N4Kzsd+G21OMiGeVtKjNJhG1JD5pSJOTqO5X+P6cadHxsv5q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAHek3k2rRDoG/2dsb2JhbAA2Hpdojkp4qE+QJI02hhwEhmGOGopu X-IronPort-AV: E=Sophos;i="4.65,275,1304294400"; d="scan'208";a="364990599" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 26 May 2011 19:08:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QJ8OmL024100; Thu, 26 May 2011 19:08:24 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 12:08:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BCPX CG+2 EG9e EZ2p EaCQ FLBZ Jql6 Jv9g Nezz RC3c SwM6 SyMI UYXe WTIe XDG7 YHgv; 3; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAdgBlAG4ALgByAG8AbgBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0A; Sosha1_v1; 7; {11A41F5D-4F75-4F94-B89D-62E72B1899D2}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 26 May 2011 19:08:16 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAGwAZQBnAGEAYwB5ACAAcwB1AHAAcABvAHIAdAAgAGkAbgAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {11A41F5D-4F75-4F94-B89D-62E72B1899D2} Content-class: urn:content-classes:message Date: Thu, 26 May 2011 12:08:16 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> In-Reply-To: <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQAAlDx0ABk+wMgA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 26 May 2011 19:08:24.0817 (UTC) FILETIME=[49932E10:01CC1BD8] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 26 May 2011 19:08:32 -0000 Roni, Paul, John- Would you care to suggest the wording you would like to see as a requirement for legacy interoperability? That would be helpful. Thanks, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Wednesday, May 18, 2011 11:13 AM > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 .... >=20 > Anyhow we are discussing solution while my point is that we will need > as a > requirement to address the case of a call from a CLUE aware endpoint to > a > non CLUE aware endpoint. Even if the consensus will be to have the > preferred > video in the first video m-line. >=20 > Regards > Roni >=20 >=20 >=20 > > -----Original Message----- > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > Sent: Wednesday, May 18, 2011 4:41 PM > > To: Paul Kyzivat (pkyzivat); Roni Even > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > Paul, > > > > I would agree that if the offer-answer model semantic is that here > are > > several options and any subset of options is acceptable. > > > > However, if there is any grouping involved such that you need to have > a > > video and audio feed integrated to make sense then watch out. > > > > For example, I wouldn't want to end up with the result of a man's > video > > paired with a woman's voice. That could be rather comical. > > > > Mike > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat (pkyzivat) > > Sent: Tuesday, May 17, 2011 7:45 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > Paul, > > > I think we read it differently. > > > If the answerer does not support the group attribute and the offer > > had > > the > > > fid semantics it may look to the answerer as an offer with multiple > > m-lines > > > of the same media tyoe. In this case an implementation might also > > decide to > > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > Acceptable), > > > because it contains several "m" lines of the same media type. > > > > That is a slightly different story. > > > > Then the reason for rejection is not because it saw an attribute it > > didn't understand - its because it didn't like something it *did* > > understand. > > > > > This is very relevant to the multiple streams case and we should > look > > if we > > > state this behavior or we will look at providing an approach that > > will > > allow > > > the answerer to choose one m-line that the offerer prefers even of > it > > does > > > not understand CLUE. > > > > IMO (lets see if others differ), if a UA receives an offer with at > > least > > > > one m-line it is happy with, then it should not reject the call > because > > there are others that it does not "understand". > > > > Here "understand" means something different - presumably it does > > understand the direct meaning of the additional m-line, it just > doesn't > > understand the *significance* or use of it. > > > > I see little difference to getting to audio m-lines and only wanting > > one, and getting one audio and one video and only supporting audio. > In > > general you should not reject an audio/video call just because you > only > > support audio. > > > > I think it will behoove clue to strongly recommend that the m-lines > in > > an offer be arranged so the first ones are the ones it most wants > used > > if not all are. > > > > Thanks, > > Paul > > > > > Roni > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > >> To: Roni Even > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > >> Subject: Re: [clue] legacy support in requirements > > >> > > >> > > >> > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > >>> Paul, > > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > example > > >>> Roni > > >> > > >> OK, I looked. It is consistent with what I said. > > >> Either a=3Dgroup: is understood, or not. If not, its ignored, and > not > > put > > >> in the answer. Same with a=3Dmid: > > >> > > >> If a=3Dgroup: *is* understood, but some parameter within it is = not, > > there > > >> are explicit rules for what to do. > > >> > > >> AFAICT there are no examples in this document where failure to > > >> understand an a-line in total (or even in part) results in > rejecting > > >> the > > >> offer. > > >> > > >> Thanks, > > >> Paul > > >> > > >>>> -----Original Message----- > > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >> Of > > >>>> Paul Kyzivat > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > >>>> To: Stephen Botzko > > >>>> Cc: clue@ietf.org > > >>>> Subject: Re: [clue] legacy support in requirements > > >>>> > > >>>> > > >>>> > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > >>>> > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > >>>> > > >>>>> When the offer includes parameters that the answerer > > does > > >> not > > >>>>> understand > > >>>>> there are two options, he can ignore the unknown > > >> parameters > > >>>> or > > >>>>> reject > > >>>>> the offer. > > >>>>> Rejecting the offer in that case is not really kosher. > > >>>>> You are required to ignore parameters you do not > > understand. > > >>>>> > > >>>>> If you reject something because you don't like the > > parameters > > >> it > > >>>>> contains, then that is an implicit statement that you > > >> understand > > >>>>> those parameters well enough to decide to reject them. > > >>>>> > > >>>>> As far as I know, you are always free to reject offers, and it > > >>>> doesn't > > >>>>> really imply anything when you do that.. Whether it is wise is > > >>>> perhaps > > >>>>> a different question. > > >>>>> Stephen Botzko > > >>>> > > >>>> Certainly you are always free to reject an offer. > > >>>> In general I don't know for certain the reason why, and so if I > > give > > >>>> you > > >>>> the benefit of the doubt I will assume you have a valid reason - > > >>>> perhaps > > >>>> just policy. > > >>>> > > >>>> But if the reason you reject the offer is based on your > violating > > a > > >>>> spec, then you are non-conforming, whether I can determine you > are > > >>>> non-conforming or not. Whether being non-conforming is just > > un-wise, > > >> or > > >>>> something stronger, is a separate discussion. The IETF does not > > levy > > >>>> any > > >>>> penalties for violating its specs. But sometimes the market > does. > > >> (And > > >>>> sometimes not.) But we don't need to endorse non-conforming > > behavior > > >> in > > >>>> our documents. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> _______________________________________________ > > >>>> clue mailing list > > >>>> clue@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >>> > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john.elwell@siemens-enterprise.com Thu May 26 23:21:51 2011 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 20861E0686 for ; Thu, 26 May 2011 23:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 OcAy+5spamiw for ; Thu, 26 May 2011 23:21:49 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 597D5E06F2 for ; Thu, 26 May 2011 23:21:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1306477307!6260985!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 14308 invoked from network); 27 May 2011 06:21:47 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-216.messagelabs.com with SMTP; 27 May 2011 06:21:47 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id BF1F123F03E6; Fri, 27 May 2011 08:21:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 27 May 2011 08:21:47 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , Roni Even , "Paul Kyzivat (pkyzivat)" Date: Fri, 27 May 2011 08:21:46 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQAAlDx0ABk+wMgAAYLHfQ Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 06:21:51 -0000 Allyn, I already made a proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00221.html John =20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: 26 May 2011 20:08 > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > Roni, Paul, John- > Would you care to suggest the wording you would like to see as a > requirement for legacy interoperability? That would be helpful. >=20 > Thanks, > Allyn >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Roni Even > > Sent: Wednesday, May 18, 2011 11:13 AM > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > >=20 > .... > >=20 > > Anyhow we are discussing solution while my point is that we=20 > will need > > as a > > requirement to address the case of a call from a CLUE aware endpoint > to > > a > > non CLUE aware endpoint. Even if the consensus will be to have the > > preferred > > video in the first video m-line. > >=20 > > Regards > > Roni > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > Paul, > > > > > > I would agree that if the offer-answer model semantic is that here > > are > > > several options and any subset of options is acceptable. > > > > > > However, if there is any grouping involved such that you need to > have > > a > > > video and audio feed integrated to make sense then watch out. > > > > > > For example, I wouldn't want to end up with the result of a man's > > video > > > paired with a woman's voice. That could be rather comical. > > > > > > Mike > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Paul Kyzivat (pkyzivat) > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > To: Roni Even > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > Paul, > > > > I think we read it differently. > > > > If the answerer does not support the group attribute=20 > and the offer > > > had > > > the > > > > fid semantics it may look to the answerer as an offer with > multiple > > > m-lines > > > > of the same media tyoe. In this case an implementation=20 > might also > > > decide to > > > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > > Acceptable), > > > > because it contains several "m" lines of the same media type. > > > > > > That is a slightly different story. > > > > > > Then the reason for rejection is not because it saw an=20 > attribute it > > > didn't understand - its because it didn't like something it *did* > > > understand. > > > > > > > This is very relevant to the multiple streams case and we should > > look > > > if we > > > > state this behavior or we will look at providing an=20 > approach that > > > will > > > allow > > > > the answerer to choose one m-line that the offerer=20 > prefers even of > > it > > > does > > > > not understand CLUE. > > > > > > IMO (lets see if others differ), if a UA receives an offer with at > > > least > > > > > > one m-line it is happy with, then it should not reject the call > > because > > > there are others that it does not "understand". > > > > > > Here "understand" means something different - presumably it does > > > understand the direct meaning of the additional m-line, it just > > doesn't > > > understand the *significance* or use of it. > > > > > > I see little difference to getting to audio m-lines and=20 > only wanting > > > one, and getting one audio and one video and only=20 > supporting audio. > > In > > > general you should not reject an audio/video call just because you > > only > > > support audio. > > > > > > I think it will behoove clue to strongly recommend that=20 > the m-lines > > in > > > an offer be arranged so the first ones are the ones it most wants > > used > > > if not all are. > > > > > > Thanks, > > > Paul > > > > > > > Roni > > > > > > > >> -----Original Message----- > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > >> To: Roni Even > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > >> Subject: Re: [clue] legacy support in requirements > > > >> > > > >> > > > >> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > >>> Paul, > > > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > example > > > >>> Roni > > > >> > > > >> OK, I looked. It is consistent with what I said. > > > >> Either a=3Dgroup: is understood, or not. If not, its ignored, and > > not > > > put > > > >> in the answer. Same with a=3Dmid: > > > >> > > > >> If a=3Dgroup: *is* understood, but some parameter within=20 > it is not, > > > there > > > >> are explicit rules for what to do. > > > >> > > > >> AFAICT there are no examples in this document where failure to > > > >> understand an a-line in total (or even in part) results in > > rejecting > > > >> the > > > >> offer. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >>>> -----Original Message----- > > > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf > > > >> Of > > > >>>> Paul Kyzivat > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > >>>> To: Stephen Botzko > > > >>>> Cc: clue@ietf.org > > > >>>> Subject: Re: [clue] legacy support in requirements > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > >>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > >>>> > > > >>>>> When the offer includes parameters that=20 > the answerer > > > does > > > >> not > > > >>>>> understand > > > >>>>> there are two options, he can ignore the unknown > > > >> parameters > > > >>>> or > > > >>>>> reject > > > >>>>> the offer. > > > >>>>> Rejecting the offer in that case is not really kosher. > > > >>>>> You are required to ignore parameters you do not > > > understand. > > > >>>>> > > > >>>>> If you reject something because you don't like the > > > parameters > > > >> it > > > >>>>> contains, then that is an implicit statement that you > > > >> understand > > > >>>>> those parameters well enough to decide to reject them. > > > >>>>> > > > >>>>> As far as I know, you are always free to reject=20 > offers, and it > > > >>>> doesn't > > > >>>>> really imply anything when you do that.. Whether it is wise > is > > > >>>> perhaps > > > >>>>> a different question. > > > >>>>> Stephen Botzko > > > >>>> > > > >>>> Certainly you are always free to reject an offer. > > > >>>> In general I don't know for certain the reason why,=20 > and so if I > > > give > > > >>>> you > > > >>>> the benefit of the doubt I will assume you have a=20 > valid reason > - > > > >>>> perhaps > > > >>>> just policy. > > > >>>> > > > >>>> But if the reason you reject the offer is based on your > > violating > > > a > > > >>>> spec, then you are non-conforming, whether I can=20 > determine you > > are > > > >>>> non-conforming or not. Whether being non-conforming is just > > > un-wise, > > > >> or > > > >>>> something stronger, is a separate discussion. The=20 > IETF does not > > > levy > > > >>>> any > > > >>>> penalties for violating its specs. But sometimes the market > > does. > > > >> (And > > > >>>> sometimes not.) But we don't need to endorse non-conforming > > > behavior > > > >> in > > > >>>> our documents. > > > >>>> > > > >>>> Thanks, > > > >>>> Paul > > > >>>> _______________________________________________ > > > >>>> clue mailing list > > > >>>> clue@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > >>> > > > >>> > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > >=20 > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From stephen.botzko@gmail.com Fri May 27 03:53:20 2011 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 A8C44E06BE for ; Fri, 27 May 2011 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.265, 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 UPBn-wUNxQw1 for ; Fri, 27 May 2011 03:53:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBCA9E0662 for ; Fri, 27 May 2011 03:53:18 -0700 (PDT) Received: by vxg33 with SMTP id 33so1570738vxg.31 for ; Fri, 27 May 2011 03:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Yg17ULvne4TNYSwXUpa3rkpIjYEO/yxNiLp2t7Z6jg=; b=M5JHlzFFzxFbPak6IQDP2qp6N7XexdpVMRHc+e0nvOJDcmSu3azPIuVFgFm+qjbzzo 0j0y8NX+M60uppDKTdX2CrITDeBBlsf4IClgUG6bJ5DYggWa0XwNiUy6iTaxqk2HfXu4 +U6PQGejXd81WvfQSxVt3uBIuHiXBjVIXS89c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e1AEZSBItUgWDOBXZYDnW5jTGG3muHu/eqk1PE3rFHXTWPzBSxyjc2P0v9NaJCT0G2 s2soA3l6kxEHvoXmZ+d8abRWkH5op6wyMxX/u1qp23raBRo5VKaFzyt5BogO/lt78f+R AyrQuh61m5TbPLfeHigfm6fqFkNNv8bdaLTU0= MIME-Version: 1.0 Received: by 10.52.182.98 with SMTP id ed2mr2915314vdc.120.1306493597959; Fri, 27 May 2011 03:53:17 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Fri, 27 May 2011 03:53:17 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> Date: Fri, 27 May 2011 06:53:17 -0400 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=bcaec547c9d3cec7b504a43fbec5 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 10:53:20 -0000 --bcaec547c9d3cec7b504a43fbec5 Content-Type: text/plain; charset=ISO-8859-1 Do you think that the language in requirement 10 means "SIP capabilities"? Or something else? I am thinking that issue is really about the signaling/protocol design itself, and isn't directly related to how many screens and cameras a system might have. Stephen Botzko On Fri, May 27, 2011 at 2:21 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Allyn, > > I already made a proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > John > > > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: 26 May 2011 20:08 > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > Roni, Paul, John- > > Would you care to suggest the wording you would like to see as a > > requirement for legacy interoperability? That would be helpful. > > > > Thanks, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Roni Even > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > .... > > > > > > Anyhow we are discussing solution while my point is that we > > will need > > > as a > > > requirement to address the case of a call from a CLUE aware endpoint > > to > > > a > > > non CLUE aware endpoint. Even if the consensus will be to have the > > > preferred > > > video in the first video m-line. > > > > > > Regards > > > Roni > > > > > > > > > > > > > -----Original Message----- > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > Cc: clue@ietf.org > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > Paul, > > > > > > > > I would agree that if the offer-answer model semantic is that here > > > are > > > > several options and any subset of options is acceptable. > > > > > > > > However, if there is any grouping involved such that you need to > > have > > > a > > > > video and audio feed integrated to make sense then watch out. > > > > > > > > For example, I wouldn't want to end up with the result of a man's > > > video > > > > paired with a woman's voice. That could be rather comical. > > > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Paul Kyzivat (pkyzivat) > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > To: Roni Even > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > Paul, > > > > > I think we read it differently. > > > > > If the answerer does not support the group attribute > > and the offer > > > > had > > > > the > > > > > fid semantics it may look to the answerer as an offer with > > multiple > > > > m-lines > > > > > of the same media tyoe. In this case an implementation > > might also > > > > decide to > > > > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > > > Acceptable), > > > > > because it contains several "m" lines of the same media type. > > > > > > > > That is a slightly different story. > > > > > > > > Then the reason for rejection is not because it saw an > > attribute it > > > > didn't understand - its because it didn't like something it *did* > > > > understand. > > > > > > > > > This is very relevant to the multiple streams case and we should > > > look > > > > if we > > > > > state this behavior or we will look at providing an > > approach that > > > > will > > > > allow > > > > > the answerer to choose one m-line that the offerer > > prefers even of > > > it > > > > does > > > > > not understand CLUE. > > > > > > > > IMO (lets see if others differ), if a UA receives an offer with at > > > > least > > > > > > > > one m-line it is happy with, then it should not reject the call > > > because > > > > there are others that it does not "understand". > > > > > > > > Here "understand" means something different - presumably it does > > > > understand the direct meaning of the additional m-line, it just > > > doesn't > > > > understand the *significance* or use of it. > > > > > > > > I see little difference to getting to audio m-lines and > > only wanting > > > > one, and getting one audio and one video and only > > supporting audio. > > > In > > > > general you should not reject an audio/video call just because you > > > only > > > > support audio. > > > > > > > > I think it will behoove clue to strongly recommend that > > the m-lines > > > in > > > > an offer be arranged so the first ones are the ones it most wants > > > used > > > > if not all are. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Roni > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > >> To: Roni Even > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > >> Subject: Re: [clue] legacy support in requirements > > > > >> > > > > >> > > > > >> > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > >>> Paul, > > > > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > example > > > > >>> Roni > > > > >> > > > > >> OK, I looked. It is consistent with what I said. > > > > >> Either a=group: is understood, or not. If not, its ignored, and > > > not > > > > put > > > > >> in the answer. Same with a=mid: > > > > >> > > > > >> If a=group: *is* understood, but some parameter within > > it is not, > > > > there > > > > >> are explicit rules for what to do. > > > > >> > > > > >> AFAICT there are no examples in this document where failure to > > > > >> understand an a-line in total (or even in part) results in > > > rejecting > > > > >> the > > > > >> offer. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>>> -----Original Message----- > > > > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > >> Of > > > > >>>> Paul Kyzivat > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > >>>> To: Stephen Botzko > > > > >>>> Cc: clue@ietf.org > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > >>>> > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > >>>> > > > > >>>>> When the offer includes parameters that > > the answerer > > > > does > > > > >> not > > > > >>>>> understand > > > > >>>>> there are two options, he can ignore the unknown > > > > >> parameters > > > > >>>> or > > > > >>>>> reject > > > > >>>>> the offer. > > > > >>>>> Rejecting the offer in that case is not really kosher. > > > > >>>>> You are required to ignore parameters you do not > > > > understand. > > > > >>>>> > > > > >>>>> If you reject something because you don't like the > > > > parameters > > > > >> it > > > > >>>>> contains, then that is an implicit statement that you > > > > >> understand > > > > >>>>> those parameters well enough to decide to reject them. > > > > >>>>> > > > > >>>>> As far as I know, you are always free to reject > > offers, and it > > > > >>>> doesn't > > > > >>>>> really imply anything when you do that.. Whether it is wise > > is > > > > >>>> perhaps > > > > >>>>> a different question. > > > > >>>>> Stephen Botzko > > > > >>>> > > > > >>>> Certainly you are always free to reject an offer. > > > > >>>> In general I don't know for certain the reason why, > > and so if I > > > > give > > > > >>>> you > > > > >>>> the benefit of the doubt I will assume you have a > > valid reason > > - > > > > >>>> perhaps > > > > >>>> just policy. > > > > >>>> > > > > >>>> But if the reason you reject the offer is based on your > > > violating > > > > a > > > > >>>> spec, then you are non-conforming, whether I can > > determine you > > > are > > > > >>>> non-conforming or not. Whether being non-conforming is just > > > > un-wise, > > > > >> or > > > > >>>> something stronger, is a separate discussion. The > > IETF does not > > > > levy > > > > >>>> any > > > > >>>> penalties for violating its specs. But sometimes the market > > > does. > > > > >> (And > > > > >>>> sometimes not.) But we don't need to endorse non-conforming > > > > behavior > > > > >> in > > > > >>>> our documents. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Paul > > > > >>>> _______________________________________________ > > > > >>>> clue mailing list > > > > >>>> clue@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > >>> > > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec547c9d3cec7b504a43fbec5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you think that the language in requirement 10 means "SIP capabiliti= es"?=A0 Or something else?

I am thinking that issue is really a= bout the signaling/protocol design itself, and isn't directly related t= o how many screens and cameras a system might have.

Stephen Botzko

On Fri, May 27, 2011 a= t 2:21 AM, Elwell, John <john.elwell@siemens-enterprise.com> = wrote:
Allyn,

I already made a proposal:
http://www.ietf.org/mail-archive/web/clue/current/msg002= 21.html

John


> -----Original Message-----
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: 26 May 2011 20:08
> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John
> Cc: clue@ietf.org
> Subject: RE: [clue] legacy support in requirements
>
> Roni, Paul, John-
> Would you care to suggest the wording you would like to see as a
> requirement for legacy interoperability? That would be helpful.
>
> Thanks,
> Allyn
>
> > -----Original Message-----
> > From: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.= org] On Behalf
> Of
> > Roni Even
> > Sent: Wednesday, May 18, 2011 11:13 AM
> > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)
> > Cc: clue@ietf.org
> > Subject: Re: [clue] legacy support in requirements
> >
> ....
> >
> > Anyhow we are discussing solution while my point is that we
> will need
> > as a
> > requirement to address the case of a call from a CLUE aware endpo= int
> to
> > a
> > non CLUE aware endpoint. Even if the consensus will be to have th= e
> > preferred
> > video in the first video m-line.
> >
> > Regards
> > Roni
> >
> >
> >
> > > -----Original Message-----
> > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com]
> > > Sent: Wednesday, May 18, 2011 4:41 PM
> > > To: Paul Kyzivat (pkyzivat); Roni Even
> > > Cc: clue@ietf.org
> > > Subject: RE: [clue] legacy support in requirements
> > >
> > > Paul,
> > >
> > > I would agree that if the offer-answer model semantic is tha= t here
> > are
> > > several options and any subset of options is acceptable.
> > >
> > > However, if there is any grouping involved such that you nee= d to
> have
> > a
> > > video and audio feed integrated to make sense then watch out= .
> > >
> > > For example, I wouldn't want to end up with the result o= f a man's
> > video
> > > paired with a woman's voice. =A0That could be rather com= ical.
> > >
> > > Mike
> > >
> > >
> > > -----Original Message-----
> > > From: clue-bounces@= ietf.org
> [mailto:clue-bounces@ietf.org= ] On Behalf
> > Of
> > > Paul Kyzivat (pkyzivat)
> > > Sent: Tuesday, May 17, 2011 7:45 PM
> > > To: Roni Even
> > > Cc: clue@ietf.org
> > > Subject: Re: [clue] legacy support in requirements
> > >
> > >
> > >
> > > On 5/17/2011 6:05 PM, Roni Even wrote:
> > > > Paul,
> > > > I think we read it differently.
> > > > If the answerer does not support the group attribute > and the offer
> > > had
> > > the
> > > > fid semantics it may look to the answerer as an offer w= ith
> multiple
> > > m-lines
> > > > of the same media tyoe. In this case an implementation<= br> > might also
> > > decide to
> > > > refuse the request (e.g., 488 Not Acceptable Here, or 6= 06 Not
> > > Acceptable),
> > > > because it contains several "m" lines of the = same media type.
> > >
> > > That is a slightly different story.
> > >
> > > Then the reason for rejection is not because it saw an
> attribute it
> > > didn't understand - its because it didn't like somet= hing it *did*
> > > understand.
> > >
> > > > This is very relevant to the multiple streams case and = we should
> > look
> > > if we
> > > > state this behavior or we will look at providing an
> approach that
> > > will
> > > allow
> > > > the answerer to choose one m-line that the offerer
> prefers even of
> > it
> > > does
> > > > not understand CLUE.
> > >
> > > IMO (lets see if others differ), if a UA receives an offer w= ith at
> > > least
> > >
> > > one m-line it is happy with, then it should not reject the c= all
> > because
> > > there are others that it does not "understand". > > >
> > > Here "understand" means something different - pres= umably it does
> > > understand the direct meaning of the additional m-line, it j= ust
> > doesn't
> > > understand the *significance* or use of it.
> > >
> > > I see little difference to getting to audio m-lines and
> only wanting
> > > one, and getting one audio and one video and only
> supporting audio.
> > In
> > > general you should not reject an audio/video call just becau= se you
> > only
> > > support audio.
> > >
> > > I think it will behoove clue to strongly recommend that
> the m-lines
> > in
> > > an offer be arranged so the first ones are the ones it most = wants
> > used
> > > if not all are.
> > >
> > > =A0 Thanks,
> > > =A0 Paul
> > >
> > > > Roni
> > > >
> > > >> -----Original Message-----
> > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > >> Sent: Wednesday, May 18, 2011 12:37 AM
> > > >> To: Roni Even
> > > >> Cc: 'Stephen Botzko'; clue@ietf.org
> > > >> Subject: Re: [clue] legacy support in requirements<= br> > > > >>
> > > >>
> > > >>
> > > >> On 5/17/2011 5:20 PM, Roni Even wrote:
> > > >>> Paul,
> > > >>> Look at http://tools.ietf.org/html/rfc5888#= section-9.4.2 for
> > > example
> > > >>> Roni
> > > >>
> > > >> OK, I looked. It is consistent with what I said. > > > >> Either a=3Dgroup: is understood, or not. If not, it= s ignored, and
> > not
> > > put
> > > >> in the answer. Same with a=3Dmid:
> > > >>
> > > >> If a=3Dgroup: *is* understood, but some parameter w= ithin
> it is not,
> > > there
> > > >> are explicit rules for what to do.
> > > >>
> > > >> AFAICT there are no examples in this document where= failure to
> > > >> understand an a-line in total (or even in part) res= ults in
> > rejecting
> > > >> the
> > > >> offer.
> > > >>
> > > >> =A0 =A0 =A0 =A0Thanks,
> > > >> =A0 =A0 =A0 =A0Paul
> > > >>
> > > >>>> -----Original Message-----
> > > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> > > Behalf
> > > >> Of
> > > >>>> Paul Kyzivat
> > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM
> > > >>>> To: Stephen Botzko
> > > >>>> Cc: clue@i= etf.org
> > > >>>> Subject: Re: [clue] legacy support in requi= rements
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote= :
> > > >>>>
> > > >>>>> =A0 =A0 =A0 On 5/17/2011 2:24 AM, Roni = Even wrote:
> > > >>>>
> > > >>>>> =A0 =A0 =A0 =A0 =A0 When the offer incl= udes parameters that
> the answerer
> > > does
> > > >> not
> > > >>>>> =A0 =A0 =A0 =A0 =A0 understand
> > > >>>>> =A0 =A0 =A0 =A0 =A0 there are two optio= ns, he can ignore the unknown
> > > >> parameters
> > > >>>> or
> > > >>>>> =A0 =A0 =A0 =A0 =A0 reject
> > > >>>>> =A0 =A0 =A0 =A0 =A0 the offer.
> > > >>>>> =A0 =A0 =A0 Rejecting the offer in that= case is not really kosher.
> > > >>>>> =A0 =A0 =A0 You are required to ignore = parameters you do not
> > > understand.
> > > >>>>>
> > > >>>>> =A0 =A0 =A0 If you reject something bec= ause you don't like the
> > > parameters
> > > >> it
> > > >>>>> =A0 =A0 =A0 contains, then that is an i= mplicit statement that you
> > > >> understand
> > > >>>>> =A0 =A0 =A0 those parameters well enoug= h to decide to reject them.
> > > >>>>>
> > > >>>>> As far as I know, you are always free t= o reject
> offers, and it
> > > >>>> doesn't
> > > >>>>> really imply anything when you do that.= . =A0Whether it is wise
> is
> > > >>>> perhaps
> > > >>>>> a different question.
> > > >>>>> Stephen Botzko
> > > >>>>
> > > >>>> Certainly you are always free to reject an = offer.
> > > >>>> In general I don't know for certain the= reason why,
> and so if I
> > > give
> > > >>>> you
> > > >>>> the benefit of the doubt I will assume you = have a
> valid reason
> -
> > > >>>> perhaps
> > > >>>> just policy.
> > > >>>>
> > > >>>> But if the reason you reject the offer is b= ased on your
> > violating
> > > a
> > > >>>> spec, then you are non-conforming, whether = I can
> determine you
> > are
> > > >>>> non-conforming or not. Whether being non-co= nforming is just
> > > un-wise,
> > > >> or
> > > >>>> something stronger, is a separate discussio= n. The
> IETF does not
> > > levy
> > > >>>> any
> > > >>>> penalties for violating its specs. But some= times the market
> > does.
> > > >> (And
> > > >>>> sometimes not.) But we don't need to en= dorse non-conforming
> > > behavior
> > > >> in
> > > >>>> our documents.
> > > >>>>
> > > >>>> =A0 =A0 =A0Thanks,
> > > >>>> =A0 =A0 =A0Paul
> > > >>>> ___________________________________________= ____
> > > >>>> clue mailing list
> > > >>>> clue@ietf.= org
> > > >>>> https://www.ietf.org/mailman/listinfo/clue
> > > >>>
> > > >>>
> > > >
> > > >
> > > _______________________________________________
> > > clue mailing list
> > > clue@ietf.org
> > > https://www.ietf.org/mailman/listinfo/clue
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec547c9d3cec7b504a43fbec5-- From john.elwell@siemens-enterprise.com Fri May 27 04:03:13 2011 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 BC6BAE0679 for ; Fri, 27 May 2011 04:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfNm7twLFps7 for ; Fri, 27 May 2011 04:03:12 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 0A142E067B for ; Fri, 27 May 2011 04:03:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1306494184!36206302!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20492 invoked from network); 27 May 2011 11:03:04 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-21.messagelabs.com with SMTP; 27 May 2011 11:03:04 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CDD8723F03E6; Fri, 27 May 2011 13:03:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 27 May 2011 13:03:06 +0200 From: "Elwell, John" To: Stephen Botzko Date: Fri, 27 May 2011 13:03:03 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcXEt6BXmXGbkKQBWMs3AbrgrNZwAAS3hQ Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 11:03:13 -0000 I thought requirement 10 would cover both (signalling/protocol capabilities= as well as user interface capabilities). John =20 > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 > Sent: 27 May 2011 11:53 > To: Elwell, John > Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat=20 > (pkyzivat); clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Do you think that the language in requirement 10 means "SIP=20 > capabilities"? Or something else? >=20 > I am thinking that issue is really about the=20 > signaling/protocol design itself, and isn't directly related=20 > to how many screens and cameras a system might have. >=20 > Stephen Botzko >=20 >=20 > On Fri, May 27, 2011 at 2:21 AM, Elwell, John=20 > wrote: >=20 >=20 > Allyn, > =09 > I already made a proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > =09 > John > =09 >=20 >=20 > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > =09 > > Sent: 26 May 2011 20:08 > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > Roni, Paul, John- > > Would you care to suggest the wording you would like=20 > to see as a > > requirement for legacy interoperability? That would=20 > be helpful. > > > > Thanks, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Roni Even > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > .... > > > > > > Anyhow we are discussing solution while my point is that we > > will need > > > as a > > > requirement to address the case of a call from a=20 > CLUE aware endpoint > > to > > > a > > > non CLUE aware endpoint. Even if the consensus will=20 > be to have the > > > preferred > > > video in the first video m-line. > > > > > > Regards > > > Roni > > > > > > > > > > > > > -----Original Message----- > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > Cc: clue@ietf.org > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > Paul, > > > > > > > > I would agree that if the offer-answer model=20 > semantic is that here > > > are > > > > several options and any subset of options is acceptable. > > > > > > > > However, if there is any grouping involved such=20 > that you need to > > have > > > a > > > > video and audio feed integrated to make sense=20 > then watch out. > > > > > > > > For example, I wouldn't want to end up with the=20 > result of a man's > > > video > > > > paired with a woman's voice. That could be=20 > rather comical. > > > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Paul Kyzivat (pkyzivat) > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > To: Roni Even > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > Paul, > > > > > I think we read it differently. > > > > > If the answerer does not support the group attribute > > and the offer > > > > had > > > > the > > > > > fid semantics it may look to the answerer as an=20 > offer with > > multiple > > > > m-lines > > > > > of the same media tyoe. In this case an implementation > > might also > > > > decide to > > > > > refuse the request (e.g., 488 Not Acceptable=20 > Here, or 606 Not > > > > Acceptable), > > > > > because it contains several "m" lines of the=20 > same media type. > > > > > > > > That is a slightly different story. > > > > > > > > Then the reason for rejection is not because it saw an > > attribute it > > > > didn't understand - its because it didn't like=20 > something it *did* > > > > understand. > > > > > > > > > This is very relevant to the multiple streams=20 > case and we should > > > look > > > > if we > > > > > state this behavior or we will look at providing an > > approach that > > > > will > > > > allow > > > > > the answerer to choose one m-line that the offerer > > prefers even of > > > it > > > > does > > > > > not understand CLUE. > > > > > > > > IMO (lets see if others differ), if a UA receives=20 > an offer with at > > > > least > > > > > > > > one m-line it is happy with, then it should not=20 > reject the call > > > because > > > > there are others that it does not "understand". > > > > > > > > Here "understand" means something different -=20 > presumably it does > > > > understand the direct meaning of the additional=20 > m-line, it just > > > doesn't > > > > understand the *significance* or use of it. > > > > > > > > I see little difference to getting to audio m-lines and > > only wanting > > > > one, and getting one audio and one video and only > > supporting audio. > > > In > > > > general you should not reject an audio/video call=20 > just because you > > > only > > > > support audio. > > > > > > > > I think it will behoove clue to strongly recommend that > > the m-lines > > > in > > > > an offer be arranged so the first ones are the=20 > ones it most wants > > > used > > > > if not all are. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Roni > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > >> To: Roni Even > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > >> Subject: Re: [clue] legacy support in requirements > > > > >> > > > > >> > > > > >> > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > >>> Paul, > > > > >>> Look at=20 > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > example > > > > >>> Roni > > > > >> > > > > >> OK, I looked. It is consistent with what I said. > > > > >> Either a=3Dgroup: is understood, or not. If not,=20 > its ignored, and > > > not > > > > put > > > > >> in the answer. Same with a=3Dmid: > > > > >> > > > > >> If a=3Dgroup: *is* understood, but some parameter within > > it is not, > > > > there > > > > >> are explicit rules for what to do. > > > > >> > > > > >> AFAICT there are no examples in this document=20 > where failure to > > > > >> understand an a-line in total (or even in=20 > part) results in > > > rejecting > > > > >> the > > > > >> offer. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>>> -----Original Message----- > > > > >>>> From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > >> Of > > > > >>>> Paul Kyzivat > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > >>>> To: Stephen Botzko > > > > >>>> Cc: clue@ietf.org > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > >>>> > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > >>>> > > > > >>>>> When the offer includes parameters that > > the answerer > > > > does > > > > >> not > > > > >>>>> understand > > > > >>>>> there are two options, he can=20 > ignore the unknown > > > > >> parameters > > > > >>>> or > > > > >>>>> reject > > > > >>>>> the offer. > > > > >>>>> Rejecting the offer in that case is=20 > not really kosher. > > > > >>>>> You are required to ignore parameters=20 > you do not > > > > understand. > > > > >>>>> > > > > >>>>> If you reject something because you=20 > don't like the > > > > parameters > > > > >> it > > > > >>>>> contains, then that is an implicit=20 > statement that you > > > > >> understand > > > > >>>>> those parameters well enough to=20 > decide to reject them. > > > > >>>>> > > > > >>>>> As far as I know, you are always free to reject > > offers, and it > > > > >>>> doesn't > > > > >>>>> really imply anything when you do that.. =20 > Whether it is wise > > is > > > > >>>> perhaps > > > > >>>>> a different question. > > > > >>>>> Stephen Botzko > > > > >>>> > > > > >>>> Certainly you are always free to reject an offer. > > > > >>>> In general I don't know for certain the reason why, > > and so if I > > > > give > > > > >>>> you > > > > >>>> the benefit of the doubt I will assume you have a > > valid reason > > - > > > > >>>> perhaps > > > > >>>> just policy. > > > > >>>> > > > > >>>> But if the reason you reject the offer is=20 > based on your > > > violating > > > > a > > > > >>>> spec, then you are non-conforming, whether I can > > determine you > > > are > > > > >>>> non-conforming or not. Whether being=20 > non-conforming is just > > > > un-wise, > > > > >> or > > > > >>>> something stronger, is a separate discussion. The > > IETF does not > > > > levy > > > > >>>> any > > > > >>>> penalties for violating its specs. But=20 > sometimes the market > > > does. > > > > >> (And > > > > >>>> sometimes not.) But we don't need to endorse=20 > non-conforming > > > > behavior > > > > >> in > > > > >>>> our documents. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Paul > > > > >>>> _______________________________________________ > > > > >>>> clue mailing list > > > > >>>> clue@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > >>> > > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 >=20 >=20 > = From stephen.botzko@gmail.com Fri May 27 04:16:02 2011 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 4DE28E06B6 for ; Fri, 27 May 2011 04:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 gs0UNYyWMu9R for ; Fri, 27 May 2011 04:16:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41767E0679 for ; Fri, 27 May 2011 04:16:00 -0700 (PDT) Received: by vxg33 with SMTP id 33so1585818vxg.31 for ; Fri, 27 May 2011 04:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ze7dsdSF2EeIzVvWcqddHFrUXIbbKFHYRBeLV8z6GXY=; b=ZNcpk+hgs8Dj10hFLMf8yBfiohuvKoIGizCsmjjHs5rXUViWoEc9N5xoSJipvX17PT xxZcsFbRlj9LQhqs3oh+gS6Xx2a8p68QvX6QfmOuqQCKRCWSXKRQQ388T6c9MxrQpm3c 6H0as5RLp1mWXX5IABW34Qpz4x4nYAUeM2tHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QPKPqfYXKgvhCqHCWvY0Y/yXPmYG1cCQ9sf13McrsDlmFBKepjRajAyZoXjGOUnkNx KzSsNqXy1kobTW62f8a1A5eNKoiKFlIN7+WAw5DhMQYALeCj3hvjec9MJVrbCzvZVzsn GLhhLXTLB68jqFiy0dxCC3O448leeR2qLwihc= MIME-Version: 1.0 Received: by 10.52.76.4 with SMTP id g4mr2947991vdw.40.1306494959553; Fri, 27 May 2011 04:15:59 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Fri, 27 May 2011 04:15:59 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> Date: Fri, 27 May 2011 07:15:59 -0400 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf3071cdaef70bdd04a4400fc1 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 11:16:02 -0000 --20cf3071cdaef70bdd04a4400fc1 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure that the language actually covers that (it seems ambiguous). What do you think about changing "endpoints with different capabilities" to "disparate devices"? Stephen On Fri, May 27, 2011 at 7:03 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > I thought requirement 10 would cover both (signalling/protocol capabilities > as well as user interface capabilities). > > John > > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: 27 May 2011 11:53 > > To: Elwell, John > > Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > > (pkyzivat); clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > Do you think that the language in requirement 10 means "SIP > > capabilities"? Or something else? > > > > I am thinking that issue is really about the > > signaling/protocol design itself, and isn't directly related > > to how many screens and cameras a system might have. > > > > Stephen Botzko > > > > > > On Fri, May 27, 2011 at 2:21 AM, Elwell, John > > wrote: > > > > > > Allyn, > > > > I already made a proposal: > > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > > > John > > > > > > > > > -----Original Message----- > > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > > > > Sent: 26 May 2011 20:08 > > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > Roni, Paul, John- > > > Would you care to suggest the wording you would like > > to see as a > > > requirement for legacy interoperability? That would > > be helpful. > > > > > > Thanks, > > > Allyn > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Roni Even > > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > .... > > > > > > > > Anyhow we are discussing solution while my point is that we > > > will need > > > > as a > > > > requirement to address the case of a call from a > > CLUE aware endpoint > > > to > > > > a > > > > non CLUE aware endpoint. Even if the consensus will > > be to have the > > > > preferred > > > > video in the first video m-line. > > > > > > > > Regards > > > > Roni > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > Paul, > > > > > > > > > > I would agree that if the offer-answer model > > semantic is that here > > > > are > > > > > several options and any subset of options is acceptable. > > > > > > > > > > However, if there is any grouping involved such > > that you need to > > > have > > > > a > > > > > video and audio feed integrated to make sense > > then watch out. > > > > > > > > > > For example, I wouldn't want to end up with the > > result of a man's > > > > video > > > > > paired with a woman's voice. That could be > > rather comical. > > > > > > > > > > Mike > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > Of > > > > > Paul Kyzivat (pkyzivat) > > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > > To: Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > > Paul, > > > > > > I think we read it differently. > > > > > > If the answerer does not support the group attribute > > > and the offer > > > > > had > > > > > the > > > > > > fid semantics it may look to the answerer as an > > offer with > > > multiple > > > > > m-lines > > > > > > of the same media tyoe. In this case an implementation > > > might also > > > > > decide to > > > > > > refuse the request (e.g., 488 Not Acceptable > > Here, or 606 Not > > > > > Acceptable), > > > > > > because it contains several "m" lines of the > > same media type. > > > > > > > > > > That is a slightly different story. > > > > > > > > > > Then the reason for rejection is not because it saw an > > > attribute it > > > > > didn't understand - its because it didn't like > > something it *did* > > > > > understand. > > > > > > > > > > > This is very relevant to the multiple streams > > case and we should > > > > look > > > > > if we > > > > > > state this behavior or we will look at providing an > > > approach that > > > > > will > > > > > allow > > > > > > the answerer to choose one m-line that the offerer > > > prefers even of > > > > it > > > > > does > > > > > > not understand CLUE. > > > > > > > > > > IMO (lets see if others differ), if a UA receives > > an offer with at > > > > > least > > > > > > > > > > one m-line it is happy with, then it should not > > reject the call > > > > because > > > > > there are others that it does not "understand". > > > > > > > > > > Here "understand" means something different - > > presumably it does > > > > > understand the direct meaning of the additional > > m-line, it just > > > > doesn't > > > > > understand the *significance* or use of it. > > > > > > > > > > I see little difference to getting to audio m-lines and > > > only wanting > > > > > one, and getting one audio and one video and only > > > supporting audio. > > > > In > > > > > general you should not reject an audio/video call > > just because you > > > > only > > > > > support audio. > > > > > > > > > > I think it will behoove clue to strongly recommend that > > > the m-lines > > > > in > > > > > an offer be arranged so the first ones are the > > ones it most wants > > > > used > > > > > if not all are. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > > Roni > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > > >> To: Roni Even > > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > > >> Subject: Re: [clue] legacy support in requirements > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > > >>> Paul, > > > > > >>> Look at > > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > > example > > > > > >>> Roni > > > > > >> > > > > > >> OK, I looked. It is consistent with what I said. > > > > > >> Either a=group: is understood, or not. If not, > > its ignored, and > > > > not > > > > > put > > > > > >> in the answer. Same with a=mid: > > > > > >> > > > > > >> If a=group: *is* understood, but some parameter within > > > it is not, > > > > > there > > > > > >> are explicit rules for what to do. > > > > > >> > > > > > >> AFAICT there are no examples in this document > > where failure to > > > > > >> understand an a-line in total (or even in > > part) results in > > > > rejecting > > > > > >> the > > > > > >> offer. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >>>> -----Original Message----- > > > > > >>>> From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On > > > > > Behalf > > > > > >> Of > > > > > >>>> Paul Kyzivat > > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > > >>>> To: Stephen Botzko > > > > > >>>> Cc: clue@ietf.org > > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > > >>>> > > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > > >>>> > > > > > >>>>> When the offer includes parameters that > > > the answerer > > > > > does > > > > > >> not > > > > > >>>>> understand > > > > > >>>>> there are two options, he can > > ignore the unknown > > > > > >> parameters > > > > > >>>> or > > > > > >>>>> reject > > > > > >>>>> the offer. > > > > > >>>>> Rejecting the offer in that case is > > not really kosher. > > > > > >>>>> You are required to ignore parameters > > you do not > > > > > understand. > > > > > >>>>> > > > > > >>>>> If you reject something because you > > don't like the > > > > > parameters > > > > > >> it > > > > > >>>>> contains, then that is an implicit > > statement that you > > > > > >> understand > > > > > >>>>> those parameters well enough to > > decide to reject them. > > > > > >>>>> > > > > > >>>>> As far as I know, you are always free to reject > > > offers, and it > > > > > >>>> doesn't > > > > > >>>>> really imply anything when you do that.. > > Whether it is wise > > > is > > > > > >>>> perhaps > > > > > >>>>> a different question. > > > > > >>>>> Stephen Botzko > > > > > >>>> > > > > > >>>> Certainly you are always free to reject an offer. > > > > > >>>> In general I don't know for certain the reason why, > > > and so if I > > > > > give > > > > > >>>> you > > > > > >>>> the benefit of the doubt I will assume you have a > > > valid reason > > > - > > > > > >>>> perhaps > > > > > >>>> just policy. > > > > > >>>> > > > > > >>>> But if the reason you reject the offer is > > based on your > > > > violating > > > > > a > > > > > >>>> spec, then you are non-conforming, whether I can > > > determine you > > > > are > > > > > >>>> non-conforming or not. Whether being > > non-conforming is just > > > > > un-wise, > > > > > >> or > > > > > >>>> something stronger, is a separate discussion. The > > > IETF does not > > > > > levy > > > > > >>>> any > > > > > >>>> penalties for violating its specs. But > > sometimes the market > > > > does. > > > > > >> (And > > > > > >>>> sometimes not.) But we don't need to endorse > > non-conforming > > > > > behavior > > > > > >> in > > > > > >>>> our documents. > > > > > >>>> > > > > > >>>> Thanks, > > > > > >>>> Paul > > > > > >>>> _______________________________________________ > > > > > >>>> clue mailing list > > > > > >>>> clue@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > clue mailing list > > > > > clue@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > --20cf3071cdaef70bdd04a4400fc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure that the language actually covers that (it seems ambiguous= ).

What do you think about changing "endpoints with different c= apabilities" to "disparate devices"?

Stephen


On Fri, May 27, 2011 at 7:03 AM, Elwell, Joh= n <john.elwell@siemens-enterprise.com> wrote:
I thought requirement 10 would cover both (signalling/protocol capabilities= as well as user interface capabilities).

John


> -----Original Message-----
> From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> Sent: 27 May 2011 11:53
> To: Elwell, John
> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat
> (pkyzivat); clue@ietf.org
> Subject: Re: [clue] legacy support i= n requirements
>
> Do you think that the language in requirement 10 means "SIP
> capabilities"? =A0Or something else?
>
> I am thinking that issue is really about the
> signaling/protocol design itself, and isn't directly related
> to how many screens and cameras a system might have.
>
> Stephen Botzko
>
>
> On Fri, May 27, 2011 at 2:21 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 Allyn,
>
> =A0 =A0 =A0 I already made a proposal:
> =A0 =A0 =A0 http://www.ietf.org/mail-archive/web/cl= ue/current/msg00221.html
>
> =A0 =A0 =A0 John
>
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
>
> =A0 =A0 =A0 > Sent: 26 May 2011 20:08
> =A0 =A0 =A0 > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John<= br> > =A0 =A0 =A0 > Cc: clue@ietf.org
> =A0 =A0 =A0 > Subject: RE: [clue] legacy support in requirements > =A0 =A0 =A0 >
> =A0 =A0 =A0 > Roni, Paul, John-
> =A0 =A0 =A0 > Would you care to suggest the wording you would like<= br> > to see as a
> =A0 =A0 =A0 > requirement for legacy interoperability? That would > be helpful.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Thanks,
> =A0 =A0 =A0 > Allyn
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > > -----Original Message-----
> =A0 =A0 =A0 > > From: c= lue-bounces@ietf.org
> [mailto:clue-bounces@ietf.org= ] On Behalf
> =A0 =A0 =A0 > Of
> =A0 =A0 =A0 > > Roni Even
> =A0 =A0 =A0 > > Sent: Wednesday, May 18, 2011 11:13 AM
> =A0 =A0 =A0 > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)<= br> > =A0 =A0 =A0 > > Cc: clue@ietf.o= rg
> =A0 =A0 =A0 > > Subject: Re: [clue] legacy support in requiremen= ts
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > ....
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Anyhow we are discussing solution while my point= is that we
> =A0 =A0 =A0 > will need
> =A0 =A0 =A0 > > as a
> =A0 =A0 =A0 > > requirement to address the case of a call from a=
> CLUE aware endpoint
> =A0 =A0 =A0 > to
> =A0 =A0 =A0 > > a
> =A0 =A0 =A0 > > non CLUE aware endpoint. Even if the consensus w= ill
> be to have the
> =A0 =A0 =A0 > > preferred
> =A0 =A0 =A0 > > video in the first video m-line.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Regards
> =A0 =A0 =A0 > > Roni
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > > -----Original Message-----
> =A0 =A0 =A0 > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com]
> =A0 =A0 =A0 > > > Sent: Wednesday, May 18, 2011 4:41 PM
> =A0 =A0 =A0 > > > To: Paul Kyzivat (pkyzivat); Roni Even
> =A0 =A0 =A0 > > > Cc: clue@i= etf.org
> =A0 =A0 =A0 > > > Subject: RE: [clue] legacy support in requi= rements
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > Paul,
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > I would agree that if the offer-answer mode= l
> semantic is that here
> =A0 =A0 =A0 > > are
> =A0 =A0 =A0 > > > several options and any subset of options i= s acceptable.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > However, if there is any grouping involved = such
> that you need to
> =A0 =A0 =A0 > have
> =A0 =A0 =A0 > > a
> =A0 =A0 =A0 > > > video and audio feed integrated to make sen= se
> then watch out.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > For example, I wouldn't want to end up = with the
> result of a man's
> =A0 =A0 =A0 > > video
> =A0 =A0 =A0 > > > paired with a woman's voice. =A0That co= uld be
> rather comical.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > Mike
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > -----Original Message-----
> =A0 =A0 =A0 > > > From: clue-bounces@ietf.org
> =A0 =A0 =A0 > [mailto:clue= -bounces@ietf.org] On Behalf
> =A0 =A0 =A0 > > Of
> =A0 =A0 =A0 > > > Paul Kyzivat (pkyzivat)
> =A0 =A0 =A0 > > > Sent: Tuesday, May 17, 2011 7:45 PM
> =A0 =A0 =A0 > > > To: Roni Even
> =A0 =A0 =A0 > > > Cc: clue@i= etf.org
> =A0 =A0 =A0 > > > Subject: Re: [clue] legacy support in requi= rements
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > On 5/17/2011 6:05 PM, Roni Even wrote:
> =A0 =A0 =A0 > > > > Paul,
> =A0 =A0 =A0 > > > > I think we read it differently.
> =A0 =A0 =A0 > > > > If the answerer does not support the g= roup attribute
> =A0 =A0 =A0 > and the offer
> =A0 =A0 =A0 > > > had
> =A0 =A0 =A0 > > > the
> =A0 =A0 =A0 > > > > fid semantics it may look to the answe= rer as an
> offer with
> =A0 =A0 =A0 > multiple
> =A0 =A0 =A0 > > > m-lines
> =A0 =A0 =A0 > > > > of the same media tyoe. In this case a= n implementation
> =A0 =A0 =A0 > might also
> =A0 =A0 =A0 > > > decide to
> =A0 =A0 =A0 > > > > refuse the request (e.g., 488 Not Acce= ptable
> Here, or 606 Not
> =A0 =A0 =A0 > > > Acceptable),
> =A0 =A0 =A0 > > > > because it contains several "m&qu= ot; lines of the
> same media type.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > That is a slightly different story.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > Then the reason for rejection is not becaus= e it saw an
> =A0 =A0 =A0 > attribute it
> =A0 =A0 =A0 > > > didn't understand - its because it didn= 't like
> something it *did*
> =A0 =A0 =A0 > > > understand.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > > This is very relevant to the multiple = streams
> case and we should
> =A0 =A0 =A0 > > look
> =A0 =A0 =A0 > > > if we
> =A0 =A0 =A0 > > > > state this behavior or we will look at= providing an
> =A0 =A0 =A0 > approach that
> =A0 =A0 =A0 > > > will
> =A0 =A0 =A0 > > > allow
> =A0 =A0 =A0 > > > > the answerer to choose one m-line that= the offerer
> =A0 =A0 =A0 > prefers even of
> =A0 =A0 =A0 > > it
> =A0 =A0 =A0 > > > does
> =A0 =A0 =A0 > > > > not understand CLUE.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > IMO (lets see if others differ), if a UA re= ceives
> an offer with at
> =A0 =A0 =A0 > > > least
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > one m-line it is happy with, then it should= not
> reject the call
> =A0 =A0 =A0 > > because
> =A0 =A0 =A0 > > > there are others that it does not "und= erstand".
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > Here "understand" means something= different -
> presumably it does
> =A0 =A0 =A0 > > > understand the direct meaning of the additi= onal
> m-line, it just
> =A0 =A0 =A0 > > doesn't
> =A0 =A0 =A0 > > > understand the *significance* or use of it.=
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > I see little difference to getting to audio= m-lines and
> =A0 =A0 =A0 > only wanting
> =A0 =A0 =A0 > > > one, and getting one audio and one video an= d only
> =A0 =A0 =A0 > supporting audio.
> =A0 =A0 =A0 > > In
> =A0 =A0 =A0 > > > general you should not reject an audio/vide= o call
> just because you
> =A0 =A0 =A0 > > only
> =A0 =A0 =A0 > > > support audio.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > I think it will behoove clue to strongly re= commend that
> =A0 =A0 =A0 > the m-lines
> =A0 =A0 =A0 > > in
> =A0 =A0 =A0 > > > an offer be arranged so the first ones are = the
> ones it most wants
> =A0 =A0 =A0 > > used
> =A0 =A0 =A0 > > > if not all are.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > =A0 Thanks,
> =A0 =A0 =A0 > > > =A0 Paul
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > > Roni
> =A0 =A0 =A0 > > > >
> =A0 =A0 =A0 > > > >> -----Original Message-----
> =A0 =A0 =A0 > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> =A0 =A0 =A0 > > > >> Sent: Wednesday, May 18, 2011 12:3= 7 AM
> =A0 =A0 =A0 > > > >> To: Roni Even
> =A0 =A0 =A0 > > > >> Cc: 'Stephen Botzko'; clue@ietf.org
> =A0 =A0 =A0 > > > >> Subject: Re: [clue] legacy support= in requirements
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >> On 5/17/2011 5:20 PM, Roni Even wr= ote:
> =A0 =A0 =A0 > > > >>> Paul,
> =A0 =A0 =A0 > > > >>> Look at
> http://tools.ietf.org/html/rfc5888#section-9.4.2 for
> =A0 =A0 =A0 > > > example
> =A0 =A0 =A0 > > > >>> Roni
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >> OK, I looked. It is consistent wit= h what I said.
> =A0 =A0 =A0 > > > >> Either a=3Dgroup: is understood, o= r not. If not,
> its ignored, and
> =A0 =A0 =A0 > > not
> =A0 =A0 =A0 > > > put
> =A0 =A0 =A0 > > > >> in the answer. Same with a=3Dmid:<= br> > =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >> If a=3Dgroup: *is* understood, but= some parameter within
> =A0 =A0 =A0 > it is not,
> =A0 =A0 =A0 > > > there
> =A0 =A0 =A0 > > > >> are explicit rules for what to do.=
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >> AFAICT there are no examples in th= is document
> where failure to
> =A0 =A0 =A0 > > > >> understand an a-line in total (or = even in
> part) results in
> =A0 =A0 =A0 > > rejecting
> =A0 =A0 =A0 > > > >> the
> =A0 =A0 =A0 > > > >> offer.
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >> =A0 =A0 =A0 =A0Thanks,
> =A0 =A0 =A0 > > > >> =A0 =A0 =A0 =A0Paul
> =A0 =A0 =A0 > > > >>
> =A0 =A0 =A0 > > > >>>> -----Original Message-----=
> =A0 =A0 =A0 > > > >>>> From: clue-bounces@ietf.org
> [mailto:clue-bounces@ietf.org= ] On
> =A0 =A0 =A0 > > > Behalf
> =A0 =A0 =A0 > > > >> Of
> =A0 =A0 =A0 > > > >>>> Paul Kyzivat
> =A0 =A0 =A0 > > > >>>> Sent: Tuesday, May 17, 201= 1 6:11 PM
> =A0 =A0 =A0 > > > >>>> To: Stephen Botzko
> =A0 =A0 =A0 > > > >>>> Cc: clue@ietf.org
> =A0 =A0 =A0 > > > >>>> Subject: Re: [clue] legacy= support in requirements
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>> On 5/17/2011 10:34 AM, Ste= phen Botzko wrote:
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 On 5/17/20= 11 2:24 AM, Roni Even wrote:
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 =A0 =A0 Wh= en the offer includes parameters that
> =A0 =A0 =A0 > the answerer
> =A0 =A0 =A0 > > > does
> =A0 =A0 =A0 > > > >> not
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 =A0 =A0 un= derstand
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 =A0 =A0 th= ere are two options, he can
> ignore the unknown
> =A0 =A0 =A0 > > > >> parameters
> =A0 =A0 =A0 > > > >>>> or
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 =A0 =A0 re= ject
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 =A0 =A0 th= e offer.
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 Rejecting = the offer in that case is
> not really kosher.
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 You are re= quired to ignore parameters
> you do not
> =A0 =A0 =A0 > > > understand.
> =A0 =A0 =A0 > > > >>>>>
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 If you rej= ect something because you
> don't like the
> =A0 =A0 =A0 > > > parameters
> =A0 =A0 =A0 > > > >> it
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 contains, = then that is an implicit
> statement that you
> =A0 =A0 =A0 > > > >> understand
> =A0 =A0 =A0 > > > >>>>> =A0 =A0 =A0 those para= meters well enough to
> decide to reject them.
> =A0 =A0 =A0 > > > >>>>>
> =A0 =A0 =A0 > > > >>>>> As far as I know, you = are always free to reject
> =A0 =A0 =A0 > offers, and it
> =A0 =A0 =A0 > > > >>>> doesn't
> =A0 =A0 =A0 > > > >>>>> really imply anything = when you do that..
> Whether it is wise
> =A0 =A0 =A0 > is
> =A0 =A0 =A0 > > > >>>> perhaps
> =A0 =A0 =A0 > > > >>>>> a different question.<= br> > =A0 =A0 =A0 > > > >>>>> Stephen Botzko
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>> Certainly you are always f= ree to reject an offer.
> =A0 =A0 =A0 > > > >>>> In general I don't kno= w for certain the reason why,
> =A0 =A0 =A0 > and so if I
> =A0 =A0 =A0 > > > give
> =A0 =A0 =A0 > > > >>>> you
> =A0 =A0 =A0 > > > >>>> the benefit of the doubt I= will assume you have a
> =A0 =A0 =A0 > valid reason
> =A0 =A0 =A0 > -
> =A0 =A0 =A0 > > > >>>> perhaps
> =A0 =A0 =A0 > > > >>>> just policy.
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>> But if the reason you reje= ct the offer is
> based on your
> =A0 =A0 =A0 > > violating
> =A0 =A0 =A0 > > > a
> =A0 =A0 =A0 > > > >>>> spec, then you are non-con= forming, whether I can
> =A0 =A0 =A0 > determine you
> =A0 =A0 =A0 > > are
> =A0 =A0 =A0 > > > >>>> non-conforming or not. Whe= ther being
> non-conforming is just
> =A0 =A0 =A0 > > > un-wise,
> =A0 =A0 =A0 > > > >> or
> =A0 =A0 =A0 > > > >>>> something stronger, is a s= eparate discussion. The
> =A0 =A0 =A0 > IETF does not
> =A0 =A0 =A0 > > > levy
> =A0 =A0 =A0 > > > >>>> any
> =A0 =A0 =A0 > > > >>>> penalties for violating it= s specs. But
> sometimes the market
> =A0 =A0 =A0 > > does.
> =A0 =A0 =A0 > > > >> (And
> =A0 =A0 =A0 > > > >>>> sometimes not.) But we don= 't need to endorse
> non-conforming
> =A0 =A0 =A0 > > > behavior
> =A0 =A0 =A0 > > > >> in
> =A0 =A0 =A0 > > > >>>> our documents.
> =A0 =A0 =A0 > > > >>>>
> =A0 =A0 =A0 > > > >>>> =A0 =A0 =A0Thanks,
> =A0 =A0 =A0 > > > >>>> =A0 =A0 =A0Paul
> =A0 =A0 =A0 > > > >>>> __________________________= _____________________
> =A0 =A0 =A0 > > > >>>> clue mailing list
> =A0 =A0 =A0 > > > >>>> clue@ietf.org
> =A0 =A0 =A0 > > > >>>> https://www.ietf.org/mailman= /listinfo/clue
> =A0 =A0 =A0 > > > >>>
> =A0 =A0 =A0 > > > >>>
> =A0 =A0 =A0 > > > >
> =A0 =A0 =A0 > > > >
> =A0 =A0 =A0 > > > ___________________________________________= ____
> =A0 =A0 =A0 > > > clue mailing list
> =A0 =A0 =A0 > > > clue@ietf.= org
> =A0 =A0 =A0 > > > https://www.ietf.org/mailman/listinfo/clue
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > _______________________________________________<= br> > =A0 =A0 =A0 > > clue mailing list
> =A0 =A0 =A0 > > clue@ietf.org
> =A0 =A0 =A0 > > https://www.ietf.org/mailman/listinfo/clue
> =A0 =A0 =A0 >
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 clue mailing list
> =A0 =A0 =A0 clue@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue
>
>
>
>

--20cf3071cdaef70bdd04a4400fc1-- From espeberg@cisco.com Fri May 27 04:22:46 2011 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 52E04E0693 for ; Fri, 27 May 2011 04:22:46 -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 sh0k+0KZKxzP for ; Fri, 27 May 2011 04:22:44 -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 D280AE0662 for ; Fri, 27 May 2011 04:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=43481; q=dns/txt; s=iport; t=1306495363; x=1307704963; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=sPuiIYE/ghLRHHwG5PzOn8AC+KsoJYjMfMyDIO01tbU=; b=AOMKEj4+Qzm5Mq7qfx8Yld55K4stiLO2r+fepADm7tdQEY2fuLPTYnZs sPvkTIYzSuc8iRP8j1oPEVcIAHkT4AcDeiR3qL0pAFqsNHmtbEJ/dv/zo ZhULjw0OKU+zR3uoNYDj3v5dEWCY1ovIK0omssV9KlsiVLPQ1KRlm6mLv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBALqI302Q/khR/2dsb2JhbAA2HoJSlRiGcodbd4hwnWGQJY1Chh4ElQeEHoY1 X-IronPort-AV: E=Sophos;i="4.65,279,1304294400"; d="scan'208,217";a="32598005" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 27 May 2011 11:22:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4RBMfip030326; Fri, 27 May 2011 11:22:41 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 13:22:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1C60.6452CE9E" Date: Fri, 27 May 2011 13:22:40 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcX4yd02c+yM3SQySHzmadUuPjGgAAAxaw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> From: "Espen Berger (espeberg)" To: "Stephen Botzko" , "Elwell, John" X-OriginalArrivalTime: 27 May 2011 11:22:41.0452 (UTC) FILETIME=[6471CEC0:01CC1C60] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 11:22:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1C60.6452CE9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it would be clearer to formulate two different requirements=20 =20 1) Two solution must provide a mechanism that make it possible for endpoints with different capabilities to interoperate, e.g. interoperability between a 2 camera/screens and 3 camera/screens endpoint. 2) Two solution must provide a mechanism that make it possible for endpoints that are CLUE aware to interoperate with CLUE-less endpoints.=20 =20 Cheers=20 =20 -Espen=20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 27. mai 2011 13:16 To: Elwell, John Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements =20 I'm not sure that the language actually covers that (it seems ambiguous). What do you think about changing "endpoints with different capabilities" to "disparate devices"? Stephen On Fri, May 27, 2011 at 7:03 AM, Elwell, John wrote: I thought requirement 10 would cover both (signalling/protocol capabilities as well as user interface capabilities). John > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: 27 May 2011 11:53 > To: Elwell, John > Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > (pkyzivat); clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > Do you think that the language in requirement 10 means "SIP > capabilities"? Or something else? > > I am thinking that issue is really about the > signaling/protocol design itself, and isn't directly related > to how many screens and cameras a system might have. > > Stephen Botzko > > > On Fri, May 27, 2011 at 2:21 AM, Elwell, John > wrote: > > > Allyn, > > I already made a proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > John > > > > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > > Sent: 26 May 2011 20:08 > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > Roni, Paul, John- > > Would you care to suggest the wording you would like > to see as a > > requirement for legacy interoperability? That would > be helpful. > > > > Thanks, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Roni Even > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > .... > > > > > > Anyhow we are discussing solution while my point is that we > > will need > > > as a > > > requirement to address the case of a call from a > CLUE aware endpoint > > to > > > a > > > non CLUE aware endpoint. Even if the consensus will > be to have the > > > preferred > > > video in the first video m-line. > > > > > > Regards > > > Roni > > > > > > > > > > > > > -----Original Message----- > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > Cc: clue@ietf.org > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > Paul, > > > > > > > > I would agree that if the offer-answer model > semantic is that here > > > are > > > > several options and any subset of options is acceptable. > > > > > > > > However, if there is any grouping involved such > that you need to > > have > > > a > > > > video and audio feed integrated to make sense > then watch out. > > > > > > > > For example, I wouldn't want to end up with the > result of a man's > > > video > > > > paired with a woman's voice. That could be > rather comical. > > > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Paul Kyzivat (pkyzivat) > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > To: Roni Even > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > Paul, > > > > > I think we read it differently. > > > > > If the answerer does not support the group attribute > > and the offer > > > > had > > > > the > > > > > fid semantics it may look to the answerer as an > offer with > > multiple > > > > m-lines > > > > > of the same media tyoe. In this case an implementation > > might also > > > > decide to > > > > > refuse the request (e.g., 488 Not Acceptable > Here, or 606 Not > > > > Acceptable), > > > > > because it contains several "m" lines of the > same media type. > > > > > > > > That is a slightly different story. > > > > > > > > Then the reason for rejection is not because it saw an > > attribute it > > > > didn't understand - its because it didn't like > something it *did* > > > > understand. > > > > > > > > > This is very relevant to the multiple streams > case and we should > > > look > > > > if we > > > > > state this behavior or we will look at providing an > > approach that > > > > will > > > > allow > > > > > the answerer to choose one m-line that the offerer > > prefers even of > > > it > > > > does > > > > > not understand CLUE. > > > > > > > > IMO (lets see if others differ), if a UA receives > an offer with at > > > > least > > > > > > > > one m-line it is happy with, then it should not > reject the call > > > because > > > > there are others that it does not "understand". > > > > > > > > Here "understand" means something different - > presumably it does > > > > understand the direct meaning of the additional > m-line, it just > > > doesn't > > > > understand the *significance* or use of it. > > > > > > > > I see little difference to getting to audio m-lines and > > only wanting > > > > one, and getting one audio and one video and only > > supporting audio. > > > In > > > > general you should not reject an audio/video call > just because you > > > only > > > > support audio. > > > > > > > > I think it will behoove clue to strongly recommend that > > the m-lines > > > in > > > > an offer be arranged so the first ones are the > ones it most wants > > > used > > > > if not all are. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Roni > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > >> To: Roni Even > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > >> Subject: Re: [clue] legacy support in requirements > > > > >> > > > > >> > > > > >> > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > >>> Paul, > > > > >>> Look at > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > example > > > > >>> Roni > > > > >> > > > > >> OK, I looked. It is consistent with what I said. > > > > >> Either a=3Dgroup: is understood, or not. If not, > its ignored, and > > > not > > > > put > > > > >> in the answer. Same with a=3Dmid: > > > > >> > > > > >> If a=3Dgroup: *is* understood, but some parameter = within > > it is not, > > > > there > > > > >> are explicit rules for what to do. > > > > >> > > > > >> AFAICT there are no examples in this document > where failure to > > > > >> understand an a-line in total (or even in > part) results in > > > rejecting > > > > >> the > > > > >> offer. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>>> -----Original Message----- > > > > >>>> From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > >> Of > > > > >>>> Paul Kyzivat > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > >>>> To: Stephen Botzko > > > > >>>> Cc: clue@ietf.org > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > >>>> > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > >>>> > > > > >>>>> When the offer includes parameters that > > the answerer > > > > does > > > > >> not > > > > >>>>> understand > > > > >>>>> there are two options, he can > ignore the unknown > > > > >> parameters > > > > >>>> or > > > > >>>>> reject > > > > >>>>> the offer. > > > > >>>>> Rejecting the offer in that case is > not really kosher. > > > > >>>>> You are required to ignore parameters > you do not > > > > understand. > > > > >>>>> > > > > >>>>> If you reject something because you > don't like the > > > > parameters > > > > >> it > > > > >>>>> contains, then that is an implicit > statement that you > > > > >> understand > > > > >>>>> those parameters well enough to > decide to reject them. > > > > >>>>> > > > > >>>>> As far as I know, you are always free to reject > > offers, and it > > > > >>>> doesn't > > > > >>>>> really imply anything when you do that.. > Whether it is wise > > is > > > > >>>> perhaps > > > > >>>>> a different question. > > > > >>>>> Stephen Botzko > > > > >>>> > > > > >>>> Certainly you are always free to reject an offer. > > > > >>>> In general I don't know for certain the reason why, > > and so if I > > > > give > > > > >>>> you > > > > >>>> the benefit of the doubt I will assume you have a > > valid reason > > - > > > > >>>> perhaps > > > > >>>> just policy. > > > > >>>> > > > > >>>> But if the reason you reject the offer is > based on your > > > violating > > > > a > > > > >>>> spec, then you are non-conforming, whether I can > > determine you > > > are > > > > >>>> non-conforming or not. Whether being > non-conforming is just > > > > un-wise, > > > > >> or > > > > >>>> something stronger, is a separate discussion. The > > IETF does not > > > > levy > > > > >>>> any > > > > >>>> penalties for violating its specs. But > sometimes the market > > > does. > > > > >> (And > > > > >>>> sometimes not.) But we don't need to endorse > non-conforming > > > > behavior > > > > >> in > > > > >>>> our documents. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Paul > > > > >>>> _______________________________________________ > > > > >>>> clue mailing list > > > > >>>> clue@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > >>> > > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > >=20 =20 ------_=_NextPart_001_01CC1C60.6452CE9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it would be clearer to formulate two different requirements =

 

1)      = Two solution must provide a mechanism that make it possible for = endpoints with different capabilities to interoperate, e.g. = interoperability between a 2 camera/screens and 3 camera/screens = endpoint.

2)      = Two solution must provide a mechanism that make it possible for = endpoints that are CLUE aware to interoperate with CLUE-less endpoints. =

 

Cheers

 

-Espen

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 27. mai 2011 13:16
To: = Elwell, John
Cc: clue@ietf.org
Subject: Re: [clue] = legacy support in requirements

 

I'm not sure that the = language actually covers that (it seems ambiguous).

What do you = think about changing "endpoints with different capabilities" = to "disparate = devices"?

Stephen

On Fri, May 27, 2011 at 7:03 AM, Elwell, John <john.elwell@siemens-en= terprise.com> wrote:

I thought = requirement 10 would cover both (signalling/protocol capabilities as = well as user interface capabilities).

John



> -----Original Message-----
> From: = Stephen Botzko [mailto:stephen.botzko@gmail.com]

> Sent: 27 May 2011 = 11:53
> To: Elwell, John
> Cc: Allyn Romanow (allyn); Roni = Even; Paul Kyzivat
> (pkyzivat); clue@ietf.org

<= p class=3DMsoNormal>> Subject: Re: [clue] legacy support in = requirements
>
> Do you think that the language in = requirement 10 means "SIP
> capabilities"?  Or = something else?
>
> I am thinking that issue is really about = the
> signaling/protocol design itself, and isn't directly = related
> to how many screens and cameras a system might = have.
>
> Stephen Botzko
>
>
> On Fri, May = 27, 2011 at 2:21 AM, Elwell, John
> <john.elwell@siemens-en= terprise.com> wrote:
>
>
>       = Allyn,
>
>       I already made a = proposal:
>       http://www.ietf.org/mail-archive/web/clue/current/msg00= 221.html
>
>       = John
>
>
>
>       > = -----Original Message-----
>       > From: Allyn = Romanow (allyn) [mailto:allyn@cisco.com]
>
> =       > Sent: 26 May 2011 20:08
>     =   > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John
> =       > Cc: clue@ietf.org
>     =   > Subject: RE: [clue] legacy support in requirements
> =       >
>       > Roni, Paul, = John-
>       > Would you care to suggest the = wording you would like
> to see as a
>       = > requirement for legacy interoperability? That would
> be = helpful.
>       >
>       = > Thanks,
>       > Allyn
>   =     >
>       > > -----Original = Message-----
>       > > From: clue-bounces@ietf.org
> = [mailto:clue-bounces@ietf.org] On = Behalf
>       > Of
>       = > > Roni Even
>       > > Sent: = Wednesday, May 18, 2011 11:13 AM
>       > > = To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)
>     =   > > Cc: clue@ietf.org
>     =   > > Subject: Re: [clue] legacy support in = requirements
>       > >
>   =     > ....
>       > >
> =       > > Anyhow we are discussing solution while = my point is that we
>       > will need
> =       > > as a
>       > = > requirement to address the case of a call from a
> CLUE aware = endpoint
>       > to
>     =   > > a
>       > > non CLUE aware = endpoint. Even if the consensus will
> be to have the
> =       > > preferred
>       = > > video in the first video m-line.
>       = > >
>       > > Regards
>   =     > > Roni
>       > = >
>       > >
>       = > >
>       > > > -----Original = Message-----
>       > > > From: Mike = Hammer (hmmr) [mailto:hmmr@cisco.com]
>     =   > > > Sent: Wednesday, May 18, 2011 4:41 PM
> =       > > > To: Paul Kyzivat (pkyzivat); Roni = Even
>       > > > Cc: clue@ietf.org
>     =   > > > Subject: RE: [clue] legacy support in = requirements
>       > > >
>   =     > > > Paul,
>       > = > >
>       > > > I would agree that = if the offer-answer model
> semantic is that here
>   =     > > are
>       > > > = several options and any subset of options is acceptable.
>   =     > > >
>       > > > = However, if there is any grouping involved such
> that you need = to
>       > have
>       = > > a
>       > > > video and audio = feed integrated to make sense
> then watch out.
>   =     > > >
>       > > > = For example, I wouldn't want to end up with the
> result of a = man's
>       > > video
>     =   > > > paired with a woman's voice.  That could = be
> rather comical.
>       > > = >
>       > > > Mike
>   =     > > >
>       > > = >
>       > > > -----Original = Message-----
>       > > > From: clue-bounces@ietf.org
> =       > [mailto:clue-bounces@ietf.org] On = Behalf
>       > > Of
>     =   > > > Paul Kyzivat (pkyzivat)
>     =   > > > Sent: Tuesday, May 17, 2011 7:45 PM
>   =     > > > To: Roni Even
>       = > > > Cc: clue@ietf.org
>     =   > > > Subject: Re: [clue] legacy support in = requirements
>       > > >
>   =     > > >
>       > > = >
>       > > > On 5/17/2011 6:05 PM, = Roni Even wrote:
>       > > > > = Paul,
>       > > > > I think we read = it differently.
>       > > > > If the = answerer does not support the group attribute
>     =   > and the offer
>       > > > = had
>       > > > the
>   =     > > > > fid semantics it may look to the = answerer as an
> offer with
>       > = multiple
>       > > > m-lines
> =       > > > > of the same media tyoe. In this = case an implementation
>       > might = also
>       > > > decide to
> =       > > > > refuse the request (e.g., 488 = Not Acceptable
> Here, or 606 Not
>       = > > > Acceptable),
>       > > > = > because it contains several "m" lines of the
> same = media type.
>       > > >
>   =     > > > That is a slightly different story.
> =       > > >
>       > = > > Then the reason for rejection is not because it saw an
> =       > attribute it
>       > = > > didn't understand - its because it didn't like
> = something it *did*
>       > > > = understand.
>       > > >
>   =     > > > > This is very relevant to the multiple = streams
> case and we should
>       > = > look
>       > > > if we
> =       > > > > state this behavior or we will = look at providing an
>       > approach = that
>       > > > will
>   =     > > > allow
>       > = > > > the answerer to choose one m-line that the = offerer
>       > prefers even of
>   =     > > it
>       > > > = does
>       > > > > not understand = CLUE.
>       > > >
>     =   > > > IMO (lets see if others differ), if a UA = receives
> an offer with at
>       > > = > least
>       > > >
>   =     > > > one m-line it is happy with, then it should = not
> reject the call
>       > > = because
>       > > > there are others = that it does not "understand".
>       = > > >
>       > > > Here = "understand" means something different -
> presumably it = does
>       > > > understand the direct = meaning of the additional
> m-line, it just
>     =   > > doesn't
>       > > > = understand the *significance* or use of it.
>       = > > >
>       > > > I see little = difference to getting to audio m-lines and
>       = > only wanting
>       > > > one, and = getting one audio and one video and only
>       = > supporting audio.
>       > > In
> =       > > > general you should not reject an = audio/video call
> just because you
>       = > > only
>       > > > support = audio.
>       > > >
>     =   > > > I think it will behoove clue to strongly recommend = that
>       > the m-lines
>     =   > > in
>       > > > an offer = be arranged so the first ones are the
> ones it most wants
> =       > > used
>       > = > > if not all are.
>       > > = >
>       > > >   Thanks,
> =       > > >   Paul
>     =   > > >
>       > > > > = Roni
>       > > > >
>   =     > > > >> -----Original Message-----
> =       > > > >> From: Paul Kyzivat = [mailto:pkyzivat@cisco.com]
> =       > > > >> Sent: Wednesday, May 18, = 2011 12:37 AM
>       > > > >> To: = Roni Even
>       > > > >> Cc: = 'Stephen Botzko'; clue@ietf.org
>     =   > > > >> Subject: Re: [clue] legacy support in = requirements
>       > > > = >>
>       > > > >>
> =       > > > >>
>     =   > > > >> On 5/17/2011 5:20 PM, Roni Even = wrote:
>       > > > >>> = Paul,
>       > > > >>> Look = at
> http://tools.ietf.org/html/rfc5888#section-9.4.2 = for
>       > > > example
>   =     > > > >>> Roni
>     =   > > > >>
>       > > = > >> OK, I looked. It is consistent with what I said.
> =       > > > >> Either a=3Dgroup: is = understood, or not. If not,
> its ignored, and
>   =     > > not
>       > > > = put
>       > > > >> in the answer. = Same with a=3Dmid:
>       > > > = >>
>       > > > >> If = a=3Dgroup: *is* understood, but some parameter within
>   =     > it is not,
>       > > = > there
>       > > > >> are = explicit rules for what to do.
>       > > = > >>
>       > > > >> = AFAICT there are no examples in this document
> where failure = to
>       > > > >> understand an = a-line in total (or even in
> part) results in
>   =     > > rejecting
>       > > = > >> the
>       > > > >> = offer.
>       > > > >>
> =       > > > >>       =  Thanks,
>       > > > >> =        Paul
>       > > = > >>
>       > > > = >>>> -----Original Message-----
>       = > > > >>>> From: clue-bounces@ietf.org
> = [mailto:clue-bounces@ietf.org] = On
>       > > > Behalf
>   =     > > > >> Of
>       = > > > >>>> Paul Kyzivat
>     =   > > > >>>> Sent: Tuesday, May 17, 2011 6:11 = PM
>       > > > >>>> To: = Stephen Botzko
>       > > > = >>>> Cc: clue@ietf.org
>     =   > > > >>>> Subject: Re: [clue] legacy = support in requirements
>       > > > = >>>>
>       > > > = >>>>
>       > > > = >>>>
>       > > > = >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote:
> =       > > > >>>>
>   =     > > > >>>>>       = On 5/17/2011 2:24 AM, Roni Even wrote:
>       > = > > >>>>
>       > > > = >>>>>           When the offer = includes parameters that
>       > the = answerer
>       > > > does
>   =     > > > >> not
>       = > > > >>>>>           = understand
>       > > > = >>>>>           there are two = options, he can
> ignore the unknown
>       = > > > >> parameters
>       > = > > >>>> or
>       > > = > >>>>>           = reject
>       > > > >>>>> =           the offer.
>     =   > > > >>>>>       = Rejecting the offer in that case is
> not really kosher.
> =       > > > >>>>>     =   You are required to ignore parameters
> you do not
> =       > > > understand.
>     =   > > > >>>>>
>       = > > > >>>>>       If you reject = something because you
> don't like the
>     =   > > > parameters
>       > > = > >> it
>       > > > = >>>>>       contains, then that is an = implicit
> statement that you
>       > = > > >> understand
>       > > = > >>>>>       those parameters well = enough to
> decide to reject them.
>       = > > > >>>>>
>       > = > > >>>>> As far as I know, you are always free to = reject
>       > offers, and it
>   =     > > > >>>> doesn't
>   =     > > > >>>>> really imply anything = when you do that..
> Whether it is wise
>     =   > is
>       > > > = >>>> perhaps
>       > > > = >>>>> a different question.
>       = > > > >>>>> Stephen Botzko
>     =   > > > >>>>
>       > = > > >>>> Certainly you are always free to reject an = offer.
>       > > > >>>> In = general I don't know for certain the reason why,
>     =   > and so if I
>       > > > = give
>       > > > >>>> = you
>       > > > >>>> the = benefit of the doubt I will assume you have a
>     =   > valid reason
>       > -
> =       > > > >>>> perhaps
> =       > > > >>>> just = policy.
>       > > > = >>>>
>       > > > = >>>> But if the reason you reject the offer is
> based = on your
>       > > violating
>   =     > > > a
>       > > = > >>>> spec, then you are non-conforming, whether I = can
>       > determine you
>   =     > > are
>       > > > = >>>> non-conforming or not. Whether being
> = non-conforming is just
>       > > > = un-wise,
>       > > > >> or
> =       > > > >>>> something stronger, = is a separate discussion. The
>       > IETF = does not
>       > > > levy
>   =     > > > >>>> any
>     =   > > > >>>> penalties for violating its = specs. But
> sometimes the market
>       = > > does.
>       > > > >> = (And
>       > > > >>>> = sometimes not.) But we don't need to endorse
> = non-conforming
>       > > > = behavior
>       > > > >> in
> =       > > > >>>> our = documents.
>       > > > = >>>>
>       > > > = >>>>      Thanks,
>     =   > > > >>>>      Paul
> =       > > > >>>> = _______________________________________________
>     =   > > > >>>> clue mailing list
>   =     > > > >>>> clue@ietf.org
>     =   > > > >>>> https://www.ietf.org/mailman/listinfo/clue
> =       > > > >>>
>     =   > > > >>>
>       > = > > >
>       > > > >
> =       > > > = _______________________________________________
>     =   > > > clue mailing list
>       = > > > clue@ietf.org
>     =   > > > https://www.ietf.org/mailman/listinfo/clue
> =       > >
>       > > = _______________________________________________
>     =   > > clue mailing list
>       > = > clue@ietf.org
>   =     > > https://www.ietf.org/mailman/listinfo/clue
> =       >
>       = _______________________________________________
>     =   clue mailing list
>       clue@ietf.org
>     =   https://www.ietf.org/mailman/listinfo/clue
><= br>>
>
>

 

------_=_NextPart_001_01CC1C60.6452CE9E-- From john.elwell@siemens-enterprise.com Fri May 27 05:28:21 2011 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 EB84EE07C0 for ; Fri, 27 May 2011 05:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Q3gIQ72OoFbU for ; Fri, 27 May 2011 05:28:20 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 24C42E0792 for ; Fri, 27 May 2011 05:28:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1306499297!36220588!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17058 invoked from network); 27 May 2011 12:28:17 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-21.messagelabs.com with SMTP; 27 May 2011 12:28:17 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B1C4123F03E2; Fri, 27 May 2011 14:28:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 27 May 2011 14:28:19 +0200 From: "Elwell, John" To: "Espen Berger (espeberg)" , Stephen Botzko Date: Fri, 27 May 2011 14:28:16 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcX4yd02c+yM3SQySHzmadUuPjGgAAAxawAAIz8LA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.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 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 12:28:22 -0000 I can live with Steve's proposal. I also don't mind separating the requirem= ents, but I don't think we should refer to CLUE in the requirement - the RF= C will live a long time after CLUE is finished and closed down. So if we wa= nt to separate the requirements, I would propose: REQMT-10: The solution MUST include a mechanism that makes it possible for= endpoints with different capabilities to interoperate in a telepresence co= nference. REQMT-10bis: The solution MUST include a mechanism that makes it possible = for endpoints without support for telepresence extensions to participate in= a telepresence conference with those that do. John > -----Original Message----- > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > Sent: 27 May 2011 12:23 > To: Stephen Botzko; Elwell, John > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > I think it would be clearer to formulate two different requirements > > > > 1) Two solution must provide a mechanism that make it > possible for endpoints with different capabilities to > interoperate, e.g. interoperability between a 2 > camera/screens and 3 camera/screens endpoint. > > 2) Two solution must provide a mechanism that make it > possible for endpoints that are CLUE aware to interoperate > with CLUE-less endpoints. > > > > Cheers > > > > -Espen > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Stephen Botzko > Sent: 27. mai 2011 13:16 > To: Elwell, John > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > I'm not sure that the language actually covers that (it seems > ambiguous). > > What do you think about changing "endpoints with different > capabilities" to "disparate devices"? > > Stephen > > > > On Fri, May 27, 2011 at 7:03 AM, Elwell, John > wrote: > > I thought requirement 10 would cover both > (signalling/protocol capabilities as well as user interface > capabilities). > > John > > > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: 27 May 2011 11:53 > > To: Elwell, John > > Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > > (pkyzivat); clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > Do you think that the language in requirement 10 means "SIP > > capabilities"? Or something else? > > > > I am thinking that issue is really about the > > signaling/protocol design itself, and isn't directly related > > to how many screens and cameras a system might have. > > > > Stephen Botzko > > > > > > On Fri, May 27, 2011 at 2:21 AM, Elwell, John > > wrote: > > > > > > Allyn, > > > > I already made a proposal: > > > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > > > John > > > > > > > > > -----Original Message----- > > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > > > > Sent: 26 May 2011 20:08 > > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > Roni, Paul, John- > > > Would you care to suggest the wording you would like > > to see as a > > > requirement for legacy interoperability? That would > > be helpful. > > > > > > Thanks, > > > Allyn > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Roni Even > > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > .... > > > > > > > > Anyhow we are discussing solution while my point > is that we > > > will need > > > > as a > > > > requirement to address the case of a call from a > > CLUE aware endpoint > > > to > > > > a > > > > non CLUE aware endpoint. Even if the consensus will > > be to have the > > > > preferred > > > > video in the first video m-line. > > > > > > > > Regards > > > > Roni > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > Paul, > > > > > > > > > > I would agree that if the offer-answer model > > semantic is that here > > > > are > > > > > several options and any subset of options is acceptable. > > > > > > > > > > However, if there is any grouping involved such > > that you need to > > > have > > > > a > > > > > video and audio feed integrated to make sense > > then watch out. > > > > > > > > > > For example, I wouldn't want to end up with the > > result of a man's > > > > video > > > > > paired with a woman's voice. That could be > > rather comical. > > > > > > > > > > Mike > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > Of > > > > > Paul Kyzivat (pkyzivat) > > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > > To: Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > > Paul, > > > > > > I think we read it differently. > > > > > > If the answerer does not support the group attribute > > > and the offer > > > > > had > > > > > the > > > > > > fid semantics it may look to the answerer as an > > offer with > > > multiple > > > > > m-lines > > > > > > of the same media tyoe. In this case an implementation > > > might also > > > > > decide to > > > > > > refuse the request (e.g., 488 Not Acceptable > > Here, or 606 Not > > > > > Acceptable), > > > > > > because it contains several "m" lines of the > > same media type. > > > > > > > > > > That is a slightly different story. > > > > > > > > > > Then the reason for rejection is not because it saw an > > > attribute it > > > > > didn't understand - its because it didn't like > > something it *did* > > > > > understand. > > > > > > > > > > > This is very relevant to the multiple streams > > case and we should > > > > look > > > > > if we > > > > > > state this behavior or we will look at providing an > > > approach that > > > > > will > > > > > allow > > > > > > the answerer to choose one m-line that the offerer > > > prefers even of > > > > it > > > > > does > > > > > > not understand CLUE. > > > > > > > > > > IMO (lets see if others differ), if a UA receives > > an offer with at > > > > > least > > > > > > > > > > one m-line it is happy with, then it should not > > reject the call > > > > because > > > > > there are others that it does not "understand". > > > > > > > > > > Here "understand" means something different - > > presumably it does > > > > > understand the direct meaning of the additional > > m-line, it just > > > > doesn't > > > > > understand the *significance* or use of it. > > > > > > > > > > I see little difference to getting to audio m-lines and > > > only wanting > > > > > one, and getting one audio and one video and only > > > supporting audio. > > > > In > > > > > general you should not reject an audio/video call > > just because you > > > > only > > > > > support audio. > > > > > > > > > > I think it will behoove clue to strongly recommend that > > > the m-lines > > > > in > > > > > an offer be arranged so the first ones are the > > ones it most wants > > > > used > > > > > if not all are. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > > Roni > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > > >> To: Roni Even > > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > > >> Subject: Re: [clue] legacy support in requirements > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > > >>> Paul, > > > > > >>> Look at > > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > > example > > > > > >>> Roni > > > > > >> > > > > > >> OK, I looked. It is consistent with what I said. > > > > > >> Either a=3Dgroup: is understood, or not. If not, > > its ignored, and > > > > not > > > > > put > > > > > >> in the answer. Same with a=3Dmid: > > > > > >> > > > > > >> If a=3Dgroup: *is* understood, but some > parameter within > > > it is not, > > > > > there > > > > > >> are explicit rules for what to do. > > > > > >> > > > > > >> AFAICT there are no examples in this document > > where failure to > > > > > >> understand an a-line in total (or even in > > part) results in > > > > rejecting > > > > > >> the > > > > > >> offer. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >>>> -----Original Message----- > > > > > >>>> From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On > > > > > Behalf > > > > > >> Of > > > > > >>>> Paul Kyzivat > > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > > >>>> To: Stephen Botzko > > > > > >>>> Cc: clue@ietf.org > > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > > >>>> > > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > > >>>> > > > > > >>>>> When the offer includes parameters that > > > the answerer > > > > > does > > > > > >> not > > > > > >>>>> understand > > > > > >>>>> there are two options, he can > > ignore the unknown > > > > > >> parameters > > > > > >>>> or > > > > > >>>>> reject > > > > > >>>>> the offer. > > > > > >>>>> Rejecting the offer in that case is > > not really kosher. > > > > > >>>>> You are required to ignore parameters > > you do not > > > > > understand. > > > > > >>>>> > > > > > >>>>> If you reject something because you > > don't like the > > > > > parameters > > > > > >> it > > > > > >>>>> contains, then that is an implicit > > statement that you > > > > > >> understand > > > > > >>>>> those parameters well enough to > > decide to reject them. > > > > > >>>>> > > > > > >>>>> As far as I know, you are always free to reject > > > offers, and it > > > > > >>>> doesn't > > > > > >>>>> really imply anything when you do that.. > > Whether it is wise > > > is > > > > > >>>> perhaps > > > > > >>>>> a different question. > > > > > >>>>> Stephen Botzko > > > > > >>>> > > > > > >>>> Certainly you are always free to reject an offer. > > > > > >>>> In general I don't know for certain the reason why, > > > and so if I > > > > > give > > > > > >>>> you > > > > > >>>> the benefit of the doubt I will assume you have a > > > valid reason > > > - > > > > > >>>> perhaps > > > > > >>>> just policy. > > > > > >>>> > > > > > >>>> But if the reason you reject the offer is > > based on your > > > > violating > > > > > a > > > > > >>>> spec, then you are non-conforming, whether I can > > > determine you > > > > are > > > > > >>>> non-conforming or not. Whether being > > non-conforming is just > > > > > un-wise, > > > > > >> or > > > > > >>>> something stronger, is a separate discussion. The > > > IETF does not > > > > > levy > > > > > >>>> any > > > > > >>>> penalties for violating its specs. But > > sometimes the market > > > > does. > > > > > >> (And > > > > > >>>> sometimes not.) But we don't need to endorse > > non-conforming > > > > > behavior > > > > > >> in > > > > > >>>> our documents. > > > > > >>>> > > > > > >>>> Thanks, > > > > > >>>> Paul > > > > > >>>> _______________________________________________ > > > > > >>>> clue mailing list > > > > > >>>> clue@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > clue mailing list > > > > > clue@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > From pkyzivat@cisco.com Fri May 27 05:51:04 2011 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 8158AE06EC for ; Fri, 27 May 2011 05:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.303 X-Spam-Level: X-Spam-Status: No, score=-110.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 96E3ANBVlqr8 for ; Fri, 27 May 2011 05:51:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE44E0679 for ; Fri, 27 May 2011 05:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8371; q=dns/txt; s=iport; t=1306500663; x=1307710263; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GxLeeuKf8u4e/0TdtmuoUTKY/6JUKqxyahs3Ug/aljw=; b=G7VEeS4W8lZvgBVBgGZZ+qCl8ag4LgRwwhBxHqfcHJ94QanSfjNLmwlw 1RgbVkuedDxKb21vqbEmmcjAm2OdvbvFpefNFrMEitsvVEUNC403HMYbk 7iJWdTSn7QhP09tk0+haaWQAV4gah3wQJEW1mpP4A+IfXLwjb4D4mxhNF U=; X-IronPort-AV: E=Sophos;i="4.65,280,1304294400"; d="scan'208";a="365470995" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 12:51:02 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4RCp1JD000686; Fri, 27 May 2011 12:51:01 GMT Message-ID: <4DDF9E35.9070502@cisco.com> Date: Fri, 27 May 2011 08:51:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.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] legacy support in requirements 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, 27 May 2011 12:51:04 -0000 That works for me On 5/27/2011 2:21 AM, Elwell, John wrote: > Allyn, > > I already made a proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > John > > >> -----Original Message----- >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> Sent: 26 May 2011 20:08 >> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >> Cc: clue@ietf.org >> Subject: RE: [clue] legacy support in requirements >> >> Roni, Paul, John- >> Would you care to suggest the wording you would like to see as a >> requirement for legacy interoperability? That would be helpful. >> >> Thanks, >> Allyn >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Roni Even >>> Sent: Wednesday, May 18, 2011 11:13 AM >>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>> Cc: clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >> .... >>> >>> Anyhow we are discussing solution while my point is that we >> will need >>> as a >>> requirement to address the case of a call from a CLUE aware endpoint >> to >>> a >>> non CLUE aware endpoint. Even if the consensus will be to have the >>> preferred >>> video in the first video m-line. >>> >>> Regards >>> Roni >>> >>> >>> >>>> -----Original Message----- >>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>> Sent: Wednesday, May 18, 2011 4:41 PM >>>> To: Paul Kyzivat (pkyzivat); Roni Even >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> Paul, >>>> >>>> I would agree that if the offer-answer model semantic is that here >>> are >>>> several options and any subset of options is acceptable. >>>> >>>> However, if there is any grouping involved such that you need to >> have >>> a >>>> video and audio feed integrated to make sense then watch out. >>>> >>>> For example, I wouldn't want to end up with the result of a man's >>> video >>>> paired with a woman's voice. That could be rather comical. >>>> >>>> Mike >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>> Paul Kyzivat (pkyzivat) >>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>> Paul, >>>>> I think we read it differently. >>>>> If the answerer does not support the group attribute >> and the offer >>>> had >>>> the >>>>> fid semantics it may look to the answerer as an offer with >> multiple >>>> m-lines >>>>> of the same media tyoe. In this case an implementation >> might also >>>> decide to >>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>> Acceptable), >>>>> because it contains several "m" lines of the same media type. >>>> >>>> That is a slightly different story. >>>> >>>> Then the reason for rejection is not because it saw an >> attribute it >>>> didn't understand - its because it didn't like something it *did* >>>> understand. >>>> >>>>> This is very relevant to the multiple streams case and we should >>> look >>>> if we >>>>> state this behavior or we will look at providing an >> approach that >>>> will >>>> allow >>>>> the answerer to choose one m-line that the offerer >> prefers even of >>> it >>>> does >>>>> not understand CLUE. >>>> >>>> IMO (lets see if others differ), if a UA receives an offer with at >>>> least >>>> >>>> one m-line it is happy with, then it should not reject the call >>> because >>>> there are others that it does not "understand". >>>> >>>> Here "understand" means something different - presumably it does >>>> understand the direct meaning of the additional m-line, it just >>> doesn't >>>> understand the *significance* or use of it. >>>> >>>> I see little difference to getting to audio m-lines and >> only wanting >>>> one, and getting one audio and one video and only >> supporting audio. >>> In >>>> general you should not reject an audio/video call just because you >>> only >>>> support audio. >>>> >>>> I think it will behoove clue to strongly recommend that >> the m-lines >>> in >>>> an offer be arranged so the first ones are the ones it most wants >>> used >>>> if not all are. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>> To: Roni Even >>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>> Paul, >>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>> example >>>>>>> Roni >>>>>> >>>>>> OK, I looked. It is consistent with what I said. >>>>>> Either a=group: is understood, or not. If not, its ignored, and >>> not >>>> put >>>>>> in the answer. Same with a=mid: >>>>>> >>>>>> If a=group: *is* understood, but some parameter within >> it is not, >>>> there >>>>>> are explicit rules for what to do. >>>>>> >>>>>> AFAICT there are no examples in this document where failure to >>>>>> understand an a-line in total (or even in part) results in >>> rejecting >>>>>> the >>>>>> offer. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf >>>>>> Of >>>>>>>> Paul Kyzivat >>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>> To: Stephen Botzko >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>> >>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>> >>>>>>>>> When the offer includes parameters that >> the answerer >>>> does >>>>>> not >>>>>>>>> understand >>>>>>>>> there are two options, he can ignore the unknown >>>>>> parameters >>>>>>>> or >>>>>>>>> reject >>>>>>>>> the offer. >>>>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>>>> You are required to ignore parameters you do not >>>> understand. >>>>>>>>> >>>>>>>>> If you reject something because you don't like the >>>> parameters >>>>>> it >>>>>>>>> contains, then that is an implicit statement that you >>>>>> understand >>>>>>>>> those parameters well enough to decide to reject them. >>>>>>>>> >>>>>>>>> As far as I know, you are always free to reject >> offers, and it >>>>>>>> doesn't >>>>>>>>> really imply anything when you do that.. Whether it is wise >> is >>>>>>>> perhaps >>>>>>>>> a different question. >>>>>>>>> Stephen Botzko >>>>>>>> >>>>>>>> Certainly you are always free to reject an offer. >>>>>>>> In general I don't know for certain the reason why, >> and so if I >>>> give >>>>>>>> you >>>>>>>> the benefit of the doubt I will assume you have a >> valid reason >> - >>>>>>>> perhaps >>>>>>>> just policy. >>>>>>>> >>>>>>>> But if the reason you reject the offer is based on your >>> violating >>>> a >>>>>>>> spec, then you are non-conforming, whether I can >> determine you >>> are >>>>>>>> non-conforming or not. Whether being non-conforming is just >>>> un-wise, >>>>>> or >>>>>>>> something stronger, is a separate discussion. The >> IETF does not >>>> levy >>>>>>>> any >>>>>>>> penalties for violating its specs. But sometimes the market >>> does. >>>>>> (And >>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>> behavior >>>>>> in >>>>>>>> our documents. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> From hmmr@cisco.com Fri May 27 05:58:49 2011 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 67F79E0679 for ; Fri, 27 May 2011 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=0.907, 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 0SG+Eo3uePnt for ; Fri, 27 May 2011 05:58:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3876BE0671 for ; Fri, 27 May 2011 05:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=15053; q=dns/txt; s=iport; t=1306501128; x=1307710728; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=urH9+1N0yC85TCpPL0jMwqENtPYYlLJClB6gZzYFm3g=; b=UehBMGAZr8QJVOm99QxPNOPrW09j8ESrOZhlJLZ/p8dFoFiBESWKTVRv vQiwPb+xYfi5kJm1kJLmsAlIh0Of8mQhwjzibslzg5By3iUAMWOfvRuMG LbJflEpYHwf51E3cfo2ifYHN1xZk6a/Y6U8P5iLsijXCmp/IoLagxwPjG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBANme302tJXG+/2dsb2JhbAA2Hpdrjk13iHCeaZAljTyGHgSGY44khB6GUQ X-IronPort-AV: E=Sophos;i="4.65,280,1304294400"; d="scan'208";a="455437435" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 27 May 2011 12:58:47 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4RCwlY2001874; Fri, 27 May 2011 12:58:47 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 07:58:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 07:58:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcX4yd02c+yM3SQySHzmadUuPjGgAAAxawAAIz8LAAAVhHcA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E6B2221@ XMB-AMS- 214.cisco.co m> From: "Mike Hammer (hmmr)" To: "Elwell, John" , "Espen Berger (espeberg)" , "Stephen Botzko" X-OriginalArrivalTime: 27 May 2011 12:58:46.0486 (UTC) FILETIME=[D0AC2F60:01CC1C6D] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 12:58:49 -0000 Looks good to me too. Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, May 27, 2011 8:28 AM To: Espen Berger (espeberg); Stephen Botzko Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements I can live with Steve's proposal. I also don't mind separating the requirements, but I don't think we should refer to CLUE in the requirement - the RFC will live a long time after CLUE is finished and closed down. So if we want to separate the requirements, I would propose: REQMT-10: The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference. REQMT-10bis: The solution MUST include a mechanism that makes it possible for endpoints without support for telepresence extensions to participate in a telepresence conference with those that do. John > -----Original Message----- > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > Sent: 27 May 2011 12:23 > To: Stephen Botzko; Elwell, John > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > I think it would be clearer to formulate two different requirements > > > > 1) Two solution must provide a mechanism that make it > possible for endpoints with different capabilities to > interoperate, e.g. interoperability between a 2 > camera/screens and 3 camera/screens endpoint. > > 2) Two solution must provide a mechanism that make it > possible for endpoints that are CLUE aware to interoperate > with CLUE-less endpoints. > > > > Cheers > > > > -Espen > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Stephen Botzko > Sent: 27. mai 2011 13:16 > To: Elwell, John > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > I'm not sure that the language actually covers that (it seems > ambiguous). > > What do you think about changing "endpoints with different > capabilities" to "disparate devices"? > > Stephen > > > > On Fri, May 27, 2011 at 7:03 AM, Elwell, John > wrote: > > I thought requirement 10 would cover both > (signalling/protocol capabilities as well as user interface > capabilities). > > John > > > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: 27 May 2011 11:53 > > To: Elwell, John > > Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > > (pkyzivat); clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > Do you think that the language in requirement 10 means "SIP > > capabilities"? Or something else? > > > > I am thinking that issue is really about the > > signaling/protocol design itself, and isn't directly related > > to how many screens and cameras a system might have. > > > > Stephen Botzko > > > > > > On Fri, May 27, 2011 at 2:21 AM, Elwell, John > > wrote: > > > > > > Allyn, > > > > I already made a proposal: > > > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > > > John > > > > > > > > > -----Original Message----- > > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > > > > Sent: 26 May 2011 20:08 > > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > Roni, Paul, John- > > > Would you care to suggest the wording you would like > > to see as a > > > requirement for legacy interoperability? That would > > be helpful. > > > > > > Thanks, > > > Allyn > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Roni Even > > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > .... > > > > > > > > Anyhow we are discussing solution while my point > is that we > > > will need > > > > as a > > > > requirement to address the case of a call from a > > CLUE aware endpoint > > > to > > > > a > > > > non CLUE aware endpoint. Even if the consensus will > > be to have the > > > > preferred > > > > video in the first video m-line. > > > > > > > > Regards > > > > Roni > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > Paul, > > > > > > > > > > I would agree that if the offer-answer model > > semantic is that here > > > > are > > > > > several options and any subset of options is acceptable. > > > > > > > > > > However, if there is any grouping involved such > > that you need to > > > have > > > > a > > > > > video and audio feed integrated to make sense > > then watch out. > > > > > > > > > > For example, I wouldn't want to end up with the > > result of a man's > > > > video > > > > > paired with a woman's voice. That could be > > rather comical. > > > > > > > > > > Mike > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > Of > > > > > Paul Kyzivat (pkyzivat) > > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > > To: Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > > Paul, > > > > > > I think we read it differently. > > > > > > If the answerer does not support the group attribute > > > and the offer > > > > > had > > > > > the > > > > > > fid semantics it may look to the answerer as an > > offer with > > > multiple > > > > > m-lines > > > > > > of the same media tyoe. In this case an implementation > > > might also > > > > > decide to > > > > > > refuse the request (e.g., 488 Not Acceptable > > Here, or 606 Not > > > > > Acceptable), > > > > > > because it contains several "m" lines of the > > same media type. > > > > > > > > > > That is a slightly different story. > > > > > > > > > > Then the reason for rejection is not because it saw an > > > attribute it > > > > > didn't understand - its because it didn't like > > something it *did* > > > > > understand. > > > > > > > > > > > This is very relevant to the multiple streams > > case and we should > > > > look > > > > > if we > > > > > > state this behavior or we will look at providing an > > > approach that > > > > > will > > > > > allow > > > > > > the answerer to choose one m-line that the offerer > > > prefers even of > > > > it > > > > > does > > > > > > not understand CLUE. > > > > > > > > > > IMO (lets see if others differ), if a UA receives > > an offer with at > > > > > least > > > > > > > > > > one m-line it is happy with, then it should not > > reject the call > > > > because > > > > > there are others that it does not "understand". > > > > > > > > > > Here "understand" means something different - > > presumably it does > > > > > understand the direct meaning of the additional > > m-line, it just > > > > doesn't > > > > > understand the *significance* or use of it. > > > > > > > > > > I see little difference to getting to audio m-lines and > > > only wanting > > > > > one, and getting one audio and one video and only > > > supporting audio. > > > > In > > > > > general you should not reject an audio/video call > > just because you > > > > only > > > > > support audio. > > > > > > > > > > I think it will behoove clue to strongly recommend that > > > the m-lines > > > > in > > > > > an offer be arranged so the first ones are the > > ones it most wants > > > > used > > > > > if not all are. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > > Roni > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > > >> To: Roni Even > > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > > >> Subject: Re: [clue] legacy support in requirements > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > > >>> Paul, > > > > > >>> Look at > > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > > example > > > > > >>> Roni > > > > > >> > > > > > >> OK, I looked. It is consistent with what I said. > > > > > >> Either a=3Dgroup: is understood, or not. If not, > > its ignored, and > > > > not > > > > > put > > > > > >> in the answer. Same with a=3Dmid: > > > > > >> > > > > > >> If a=3Dgroup: *is* understood, but some > parameter within > > > it is not, > > > > > there > > > > > >> are explicit rules for what to do. > > > > > >> > > > > > >> AFAICT there are no examples in this document > > where failure to > > > > > >> understand an a-line in total (or even in > > part) results in > > > > rejecting > > > > > >> the > > > > > >> offer. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >>>> -----Original Message----- > > > > > >>>> From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On > > > > > Behalf > > > > > >> Of > > > > > >>>> Paul Kyzivat > > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > > >>>> To: Stephen Botzko > > > > > >>>> Cc: clue@ietf.org > > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > > >>>> > > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > > >>>> > > > > > >>>>> When the offer includes parameters that > > > the answerer > > > > > does > > > > > >> not > > > > > >>>>> understand > > > > > >>>>> there are two options, he can > > ignore the unknown > > > > > >> parameters > > > > > >>>> or > > > > > >>>>> reject > > > > > >>>>> the offer. > > > > > >>>>> Rejecting the offer in that case is > > not really kosher. > > > > > >>>>> You are required to ignore parameters > > you do not > > > > > understand. > > > > > >>>>> > > > > > >>>>> If you reject something because you > > don't like the > > > > > parameters > > > > > >> it > > > > > >>>>> contains, then that is an implicit > > statement that you > > > > > >> understand > > > > > >>>>> those parameters well enough to > > decide to reject them. > > > > > >>>>> > > > > > >>>>> As far as I know, you are always free to reject > > > offers, and it > > > > > >>>> doesn't > > > > > >>>>> really imply anything when you do that.. > > Whether it is wise > > > is > > > > > >>>> perhaps > > > > > >>>>> a different question. > > > > > >>>>> Stephen Botzko > > > > > >>>> > > > > > >>>> Certainly you are always free to reject an offer. > > > > > >>>> In general I don't know for certain the reason why, > > > and so if I > > > > > give > > > > > >>>> you > > > > > >>>> the benefit of the doubt I will assume you have a > > > valid reason > > > - > > > > > >>>> perhaps > > > > > >>>> just policy. > > > > > >>>> > > > > > >>>> But if the reason you reject the offer is > > based on your > > > > violating > > > > > a > > > > > >>>> spec, then you are non-conforming, whether I can > > > determine you > > > > are > > > > > >>>> non-conforming or not. Whether being > > non-conforming is just > > > > > un-wise, > > > > > >> or > > > > > >>>> something stronger, is a separate discussion. The > > > IETF does not > > > > > levy > > > > > >>>> any > > > > > >>>> penalties for violating its specs. But > > sometimes the market > > > > does. > > > > > >> (And > > > > > >>>> sometimes not.) But we don't need to endorse > > non-conforming > > > > > behavior > > > > > >> in > > > > > >>>> our documents. > > > > > >>>> > > > > > >>>> Thanks, > > > > > >>>> Paul > > > > > >>>> _______________________________________________ > > > > > >>>> clue mailing list > > > > > >>>> clue@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > clue mailing list > > > > > clue@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > > 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 stephen.botzko@gmail.com Fri May 27 05:59:53 2011 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 17E6CE0671 for ; Fri, 27 May 2011 05:59:53 -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 zpUGU85gMvD8 for ; Fri, 27 May 2011 05:59:51 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43461E0679 for ; Fri, 27 May 2011 05:59:51 -0700 (PDT) Received: by vxg33 with SMTP id 33so1659972vxg.31 for ; Fri, 27 May 2011 05:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V3rpfe64BdqtTSV0tI4ByWtemRQ4nKRbEmi1OyjjRJo=; b=g/xu748SU0DvQDSB424CDxsXvIHqqN8u+biQenyYTCZ0ZBz4SKTR9e/4FCpmeOAVvV aZ2rtzY5EkRJtnb7zitUxKzuFN4QZueYS2EdOJZqMmJ50aaHTlB9xmzRgvY0wLAQoGmy UIaAFXDEtATbxW+FseG+lJdhprim6OcIEbXCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jT7ArAEDSQyijGgqgZkcFSvGDr4Skpo5T/c8O9EI3NT1pwoJB+wFJLn2hSIF4u4SWd VUyT9zFJKo3DBpxVpxFf+IpneXBsttrp6/yXnX2semNjuBLNi57FfYp5r+yEa69Hxv2E GjvgcuiGQTmwPqRF714vy1gykQ1THfBsCBrQg= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr3033459vdb.200.1306501190589; Fri, 27 May 2011 05:59:50 -0700 (PDT) Received: by 10.52.186.97 with HTTP; Fri, 27 May 2011 05:59:50 -0700 (PDT) In-Reply-To: <4DDF9E35.9070502@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <4DDF9E35.9070502@cisco.com> Date: Fri, 27 May 2011 08:59:50 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf307f34a65d1ceb04a44183f2 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 12:59:53 -0000 --20cf307f34a65d1ceb04a44183f2 Content-Type: text/plain; charset=ISO-8859-1 I am ok with it, we might wordsmith it slightly to remove the capability word. It has become overloaded. Stephen Botzko On Fri, May 27, 2011 at 8:51 AM, Paul Kyzivat wrote: > That works for me > > > On 5/27/2011 2:21 AM, Elwell, John wrote: > >> Allyn, >> >> I already made a proposal: >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >> >> John >> >> >> -----Original Message----- >>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>> Sent: 26 May 2011 20:08 >>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> Roni, Paul, John- >>> Would you care to suggest the wording you would like to see as a >>> requirement for legacy interoperability? That would be helpful. >>> >>> Thanks, >>> Allyn >>> >>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> >>> Of >>> >>>> Roni Even >>>> Sent: Wednesday, May 18, 2011 11:13 AM >>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> .... >>> >>>> >>>> Anyhow we are discussing solution while my point is that we >>>> >>> will need >>> >>>> as a >>>> requirement to address the case of a call from a CLUE aware endpoint >>>> >>> to >>> >>>> a >>>> non CLUE aware endpoint. Even if the consensus will be to have the >>>> preferred >>>> video in the first video m-line. >>>> >>>> Regards >>>> Roni >>>> >>>> >>>> >>>> -----Original Message----- >>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>> Sent: Wednesday, May 18, 2011 4:41 PM >>>>> To: Paul Kyzivat (pkyzivat); Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] legacy support in requirements >>>>> >>>>> Paul, >>>>> >>>>> I would agree that if the offer-answer model semantic is that here >>>>> >>>> are >>>> >>>>> several options and any subset of options is acceptable. >>>>> >>>>> However, if there is any grouping involved such that you need to >>>>> >>>> have >>> >>>> a >>>> >>>>> video and audio feed integrated to make sense then watch out. >>>>> >>>>> For example, I wouldn't want to end up with the result of a man's >>>>> >>>> video >>>> >>>>> paired with a woman's voice. That could be rather comical. >>>>> >>>>> Mike >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>>>> >>>> [mailto:clue-bounces@ietf.org] On Behalf >>> >>>> Of >>>> >>>>> Paul Kyzivat (pkyzivat) >>>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>>> To: Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>> >>>>>> Paul, >>>>>> I think we read it differently. >>>>>> If the answerer does not support the group attribute >>>>>> >>>>> and the offer >>> >>>> had >>>>> the >>>>> >>>>>> fid semantics it may look to the answerer as an offer with >>>>>> >>>>> multiple >>> >>>> m-lines >>>>> >>>>>> of the same media tyoe. In this case an implementation >>>>>> >>>>> might also >>> >>>> decide to >>>>> >>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>>>> >>>>> Acceptable), >>>>> >>>>>> because it contains several "m" lines of the same media type. >>>>>> >>>>> >>>>> That is a slightly different story. >>>>> >>>>> Then the reason for rejection is not because it saw an >>>>> >>>> attribute it >>> >>>> didn't understand - its because it didn't like something it *did* >>>>> understand. >>>>> >>>>> This is very relevant to the multiple streams case and we should >>>>>> >>>>> look >>>> >>>>> if we >>>>> >>>>>> state this behavior or we will look at providing an >>>>>> >>>>> approach that >>> >>>> will >>>>> allow >>>>> >>>>>> the answerer to choose one m-line that the offerer >>>>>> >>>>> prefers even of >>> >>>> it >>>> >>>>> does >>>>> >>>>>> not understand CLUE. >>>>>> >>>>> >>>>> IMO (lets see if others differ), if a UA receives an offer with at >>>>> least >>>>> >>>>> one m-line it is happy with, then it should not reject the call >>>>> >>>> because >>>> >>>>> there are others that it does not "understand". >>>>> >>>>> Here "understand" means something different - presumably it does >>>>> understand the direct meaning of the additional m-line, it just >>>>> >>>> doesn't >>>> >>>>> understand the *significance* or use of it. >>>>> >>>>> I see little difference to getting to audio m-lines and >>>>> >>>> only wanting >>> >>>> one, and getting one audio and one video and only >>>>> >>>> supporting audio. >>> >>>> In >>>> >>>>> general you should not reject an audio/video call just because you >>>>> >>>> only >>>> >>>>> support audio. >>>>> >>>>> I think it will behoove clue to strongly recommend that >>>>> >>>> the m-lines >>> >>>> in >>>> >>>>> an offer be arranged so the first ones are the ones it most wants >>>>> >>>> used >>>> >>>>> if not all are. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Roni >>>>>> >>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>>> To: Roni Even >>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>> >>>>>>>> Paul, >>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>>>> >>>>>>> example >>>>> >>>>>> Roni >>>>>>>> >>>>>>> >>>>>>> OK, I looked. It is consistent with what I said. >>>>>>> Either a=group: is understood, or not. If not, its ignored, and >>>>>>> >>>>>> not >>>> >>>>> put >>>>> >>>>>> in the answer. Same with a=mid: >>>>>>> >>>>>>> If a=group: *is* understood, but some parameter within >>>>>>> >>>>>> it is not, >>> >>>> there >>>>> >>>>>> are explicit rules for what to do. >>>>>>> >>>>>>> AFAICT there are no examples in this document where failure to >>>>>>> understand an a-line in total (or even in part) results in >>>>>>> >>>>>> rejecting >>>> >>>>> the >>>>>>> offer. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> -----Original Message----- >>>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>>>>> >>>>>>>> Behalf >>>>> >>>>>> Of >>>>>>> >>>>>>>> Paul Kyzivat >>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>>> To: Stephen Botzko >>>>>>>>> Cc: clue@ietf.org >>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>>> >>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>> When the offer includes parameters that >>>>>>>>>> >>>>>>>>> the answerer >>> >>>> does >>>>> >>>>>> not >>>>>>> >>>>>>>> understand >>>>>>>>>> there are two options, he can ignore the unknown >>>>>>>>>> >>>>>>>>> parameters >>>>>>> >>>>>>>> or >>>>>>>>> >>>>>>>>>> reject >>>>>>>>>> the offer. >>>>>>>>>> Rejecting the offer in that case is not really kosher. >>>>>>>>>> You are required to ignore parameters you do not >>>>>>>>>> >>>>>>>>> understand. >>>>> >>>>>> >>>>>>>>>> If you reject something because you don't like the >>>>>>>>>> >>>>>>>>> parameters >>>>> >>>>>> it >>>>>>> >>>>>>>> contains, then that is an implicit statement that you >>>>>>>>>> >>>>>>>>> understand >>>>>>> >>>>>>>> those parameters well enough to decide to reject them. >>>>>>>>>> >>>>>>>>>> As far as I know, you are always free to reject >>>>>>>>>> >>>>>>>>> offers, and it >>> >>>> doesn't >>>>>>>>> >>>>>>>>>> really imply anything when you do that.. Whether it is wise >>>>>>>>>> >>>>>>>>> is >>> >>>> perhaps >>>>>>>>> >>>>>>>>>> a different question. >>>>>>>>>> Stephen Botzko >>>>>>>>>> >>>>>>>>> >>>>>>>>> Certainly you are always free to reject an offer. >>>>>>>>> In general I don't know for certain the reason why, >>>>>>>>> >>>>>>>> and so if I >>> >>>> give >>>>> >>>>>> you >>>>>>>>> the benefit of the doubt I will assume you have a >>>>>>>>> >>>>>>>> valid reason >>> - >>> >>>> perhaps >>>>>>>>> just policy. >>>>>>>>> >>>>>>>>> But if the reason you reject the offer is based on your >>>>>>>>> >>>>>>>> violating >>>> >>>>> a >>>>> >>>>>> spec, then you are non-conforming, whether I can >>>>>>>>> >>>>>>>> determine you >>> >>>> are >>>> >>>>> non-conforming or not. Whether being non-conforming is just >>>>>>>>> >>>>>>>> un-wise, >>>>> >>>>>> or >>>>>>> >>>>>>>> something stronger, is a separate discussion. The >>>>>>>>> >>>>>>>> IETF does not >>> >>>> levy >>>>> >>>>>> any >>>>>>>>> penalties for violating its specs. But sometimes the market >>>>>>>>> >>>>>>>> does. >>>> >>>>> (And >>>>>>> >>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>>>>>>> >>>>>>>> behavior >>>>> >>>>>> in >>>>>>> >>>>>>>> our documents. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f34a65d1ceb04a44183f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am ok with it, we might wordsmith it slightly to remove the capabili= ty word.=A0 It has become overloaded.
=A0
Stephen Botzko

On Fri, May 27, 2011 at 8:51 AM, Paul Kyzivat <pkyzivat@cisco.co= m> wrote:
That works for me=20


On 5/27/2011 2:21 AM, Elwell, John wrote:
Allyn,

I already made a p= roposal:
http://www.ietf.org/mail-archive/web/clue/cu= rrent/msg00221.html

John


-----Original Message-----
Fr= om: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: 26 May 2011 20:08
To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, = John
Cc: clue@ietf.or= g
Subject: RE: [clue] legacy support in requirements

Roni, Pa= ul, John-
Would you care to suggest the wording you would like to see as a
require= ment for legacy interoperability? That would be helpful.

Thanks,
= Allyn

-----Original Message-----
Fr= om: clue-bounces= @ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of
Roni Even
Sent: Wednesday, Ma= y 18, 2011 11:13 AM
To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)
Cc: clue@ietf.orgSubject: Re: [clue] legacy support in requirements

...= .

Anyhow we are discussing sol= ution while my point is that we
will need
as a
requirement to address t= he case of a call from a CLUE aware endpoint
to
a
non CLUE aware endpoint. Ev= en if the consensus will be to have the
preferred
video in the first = video m-line.

Regards
Roni



-----Original Message-----
Fr= om: Mike Hammer (hmmr) [mailto:hmmr@cisco.com]
Sent: Wednesday, May 18, 2011 4:41 PM
To: Paul Kyzivat (pkyzivat); Roni = Even
Cc: clue@ietf.or= g
Subject: RE: [clue] legacy support in requirements

Paul,
I would agree that if the offer-answer model semantic is that here
<= /blockquote>are
several options and any subset o= f options is acceptable.

However, if there is any grouping involved = such that you need to
have
a
video and audio feed integrated = to make sense then watch out.

For example, I wouldn't want to en= d up with the result of a man's
video
paired with a woman's voice.= =A0That could be rather comical.

Mike


-----Original Mess= age-----
From: clue-bounc= es@ietf.org
[mailto:clue-bounces@ietf.org] On Behalf
Of
Paul Kyzivat (pkyzivat)
Sent:= Tuesday, May 17, 2011 7:45 PM
To: Roni Even
Cc: clue@ietf.org
Subject: Re: [clue] legacy support in requirements



On 5/17/2= 011 6:05 PM, Roni Even wrote:
Paul,
I think we read it diff= erently.
If the answerer does not support the group attribute
and the offer
had
the
fid semantics it may look to the= answerer as an offer with
multip= le
m-lines
of the same media tyoe. In this = case an implementation
might also=
decide to
refuse the request (e.g., 488 No= t Acceptable Here, or 606 Not
Acceptable),
because it contains several &quo= t;m" lines of the same media type.

That is a sligh= tly different story.

Then the reason for rejection is not because it saw an
=
attribute it
didn't understand - its beca= use it didn't like something it *did*
understand.

This is very relevant to the mul= tiple streams case and we should
look
if we
state this behavior or we will l= ook at providing an
approach that=
will
allow
the answerer to choose one m-lin= e that the offerer
prefers even o= f
it
does
not understand CLUE.

IMO (lets see if others differ), if a UA receives an offer with at=
least

one m-line it is happy with, then it should not reject the cal= l
because
there are others that it does no= t "understand".

Here "understand" means somethin= g different - presumably it does
understand the direct meaning of the additional m-line, it just
doesn't
understand the *significance* or= use of it.

I see little difference to getting to audio m-lines and<= br>
only wanting
one, and getting one audio and o= ne video and only
supporting audio.
In
general you should not reject an= audio/video call just because you
only
support audio.

I think it= will behoove clue to strongly recommend that
the m-lines
in
an offer be arranged so the firs= t ones are the ones it most wants
used
if not all are.

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

Roni

-----Original Message-----
Fr= om: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, May 18, 2011 12:37 AM
To: Roni Even
Cc: 'Stephen= Botzko'; clue@ietf.= org
Subject: Re: [clue] legacy support in requirements


On 5/17/2011 5:20 PM, Roni Even wrote:
Paul,
Look at http://tool= s.ietf.org/html/rfc5888#section-9.4.2 for
example
Roni

OK, I l= ooked. It is consistent with what I said.
Either a=3Dgroup: is understoo= d, or not. If not, its ignored, and
not
put
in the answer. Same with a=3Dmid= :

If a=3Dgroup: *is* understood, but some parameter within
it is not,
there
are explicit rules for what to d= o.

AFAICT there are no examples in this document where failure to understand an a-line in total (or even in part) results in
=
rejecting
the
offer.

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

-----Original Message-----
Fr= om: clue-bounces= @ietf.org [mailto:clue-bounces@ietf.org] On
Behalf
Of
Paul Kyzivat
Sent: Tuesday, M= ay 17, 2011 6:11 PM
To: Stephen Botzko
Cc: clue@ietf.org
Subject: Re: [clue] legacy support in requirements



On 5/17/2= 011 10:34 AM, Stephen Botzko wrote:

=A0 =A0 =A0 On 5/17/2011 2:24 AM= , Roni Even wrote:

=A0 =A0 =A0 =A0 =A0 When the off= er includes parameters that
the answerer
does
not
=A0 =A0 =A0 =A0 =A0 understand=A0 =A0 =A0 =A0 =A0 there are two options, he can ignore the unknown
<= /blockquote>
parameters
or
=A0 =A0 =A0 =A0 =A0 reject
= =A0 =A0 =A0 =A0 =A0 the offer.
=A0 =A0 =A0 Rejecting the offer in that c= ase is not really kosher.
=A0 =A0 =A0 You are required to ignore parameters you do not
understand.

=A0 =A0 =A0 If you reject so= mething because you don't like the
parameters
it
=A0 =A0 =A0 contains, then that = is an implicit statement that you
understand
=A0 =A0 =A0 those parameters wel= l enough to decide to reject them.

As far as I know, you are always = free to reject
offers, and it
doesn't
really imply anything when you d= o that.. =A0Whether it is wise
is
perhaps
a different question.
Stephen= Botzko

Certainly you are always free to reject an offe= r.
In general I don't know for certain the reason why,
and so if I
give
you
the benefit of the doubt = I will assume you have a
valid reason
-
perhaps
just policy.

B= ut if the reason you reject the offer is based on your
violating
a
spec, then you are non-conformin= g, whether I can
determine you
are
non-conforming or not. Whether b= eing non-conforming is just
un-wise,
or
something stronger, is a separat= e discussion. The
IETF does not
levy
any
penalties for violating i= ts specs. But sometimes the market
does.
(And
sometimes not.) But we don't= need to endorse non-conforming
behavior
in
our documents.

=A0 =A0 = =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul
__________________________________= _____________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue




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

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

________________________________= _______________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/cl= ue

--20cf307f34a65d1ceb04a44183f2-- From pkyzivat@cisco.com Fri May 27 06:02:02 2011 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 E3C45E0671 for ; Fri, 27 May 2011 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ykDKq3gBKJZw for ; Fri, 27 May 2011 06:02:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC56E06EC for ; Fri, 27 May 2011 06:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=16669; q=dns/txt; s=iport; t=1306501321; x=1307710921; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=guoJFePTpp+TiLmcrSbEBzpQK7tsIL+Ewm42u25x1ec=; b=Wi9G2F1KgckLolJZ0NOXD0RmgaC7qxG5Vsa1Zc4L3nzTSc60PDFnEO+i Akh1GkS40DcNVsuxEaLZ4YE9ttf/qREiFP2aChD7bAgo9utJyLmcva5zr uGiELzwNYhLsCa+pAgyVNw7GDGjvqRZ+M0FZBVuiACKdL58Po8Kw+eBLl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAH+g302rRDoI/2dsb2JhbAA2Hpdrjk13iHCecpAljT6GHgSQQ4Q7hCeGTw X-IronPort-AV: E=Sophos;i="4.65,280,1304294400"; d="scan'208";a="365478301" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 13:02:01 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4RD20VY008712 for ; Fri, 27 May 2011 13:02:00 GMT Message-ID: <4DDFA0C8.1050509@cisco.com> Date: Fri, 27 May 2011 09:02:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 13:02:03 -0000 On 5/27/2011 8:28 AM, Elwell, John wrote: > I can live with Steve's proposal. I also don't mind separating the requirements, but I don't think we should refer to CLUE in the requirement - the RFC will live a long time after CLUE is finished and closed down. So if we want to separate the requirements, I would propose: > > REQMT-10: The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference. > REQMT-10bis: The solution MUST include a mechanism that makes it possible for endpoints without support for telepresence extensions to participate in a telepresence conference with those that do. How about the following variant of that: REQMT-10bis: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. I dropped "mechanism" because its unlikely to be a new mechanism that makes this possible. (That would require changes to the legacy systems.) Rather it will need to be the manner of using existing mechanisms. And I changed "telepresence conference" to "telepresence session" because this ought to work point-point as well as for conferences. (But we probably need more definition work here, since neither telepresence-conference nor telepresence-session is currently defined.) Thanks, Paul > John > > >> -----Original Message----- >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >> Sent: 27 May 2011 12:23 >> To: Stephen Botzko; Elwell, John >> Cc: clue@ietf.org >> Subject: RE: [clue] legacy support in requirements >> >> I think it would be clearer to formulate two different requirements >> >> >> >> 1) Two solution must provide a mechanism that make it >> possible for endpoints with different capabilities to >> interoperate, e.g. interoperability between a 2 >> camera/screens and 3 camera/screens endpoint. >> >> 2) Two solution must provide a mechanism that make it >> possible for endpoints that are CLUE aware to interoperate >> with CLUE-less endpoints. >> >> >> >> Cheers >> >> >> >> -Espen >> >> >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Stephen Botzko >> Sent: 27. mai 2011 13:16 >> To: Elwell, John >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> I'm not sure that the language actually covers that (it seems >> ambiguous). >> >> What do you think about changing "endpoints with different >> capabilities" to "disparate devices"? >> >> Stephen >> >> >> >> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >> wrote: >> >> I thought requirement 10 would cover both >> (signalling/protocol capabilities as well as user interface >> capabilities). >> >> John >> >> >> >>> -----Original Message----- >>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >> >>> Sent: 27 May 2011 11:53 >>> To: Elwell, John >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >>> (pkyzivat); clue@ietf.org >> >>> Subject: Re: [clue] legacy support in requirements >>> >>> Do you think that the language in requirement 10 means "SIP >>> capabilities"? Or something else? >>> >>> I am thinking that issue is really about the >>> signaling/protocol design itself, and isn't directly related >>> to how many screens and cameras a system might have. >>> >>> Stephen Botzko >>> >>> >>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>> wrote: >>> >>> >>> Allyn, >>> >>> I already made a proposal: >>> >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>> >>> John >>> >>> >>> >>> > -----Original Message----- >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>> >>> > Sent: 26 May 2011 20:08 >>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>> > Cc: clue@ietf.org >>> > Subject: RE: [clue] legacy support in requirements >>> > >>> > Roni, Paul, John- >>> > Would you care to suggest the wording you would like >>> to see as a >>> > requirement for legacy interoperability? That would >>> be helpful. >>> > >>> > Thanks, >>> > Allyn >>> > >>> > > -----Original Message----- >>> > > From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On Behalf >>> > Of >>> > > Roni Even >>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>> > > Cc: clue@ietf.org >>> > > Subject: Re: [clue] legacy support in requirements >>> > > >>> > .... >>> > > >>> > > Anyhow we are discussing solution while my point >> is that we >>> > will need >>> > > as a >>> > > requirement to address the case of a call from a >>> CLUE aware endpoint >>> > to >>> > > a >>> > > non CLUE aware endpoint. Even if the consensus will >>> be to have the >>> > > preferred >>> > > video in the first video m-line. >>> > > >>> > > Regards >>> > > Roni >>> > > >>> > > >>> > > >>> > > > -----Original Message----- >>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>> > > > Cc: clue@ietf.org >>> > > > Subject: RE: [clue] legacy support in requirements >>> > > > >>> > > > Paul, >>> > > > >>> > > > I would agree that if the offer-answer model >>> semantic is that here >>> > > are >>> > > > several options and any subset of options is acceptable. >>> > > > >>> > > > However, if there is any grouping involved such >>> that you need to >>> > have >>> > > a >>> > > > video and audio feed integrated to make sense >>> then watch out. >>> > > > >>> > > > For example, I wouldn't want to end up with the >>> result of a man's >>> > > video >>> > > > paired with a woman's voice. That could be >>> rather comical. >>> > > > >>> > > > Mike >>> > > > >>> > > > >>> > > > -----Original Message----- >>> > > > From: clue-bounces@ietf.org >>> > [mailto:clue-bounces@ietf.org] On Behalf >>> > > Of >>> > > > Paul Kyzivat (pkyzivat) >>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>> > > > To: Roni Even >>> > > > Cc: clue@ietf.org >>> > > > Subject: Re: [clue] legacy support in requirements >>> > > > >>> > > > >>> > > > >>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>> > > > > Paul, >>> > > > > I think we read it differently. >>> > > > > If the answerer does not support the group attribute >>> > and the offer >>> > > > had >>> > > > the >>> > > > > fid semantics it may look to the answerer as an >>> offer with >>> > multiple >>> > > > m-lines >>> > > > > of the same media tyoe. In this case an implementation >>> > might also >>> > > > decide to >>> > > > > refuse the request (e.g., 488 Not Acceptable >>> Here, or 606 Not >>> > > > Acceptable), >>> > > > > because it contains several "m" lines of the >>> same media type. >>> > > > >>> > > > That is a slightly different story. >>> > > > >>> > > > Then the reason for rejection is not because it saw an >>> > attribute it >>> > > > didn't understand - its because it didn't like >>> something it *did* >>> > > > understand. >>> > > > >>> > > > > This is very relevant to the multiple streams >>> case and we should >>> > > look >>> > > > if we >>> > > > > state this behavior or we will look at providing an >>> > approach that >>> > > > will >>> > > > allow >>> > > > > the answerer to choose one m-line that the offerer >>> > prefers even of >>> > > it >>> > > > does >>> > > > > not understand CLUE. >>> > > > >>> > > > IMO (lets see if others differ), if a UA receives >>> an offer with at >>> > > > least >>> > > > >>> > > > one m-line it is happy with, then it should not >>> reject the call >>> > > because >>> > > > there are others that it does not "understand". >>> > > > >>> > > > Here "understand" means something different - >>> presumably it does >>> > > > understand the direct meaning of the additional >>> m-line, it just >>> > > doesn't >>> > > > understand the *significance* or use of it. >>> > > > >>> > > > I see little difference to getting to audio m-lines and >>> > only wanting >>> > > > one, and getting one audio and one video and only >>> > supporting audio. >>> > > In >>> > > > general you should not reject an audio/video call >>> just because you >>> > > only >>> > > > support audio. >>> > > > >>> > > > I think it will behoove clue to strongly recommend that >>> > the m-lines >>> > > in >>> > > > an offer be arranged so the first ones are the >>> ones it most wants >>> > > used >>> > > > if not all are. >>> > > > >>> > > > Thanks, >>> > > > Paul >>> > > > >>> > > > > Roni >>> > > > > >>> > > > >> -----Original Message----- >>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>> > > > >> To: Roni Even >>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>> > > > >> Subject: Re: [clue] legacy support in requirements >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>> > > > >>> Paul, >>> > > > >>> Look at >>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>> > > > example >>> > > > >>> Roni >>> > > > >> >>> > > > >> OK, I looked. It is consistent with what I said. >>> > > > >> Either a=group: is understood, or not. If not, >>> its ignored, and >>> > > not >>> > > > put >>> > > > >> in the answer. Same with a=mid: >>> > > > >> >>> > > > >> If a=group: *is* understood, but some >> parameter within >>> > it is not, >>> > > > there >>> > > > >> are explicit rules for what to do. >>> > > > >> >>> > > > >> AFAICT there are no examples in this document >>> where failure to >>> > > > >> understand an a-line in total (or even in >>> part) results in >>> > > rejecting >>> > > > >> the >>> > > > >> offer. >>> > > > >> >>> > > > >> Thanks, >>> > > > >> Paul >>> > > > >> >>> > > > >>>> -----Original Message----- >>> > > > >>>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On >>> > > > Behalf >>> > > > >> Of >>> > > > >>>> Paul Kyzivat >>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>> > > > >>>> To: Stephen Botzko >>> > > > >>>> Cc: clue@ietf.org >>> > > > >>>> Subject: Re: [clue] legacy support in requirements >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>> > > > >>>> >>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>> > > > >>>> >>> > > > >>>>> When the offer includes parameters that >>> > the answerer >>> > > > does >>> > > > >> not >>> > > > >>>>> understand >>> > > > >>>>> there are two options, he can >>> ignore the unknown >>> > > > >> parameters >>> > > > >>>> or >>> > > > >>>>> reject >>> > > > >>>>> the offer. >>> > > > >>>>> Rejecting the offer in that case is >>> not really kosher. >>> > > > >>>>> You are required to ignore parameters >>> you do not >>> > > > understand. >>> > > > >>>>> >>> > > > >>>>> If you reject something because you >>> don't like the >>> > > > parameters >>> > > > >> it >>> > > > >>>>> contains, then that is an implicit >>> statement that you >>> > > > >> understand >>> > > > >>>>> those parameters well enough to >>> decide to reject them. >>> > > > >>>>> >>> > > > >>>>> As far as I know, you are always free to reject >>> > offers, and it >>> > > > >>>> doesn't >>> > > > >>>>> really imply anything when you do that.. >>> Whether it is wise >>> > is >>> > > > >>>> perhaps >>> > > > >>>>> a different question. >>> > > > >>>>> Stephen Botzko >>> > > > >>>> >>> > > > >>>> Certainly you are always free to reject an offer. >>> > > > >>>> In general I don't know for certain the reason why, >>> > and so if I >>> > > > give >>> > > > >>>> you >>> > > > >>>> the benefit of the doubt I will assume you have a >>> > valid reason >>> > - >>> > > > >>>> perhaps >>> > > > >>>> just policy. >>> > > > >>>> >>> > > > >>>> But if the reason you reject the offer is >>> based on your >>> > > violating >>> > > > a >>> > > > >>>> spec, then you are non-conforming, whether I can >>> > determine you >>> > > are >>> > > > >>>> non-conforming or not. Whether being >>> non-conforming is just >>> > > > un-wise, >>> > > > >> or >>> > > > >>>> something stronger, is a separate discussion. The >>> > IETF does not >>> > > > levy >>> > > > >>>> any >>> > > > >>>> penalties for violating its specs. But >>> sometimes the market >>> > > does. >>> > > > >> (And >>> > > > >>>> sometimes not.) But we don't need to endorse >>> non-conforming >>> > > > behavior >>> > > > >> in >>> > > > >>>> our documents. >>> > > > >>>> >>> > > > >>>> Thanks, >>> > > > >>>> Paul >>> > > > >>>> _______________________________________________ >>> > > > >>>> clue mailing list >>> > > > >>>> clue@ietf.org >>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue >>> > > > >>> >>> > > > >>> >>> > > > > >>> > > > > >>> > > > _______________________________________________ >>> > > > clue mailing list >>> > > > clue@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/clue >>> > > >>> > > _______________________________________________ >>> > > clue mailing list >>> > > clue@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/clue >>> > >>> _______________________________________________ >>> 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.elwell@siemens-enterprise.com Fri May 27 06:55:28 2011 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 2D3A3E06C7 for ; Fri, 27 May 2011 06:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 Xj+o2HtSdsvB for ; Fri, 27 May 2011 06:55:26 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id D6B30E0664 for ; Fri, 27 May 2011 06:55:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1306504478!6163250!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 10921 invoked from network); 27 May 2011 13:54:38 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-216.messagelabs.com with SMTP; 27 May 2011 13:54:38 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 5B21E1EB83D3; Fri, 27 May 2011 15:54:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 27 May 2011 15:54:37 +0200 From: "Elwell, John" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 27 May 2011 15:54:35 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcbkeociU79eYoRASVVB9uolX4rQAB0sHA Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com> <4DDFA0C8.1050509@cisco.com> In-Reply-To: <4DDFA0C8.1050509@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 13:55:28 -0000 Yes, I like Paul's changes. John > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 27 May 2011 14:02 > To: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/27/2011 8:28 AM, Elwell, John wrote: > > I can live with Steve's proposal. I also don't mind > separating the requirements, but I don't think we should > refer to CLUE in the requirement - the RFC will live a long > time after CLUE is finished and closed down. So if we want to > separate the requirements, I would propose: > > > > REQMT-10: The solution MUST include a mechanism that makes > it possible for endpoints with different capabilities to > interoperate in a telepresence conference. > > REQMT-10bis: The solution MUST include a mechanism that > makes it possible for endpoints without support for > telepresence extensions to participate in a telepresence > conference with those that do. > > How about the following variant of that: > > REQMT-10bis: The solution MUST make it possible for > endpoints without > support for telepresence extensions to participate in a telepresence > session with those that do. > > I dropped "mechanism" because its unlikely to be a new mechanism that > makes this possible. (That would require changes to the > legacy systems.) > Rather it will need to be the manner of using existing mechanisms. > > And I changed "telepresence conference" to "telepresence session" > because this ought to work point-point as well as for conferences. > (But we probably need more definition work here, since neither > telepresence-conference nor telepresence-session is currently > defined.) > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >> Sent: 27 May 2011 12:23 > >> To: Stephen Botzko; Elwell, John > >> Cc: clue@ietf.org > >> Subject: RE: [clue] legacy support in requirements > >> > >> I think it would be clearer to formulate two different requirements > >> > >> > >> > >> 1) Two solution must provide a mechanism that make it > >> possible for endpoints with different capabilities to > >> interoperate, e.g. interoperability between a 2 > >> camera/screens and 3 camera/screens endpoint. > >> > >> 2) Two solution must provide a mechanism that make it > >> possible for endpoints that are CLUE aware to interoperate > >> with CLUE-less endpoints. > >> > >> > >> > >> Cheers > >> > >> > >> > >> -Espen > >> > >> > >> > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf Of Stephen Botzko > >> Sent: 27. mai 2011 13:16 > >> To: Elwell, John > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> I'm not sure that the language actually covers that (it seems > >> ambiguous). > >> > >> What do you think about changing "endpoints with different > >> capabilities" to "disparate devices"? > >> > >> Stephen > >> > >> > >> > >> On Fri, May 27, 2011 at 7:03 AM, Elwell, John > >> wrote: > >> > >> I thought requirement 10 would cover both > >> (signalling/protocol capabilities as well as user interface > >> capabilities). > >> > >> John > >> > >> > >> > >>> -----Original Message----- > >>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > >> > >>> Sent: 27 May 2011 11:53 > >>> To: Elwell, John > >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > >>> (pkyzivat); clue@ietf.org > >> > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> Do you think that the language in requirement 10 means "SIP > >>> capabilities"? Or something else? > >>> > >>> I am thinking that issue is really about the > >>> signaling/protocol design itself, and isn't directly related > >>> to how many screens and cameras a system might have. > >>> > >>> Stephen Botzko > >>> > >>> > >>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John > >>> wrote: > >>> > >>> > >>> Allyn, > >>> > >>> I already made a proposal: > >>> > >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >>> > >>> John > >>> > >>> > >>> > >>> > -----Original Message----- > >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>> > >>> > Sent: 26 May 2011 20:08 > >>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > >>> > Cc: clue@ietf.org > >>> > Subject: RE: [clue] legacy support in requirements > >>> > > >>> > Roni, Paul, John- > >>> > Would you care to suggest the wording you would like > >>> to see as a > >>> > requirement for legacy interoperability? That would > >>> be helpful. > >>> > > >>> > Thanks, > >>> > Allyn > >>> > > >>> > > -----Original Message----- > >>> > > From: clue-bounces@ietf.org > >>> [mailto:clue-bounces@ietf.org] On Behalf > >>> > Of > >>> > > Roni Even > >>> > > Sent: Wednesday, May 18, 2011 11:13 AM > >>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > >>> > > Cc: clue@ietf.org > >>> > > Subject: Re: [clue] legacy support in requirements > >>> > > > >>> > .... > >>> > > > >>> > > Anyhow we are discussing solution while my point > >> is that we > >>> > will need > >>> > > as a > >>> > > requirement to address the case of a call from a > >>> CLUE aware endpoint > >>> > to > >>> > > a > >>> > > non CLUE aware endpoint. Even if the consensus will > >>> be to have the > >>> > > preferred > >>> > > video in the first video m-line. > >>> > > > >>> > > Regards > >>> > > Roni > >>> > > > >>> > > > >>> > > > >>> > > > -----Original Message----- > >>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > >>> > > > Sent: Wednesday, May 18, 2011 4:41 PM > >>> > > > To: Paul Kyzivat (pkyzivat); Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: RE: [clue] legacy support in requirements > >>> > > > > >>> > > > Paul, > >>> > > > > >>> > > > I would agree that if the offer-answer model > >>> semantic is that here > >>> > > are > >>> > > > several options and any subset of options > is acceptable. > >>> > > > > >>> > > > However, if there is any grouping involved such > >>> that you need to > >>> > have > >>> > > a > >>> > > > video and audio feed integrated to make sense > >>> then watch out. > >>> > > > > >>> > > > For example, I wouldn't want to end up with the > >>> result of a man's > >>> > > video > >>> > > > paired with a woman's voice. That could be > >>> rather comical. > >>> > > > > >>> > > > Mike > >>> > > > > >>> > > > > >>> > > > -----Original Message----- > >>> > > > From: clue-bounces@ietf.org > >>> > [mailto:clue-bounces@ietf.org] On Behalf > >>> > > Of > >>> > > > Paul Kyzivat (pkyzivat) > >>> > > > Sent: Tuesday, May 17, 2011 7:45 PM > >>> > > > To: Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: Re: [clue] legacy support in requirements > >>> > > > > >>> > > > > >>> > > > > >>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >>> > > > > Paul, > >>> > > > > I think we read it differently. > >>> > > > > If the answerer does not support the > group attribute > >>> > and the offer > >>> > > > had > >>> > > > the > >>> > > > > fid semantics it may look to the answerer as an > >>> offer with > >>> > multiple > >>> > > > m-lines > >>> > > > > of the same media tyoe. In this case > an implementation > >>> > might also > >>> > > > decide to > >>> > > > > refuse the request (e.g., 488 Not Acceptable > >>> Here, or 606 Not > >>> > > > Acceptable), > >>> > > > > because it contains several "m" lines of the > >>> same media type. > >>> > > > > >>> > > > That is a slightly different story. > >>> > > > > >>> > > > Then the reason for rejection is not > because it saw an > >>> > attribute it > >>> > > > didn't understand - its because it didn't like > >>> something it *did* > >>> > > > understand. > >>> > > > > >>> > > > > This is very relevant to the multiple streams > >>> case and we should > >>> > > look > >>> > > > if we > >>> > > > > state this behavior or we will look at > providing an > >>> > approach that > >>> > > > will > >>> > > > allow > >>> > > > > the answerer to choose one m-line that > the offerer > >>> > prefers even of > >>> > > it > >>> > > > does > >>> > > > > not understand CLUE. > >>> > > > > >>> > > > IMO (lets see if others differ), if a UA receives > >>> an offer with at > >>> > > > least > >>> > > > > >>> > > > one m-line it is happy with, then it should not > >>> reject the call > >>> > > because > >>> > > > there are others that it does not "understand". > >>> > > > > >>> > > > Here "understand" means something different - > >>> presumably it does > >>> > > > understand the direct meaning of the additional > >>> m-line, it just > >>> > > doesn't > >>> > > > understand the *significance* or use of it. > >>> > > > > >>> > > > I see little difference to getting to > audio m-lines and > >>> > only wanting > >>> > > > one, and getting one audio and one video and only > >>> > supporting audio. > >>> > > In > >>> > > > general you should not reject an audio/video call > >>> just because you > >>> > > only > >>> > > > support audio. > >>> > > > > >>> > > > I think it will behoove clue to strongly > recommend that > >>> > the m-lines > >>> > > in > >>> > > > an offer be arranged so the first ones are the > >>> ones it most wants > >>> > > used > >>> > > > if not all are. > >>> > > > > >>> > > > Thanks, > >>> > > > Paul > >>> > > > > >>> > > > > Roni > >>> > > > > > >>> > > > >> -----Original Message----- > >>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > >>> > > > >> To: Roni Even > >>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > >>> > > > >> Subject: Re: [clue] legacy support in > requirements > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> > > > >>> Paul, > >>> > > > >>> Look at > >>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>> > > > example > >>> > > > >>> Roni > >>> > > > >> > >>> > > > >> OK, I looked. It is consistent with > what I said. > >>> > > > >> Either a=3Dgroup: is understood, or not. If not, > >>> its ignored, and > >>> > > not > >>> > > > put > >>> > > > >> in the answer. Same with a=3Dmid: > >>> > > > >> > >>> > > > >> If a=3Dgroup: *is* understood, but some > >> parameter within > >>> > it is not, > >>> > > > there > >>> > > > >> are explicit rules for what to do. > >>> > > > >> > >>> > > > >> AFAICT there are no examples in this document > >>> where failure to > >>> > > > >> understand an a-line in total (or even in > >>> part) results in > >>> > > rejecting > >>> > > > >> the > >>> > > > >> offer. > >>> > > > >> > >>> > > > >> Thanks, > >>> > > > >> Paul > >>> > > > >> > >>> > > > >>>> -----Original Message----- > >>> > > > >>>> From: clue-bounces@ietf.org > >>> [mailto:clue-bounces@ietf.org] On > >>> > > > Behalf > >>> > > > >> Of > >>> > > > >>>> Paul Kyzivat > >>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>> > > > >>>> To: Stephen Botzko > >>> > > > >>>> Cc: clue@ietf.org > >>> > > > >>>> Subject: Re: [clue] legacy support > in requirements > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>> > > > >>>> > >>> > > > >>>>> On 5/17/2011 2:24 AM, Roni > Even wrote: > >>> > > > >>>> > >>> > > > >>>>> When the offer includes > parameters that > >>> > the answerer > >>> > > > does > >>> > > > >> not > >>> > > > >>>>> understand > >>> > > > >>>>> there are two options, he can > >>> ignore the unknown > >>> > > > >> parameters > >>> > > > >>>> or > >>> > > > >>>>> reject > >>> > > > >>>>> the offer. > >>> > > > >>>>> Rejecting the offer in that case is > >>> not really kosher. > >>> > > > >>>>> You are required to ignore parameters > >>> you do not > >>> > > > understand. > >>> > > > >>>>> > >>> > > > >>>>> If you reject something because you > >>> don't like the > >>> > > > parameters > >>> > > > >> it > >>> > > > >>>>> contains, then that is an implicit > >>> statement that you > >>> > > > >> understand > >>> > > > >>>>> those parameters well enough to > >>> decide to reject them. > >>> > > > >>>>> > >>> > > > >>>>> As far as I know, you are always > free to reject > >>> > offers, and it > >>> > > > >>>> doesn't > >>> > > > >>>>> really imply anything when you do that.. > >>> Whether it is wise > >>> > is > >>> > > > >>>> perhaps > >>> > > > >>>>> a different question. > >>> > > > >>>>> Stephen Botzko > >>> > > > >>>> > >>> > > > >>>> Certainly you are always free to > reject an offer. > >>> > > > >>>> In general I don't know for certain > the reason why, > >>> > and so if I > >>> > > > give > >>> > > > >>>> you > >>> > > > >>>> the benefit of the doubt I will > assume you have a > >>> > valid reason > >>> > - > >>> > > > >>>> perhaps > >>> > > > >>>> just policy. > >>> > > > >>>> > >>> > > > >>>> But if the reason you reject the offer is > >>> based on your > >>> > > violating > >>> > > > a > >>> > > > >>>> spec, then you are non-conforming, > whether I can > >>> > determine you > >>> > > are > >>> > > > >>>> non-conforming or not. Whether being > >>> non-conforming is just > >>> > > > un-wise, > >>> > > > >> or > >>> > > > >>>> something stronger, is a separate > discussion. The > >>> > IETF does not > >>> > > > levy > >>> > > > >>>> any > >>> > > > >>>> penalties for violating its specs. But > >>> sometimes the market > >>> > > does. > >>> > > > >> (And > >>> > > > >>>> sometimes not.) But we don't need to endorse > >>> non-conforming > >>> > > > behavior > >>> > > > >> in > >>> > > > >>>> our documents. > >>> > > > >>>> > >>> > > > >>>> Thanks, > >>> > > > >>>> Paul > >>> > > > >>>> > _______________________________________________ > >>> > > > >>>> clue mailing list > >>> > > > >>>> clue@ietf.org > >>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > >>> > > > >>> > >>> > > > > > >>> > > > > > >>> > > > _______________________________________________ > >>> > > > clue mailing list > >>> > > > clue@ietf.org > >>> > > > https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > > _______________________________________________ > >>> > > clue mailing list > >>> > > clue@ietf.org > >>> > > https://www.ietf.org/mailman/listinfo/clue > >>> > > >>> _______________________________________________ > >>> 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 partr@cisco.com Fri May 27 07:06:13 2011 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 0B15BE06F7 for ; Fri, 27 May 2011 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.417 X-Spam-Level: X-Spam-Status: No, score=-10.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 MoQy6vauG-Oa for ; Fri, 27 May 2011 07:06:10 -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 1C3F6E06DD for ; Fri, 27 May 2011 07:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=19034; q=dns/txt; s=iport; t=1306505169; x=1307714769; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tFAPx9T3f4AtebtRitb0ScxkHlzAkexGC4BrOCqXKGo=; b=VaggcpUZcIN5R/to3ft8AZdf2mf0ADfmoQ/VuCfe+TZrYLJhQmDoj6TU lf9yiPDhy2n9Kg61QbS5z1zL9jRh674nFiGm17tO+05kB/SncBcFYP2v7 pzokKO6SAIPn62pCHQ4nkEhhDbXYVcG+aANid1ZHRtt/lGUvvsHTN1YtB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAKqv301Io8UT/2dsb2JhbAA2Hpdrjk53iHCeY5AljSuGHgSGYY4mhB6GOw X-IronPort-AV: E=Sophos;i="4.65,280,1304294400"; d="scan'208";a="32622979" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 27 May 2011 14:05:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4RE5te2021419; Fri, 27 May 2011 14:05:55 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 19:35:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 19:35:54 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcbkeociU79eYoRASVVB9uolX4rQAB0sHAAAAdyIA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com><4DDFA0C8.1050509@cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 27 May 2011 14:05:54.0937 (UTC) FILETIME=[31D10690:01CC1C77] Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 14:06:13 -0000 Paul, I have the doubt whether this requirement has to be "MUST" or "SHOULD" because CLUE (telepresence) end-point may not like to interop with simple audio end-point (SIP UA). It may be just policy not to received audio-call in CLUE endpoint because of better utilization of costly resources. Please let me know your opinion here.=20 Apart from this doubt, I like your requirement proposal. Thanks Partha -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, May 27, 2011 7:25 PM To: Paul Kyzivat (pkyzivat); clue@ietf.org Subject: Re: [clue] legacy support in requirements Yes, I like Paul's changes. John > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 27 May 2011 14:02 > To: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/27/2011 8:28 AM, Elwell, John wrote: > > I can live with Steve's proposal. I also don't mind > separating the requirements, but I don't think we should refer to CLUE > in the requirement - the RFC will live a long time after CLUE is=20 > finished and closed down. So if we want to separate the requirements,=20 > I would propose: > > > > REQMT-10: The solution MUST include a mechanism that makes > it possible for endpoints with different capabilities to interoperate=20 > in a telepresence conference. > > REQMT-10bis: The solution MUST include a mechanism that > makes it possible for endpoints without support for telepresence=20 > extensions to participate in a telepresence conference with those that > do. > > How about the following variant of that: > > REQMT-10bis: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a telepresence=20 > session with those that do. > > I dropped "mechanism" because its unlikely to be a new mechanism that=20 > makes this possible. (That would require changes to the legacy=20 > systems.) Rather it will need to be the manner of using existing=20 > mechanisms. > > And I changed "telepresence conference" to "telepresence session" > because this ought to work point-point as well as for conferences. > (But we probably need more definition work here, since neither=20 > telepresence-conference nor telepresence-session is currently > defined.) > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >> Sent: 27 May 2011 12:23 > >> To: Stephen Botzko; Elwell, John > >> Cc: clue@ietf.org > >> Subject: RE: [clue] legacy support in requirements > >> > >> I think it would be clearer to formulate two different requirements > >> > >> > >> > >> 1) Two solution must provide a mechanism that make it > >> possible for endpoints with different capabilities to interoperate, > >> e.g. interoperability between a 2 camera/screens and 3=20 > >> camera/screens endpoint. > >> > >> 2) Two solution must provide a mechanism that make it > >> possible for endpoints that are CLUE aware to interoperate with=20 > >> CLUE-less endpoints. > >> > >> > >> > >> Cheers > >> > >> > >> > >> -Espen > >> > >> > >> > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Stephen Botzko > >> Sent: 27. mai 2011 13:16 > >> To: Elwell, John > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> I'm not sure that the language actually covers that (it seems=20 > >> ambiguous). > >> > >> What do you think about changing "endpoints with different=20 > >> capabilities" to "disparate devices"? > >> > >> Stephen > >> > >> > >> > >> On Fri, May 27, 2011 at 7:03 AM, Elwell, John=20 > >> wrote: > >> > >> I thought requirement 10 would cover both (signalling/protocol=20 > >> capabilities as well as user interface capabilities). > >> > >> John > >> > >> > >> > >>> -----Original Message----- > >>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > >> > >>> Sent: 27 May 2011 11:53 > >>> To: Elwell, John > >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat);=20 > >>> clue@ietf.org > >> > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> Do you think that the language in requirement 10 means "SIP=20 > >>> capabilities"? Or something else? > >>> > >>> I am thinking that issue is really about the signaling/protocol=20 > >>> design itself, and isn't directly related to how many screens and=20 > >>> cameras a system might have. > >>> > >>> Stephen Botzko > >>> > >>> > >>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John=20 > >>> wrote: > >>> > >>> > >>> Allyn, > >>> > >>> I already made a proposal: > >>> > >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >>> > >>> John > >>> > >>> > >>> > >>> > -----Original Message----- > >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>> > >>> > Sent: 26 May 2011 20:08 > >>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > >>> > Cc: clue@ietf.org > >>> > Subject: RE: [clue] legacy support in requirements > >>> > > >>> > Roni, Paul, John- > >>> > Would you care to suggest the wording you would like to=20 > >>> see as a > >>> > requirement for legacy interoperability? That would be=20 > >>> helpful. > >>> > > >>> > Thanks, > >>> > Allyn > >>> > > >>> > > -----Original Message----- > >>> > > From: clue-bounces@ietf.org=20 > >>> [mailto:clue-bounces@ietf.org] On Behalf > >>> > Of > >>> > > Roni Even > >>> > > Sent: Wednesday, May 18, 2011 11:13 AM > >>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > >>> > > Cc: clue@ietf.org > >>> > > Subject: Re: [clue] legacy support in requirements > >>> > > > >>> > .... > >>> > > > >>> > > Anyhow we are discussing solution while my point > >> is that we > >>> > will need > >>> > > as a > >>> > > requirement to address the case of a call from a CLUE > >>> aware endpoint > >>> > to > >>> > > a > >>> > > non CLUE aware endpoint. Even if the consensus will=20 > >>> be to have the > >>> > > preferred > >>> > > video in the first video m-line. > >>> > > > >>> > > Regards > >>> > > Roni > >>> > > > >>> > > > >>> > > > >>> > > > -----Original Message----- > >>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > >>> > > > Sent: Wednesday, May 18, 2011 4:41 PM > >>> > > > To: Paul Kyzivat (pkyzivat); Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: RE: [clue] legacy support in requirements > >>> > > > > >>> > > > Paul, > >>> > > > > >>> > > > I would agree that if the offer-answer model=20 > >>> semantic is that here > >>> > > are > >>> > > > several options and any subset of options > is acceptable. > >>> > > > > >>> > > > However, if there is any grouping involved such=20 > >>> that you need to > >>> > have > >>> > > a > >>> > > > video and audio feed integrated to make sense then > >>> watch out. > >>> > > > > >>> > > > For example, I wouldn't want to end up with the=20 > >>> result of a man's > >>> > > video > >>> > > > paired with a woman's voice. That could be rather > >>> comical. > >>> > > > > >>> > > > Mike > >>> > > > > >>> > > > > >>> > > > -----Original Message----- > >>> > > > From: clue-bounces@ietf.org > >>> > [mailto:clue-bounces@ietf.org] On Behalf > >>> > > Of > >>> > > > Paul Kyzivat (pkyzivat) > >>> > > > Sent: Tuesday, May 17, 2011 7:45 PM > >>> > > > To: Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: Re: [clue] legacy support in requirements > >>> > > > > >>> > > > > >>> > > > > >>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >>> > > > > Paul, > >>> > > > > I think we read it differently. > >>> > > > > If the answerer does not support the > group attribute > >>> > and the offer > >>> > > > had > >>> > > > the > >>> > > > > fid semantics it may look to the answerer as an > >>> offer with > >>> > multiple > >>> > > > m-lines > >>> > > > > of the same media tyoe. In this case > an implementation > >>> > might also > >>> > > > decide to > >>> > > > > refuse the request (e.g., 488 Not Acceptable=20 > >>> Here, or 606 Not > >>> > > > Acceptable), > >>> > > > > because it contains several "m" lines of the=20 > >>> same media type. > >>> > > > > >>> > > > That is a slightly different story. > >>> > > > > >>> > > > Then the reason for rejection is not > because it saw an > >>> > attribute it > >>> > > > didn't understand - its because it didn't like=20 > >>> something it *did* > >>> > > > understand. > >>> > > > > >>> > > > > This is very relevant to the multiple streams=20 > >>> case and we should > >>> > > look > >>> > > > if we > >>> > > > > state this behavior or we will look at > providing an > >>> > approach that > >>> > > > will > >>> > > > allow > >>> > > > > the answerer to choose one m-line that > the offerer > >>> > prefers even of > >>> > > it > >>> > > > does > >>> > > > > not understand CLUE. > >>> > > > > >>> > > > IMO (lets see if others differ), if a UA receives=20 > >>> an offer with at > >>> > > > least > >>> > > > > >>> > > > one m-line it is happy with, then it should not=20 > >>> reject the call > >>> > > because > >>> > > > there are others that it does not "understand". > >>> > > > > >>> > > > Here "understand" means something different -=20 > >>> presumably it does > >>> > > > understand the direct meaning of the additional=20 > >>> m-line, it just > >>> > > doesn't > >>> > > > understand the *significance* or use of it. > >>> > > > > >>> > > > I see little difference to getting to > audio m-lines and > >>> > only wanting > >>> > > > one, and getting one audio and one video and only > >>> > supporting audio. > >>> > > In > >>> > > > general you should not reject an audio/video call=20 > >>> just because you > >>> > > only > >>> > > > support audio. > >>> > > > > >>> > > > I think it will behoove clue to strongly > recommend that > >>> > the m-lines > >>> > > in > >>> > > > an offer be arranged so the first ones are the=20 > >>> ones it most wants > >>> > > used > >>> > > > if not all are. > >>> > > > > >>> > > > Thanks, > >>> > > > Paul > >>> > > > > >>> > > > > Roni > >>> > > > > > >>> > > > >> -----Original Message----- > >>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > >>> > > > >> To: Roni Even > >>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > >>> > > > >> Subject: Re: [clue] legacy support in > requirements > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> > > > >>> Paul, > >>> > > > >>> Look at > >>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>> > > > example > >>> > > > >>> Roni > >>> > > > >> > >>> > > > >> OK, I looked. It is consistent with > what I said. > >>> > > > >> Either a=3Dgroup: is understood, or not. If = not, > >>> its ignored, and > >>> > > not > >>> > > > put > >>> > > > >> in the answer. Same with a=3Dmid: > >>> > > > >> > >>> > > > >> If a=3Dgroup: *is* understood, but some > >> parameter within > >>> > it is not, > >>> > > > there > >>> > > > >> are explicit rules for what to do. > >>> > > > >> > >>> > > > >> AFAICT there are no examples in this document=20 > >>> where failure to > >>> > > > >> understand an a-line in total (or even in > >>> part) results in > >>> > > rejecting > >>> > > > >> the > >>> > > > >> offer. > >>> > > > >> > >>> > > > >> Thanks, > >>> > > > >> Paul > >>> > > > >> > >>> > > > >>>> -----Original Message----- > >>> > > > >>>> From: clue-bounces@ietf.org=20 > >>> [mailto:clue-bounces@ietf.org] On > >>> > > > Behalf > >>> > > > >> Of > >>> > > > >>>> Paul Kyzivat > >>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>> > > > >>>> To: Stephen Botzko > >>> > > > >>>> Cc: clue@ietf.org > >>> > > > >>>> Subject: Re: [clue] legacy support > in requirements > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>> > > > >>>> > >>> > > > >>>>> On 5/17/2011 2:24 AM, Roni > Even wrote: > >>> > > > >>>> > >>> > > > >>>>> When the offer includes > parameters that > >>> > the answerer > >>> > > > does > >>> > > > >> not > >>> > > > >>>>> understand > >>> > > > >>>>> there are two options, he can > >>> ignore the unknown > >>> > > > >> parameters > >>> > > > >>>> or > >>> > > > >>>>> reject > >>> > > > >>>>> the offer. > >>> > > > >>>>> Rejecting the offer in that case is > >>> not really kosher. > >>> > > > >>>>> You are required to ignore parameters > >>> you do not > >>> > > > understand. > >>> > > > >>>>> > >>> > > > >>>>> If you reject something because you > >>> don't like the > >>> > > > parameters > >>> > > > >> it > >>> > > > >>>>> contains, then that is an implicit > >>> statement that you > >>> > > > >> understand > >>> > > > >>>>> those parameters well enough to > >>> decide to reject them. > >>> > > > >>>>> > >>> > > > >>>>> As far as I know, you are always > free to reject > >>> > offers, and it > >>> > > > >>>> doesn't > >>> > > > >>>>> really imply anything when you do that.. > >>> Whether it is wise > >>> > is > >>> > > > >>>> perhaps > >>> > > > >>>>> a different question. > >>> > > > >>>>> Stephen Botzko > >>> > > > >>>> > >>> > > > >>>> Certainly you are always free to > reject an offer. > >>> > > > >>>> In general I don't know for certain > the reason why, > >>> > and so if I > >>> > > > give > >>> > > > >>>> you > >>> > > > >>>> the benefit of the doubt I will > assume you have a > >>> > valid reason > >>> > - > >>> > > > >>>> perhaps > >>> > > > >>>> just policy. > >>> > > > >>>> > >>> > > > >>>> But if the reason you reject the offer is=20 > >>> based on your > >>> > > violating > >>> > > > a > >>> > > > >>>> spec, then you are non-conforming, > whether I can > >>> > determine you > >>> > > are > >>> > > > >>>> non-conforming or not. Whether being=20 > >>> non-conforming is just > >>> > > > un-wise, > >>> > > > >> or > >>> > > > >>>> something stronger, is a separate > discussion. The > >>> > IETF does not > >>> > > > levy > >>> > > > >>>> any > >>> > > > >>>> penalties for violating its specs. But=20 > >>> sometimes the market > >>> > > does. > >>> > > > >> (And > >>> > > > >>>> sometimes not.) But we don't need to endorse > >>> non-conforming > >>> > > > behavior > >>> > > > >> in > >>> > > > >>>> our documents. > >>> > > > >>>> > >>> > > > >>>> Thanks, > >>> > > > >>>> Paul > >>> > > > >>>> > _______________________________________________ > >>> > > > >>>> clue mailing list > >>> > > > >>>> clue@ietf.org > >>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > >>> > > > >>> > >>> > > > > > >>> > > > > > >>> > > > _______________________________________________ > >>> > > > clue mailing list > >>> > > > clue@ietf.org > >>> > > > https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > > _______________________________________________ > >>> > > clue mailing list > >>> > > clue@ietf.org > >>> > > https://www.ietf.org/mailman/listinfo/clue > >>> > > >>> _______________________________________________ > >>> 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 john.elwell@siemens-enterprise.com Fri May 27 07:10:32 2011 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 60EF8E06DD for ; Fri, 27 May 2011 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 yLF8Lof4j1yG for ; Fri, 27 May 2011 07:10:30 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 15024E06DA for ; Fri, 27 May 2011 07:10:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1306505421!25314727!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 30857 invoked from network); 27 May 2011 14:10:21 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-27.messagelabs.com with SMTP; 27 May 2011 14:10:21 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7548523F03EA; Fri, 27 May 2011 16:10:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 27 May 2011 16:10:28 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "clue@ietf.org" Date: Fri, 27 May 2011 16:10:26 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwcbkeociU79eYoRASVVB9uolX4rQAB0sHAAAAdyIAAAGvK8A== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com><4DDFA0C8.1050509@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 14:10:32 -0000 The requirement is on the solution. The solution must provide this capabili= ty, even though some deployments might not wish to use it. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 27 May 2011 15:06 > To: Elwell, John; Paul Kyzivat (pkyzivat); clue@ietf.org > Subject: RE: [clue] legacy support in requirements > > Paul, > > I have the doubt whether this requirement has to be "MUST" or "SHOULD" > because CLUE (telepresence) end-point may not like to interop with > simple audio end-point (SIP UA). It may be just policy not to received > audio-call in CLUE endpoint because of better utilization of costly > resources. Please let me know your opinion here. > > Apart from this doubt, I like your requirement proposal. > > Thanks > Partha > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of > Elwell, John > Sent: Friday, May 27, 2011 7:25 PM > To: Paul Kyzivat (pkyzivat); clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > Yes, I like Paul's changes. > > John > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > On Behalf > > Of Paul Kyzivat > > Sent: 27 May 2011 14:02 > > To: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > > > > > > > > On 5/27/2011 8:28 AM, Elwell, John wrote: > > > I can live with Steve's proposal. I also don't mind > > separating the requirements, but I don't think we should > refer to CLUE > > > in the requirement - the RFC will live a long time after CLUE is > > finished and closed down. So if we want to separate the > requirements, > > I would propose: > > > > > > REQMT-10: The solution MUST include a mechanism that makes > > it possible for endpoints with different capabilities to > interoperate > > in a telepresence conference. > > > REQMT-10bis: The solution MUST include a mechanism that > > makes it possible for endpoints without support for telepresence > > extensions to participate in a telepresence conference with > those that > > > do. > > > > How about the following variant of that: > > > > REQMT-10bis: The solution MUST make it possible for > endpoints without > > > support for telepresence extensions to participate in a > telepresence > > session with those that do. > > > > I dropped "mechanism" because its unlikely to be a new > mechanism that > > makes this possible. (That would require changes to the legacy > > systems.) Rather it will need to be the manner of using existing > > mechanisms. > > > > And I changed "telepresence conference" to "telepresence session" > > because this ought to work point-point as well as for conferences. > > (But we probably need more definition work here, since neither > > telepresence-conference nor telepresence-session is currently > > defined.) > > > > Thanks, > > Paul > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > >> Sent: 27 May 2011 12:23 > > >> To: Stephen Botzko; Elwell, John > > >> Cc: clue@ietf.org > > >> Subject: RE: [clue] legacy support in requirements > > >> > > >> I think it would be clearer to formulate two different > requirements > > >> > > >> > > >> > > >> 1) Two solution must provide a mechanism that make it > > >> possible for endpoints with different capabilities to > interoperate, > > > >> e.g. interoperability between a 2 camera/screens and 3 > > >> camera/screens endpoint. > > >> > > >> 2) Two solution must provide a mechanism that make it > > >> possible for endpoints that are CLUE aware to interoperate with > > >> CLUE-less endpoints. > > >> > > >> > > >> > > >> Cheers > > >> > > >> > > >> > > >> -Espen > > >> > > >> > > >> > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > >> Behalf Of Stephen Botzko > > >> Sent: 27. mai 2011 13:16 > > >> To: Elwell, John > > >> Cc: clue@ietf.org > > >> Subject: Re: [clue] legacy support in requirements > > >> > > >> > > >> > > >> I'm not sure that the language actually covers that (it seems > > >> ambiguous). > > >> > > >> What do you think about changing "endpoints with different > > >> capabilities" to "disparate devices"? > > >> > > >> Stephen > > >> > > >> > > >> > > >> On Fri, May 27, 2011 at 7:03 AM, Elwell, John > > >> wrote: > > >> > > >> I thought requirement 10 would cover both (signalling/protocol > > >> capabilities as well as user interface capabilities). > > >> > > >> John > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > >> > > >>> Sent: 27 May 2011 11:53 > > >>> To: Elwell, John > > >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat); > > >>> clue@ietf.org > > >> > > >>> Subject: Re: [clue] legacy support in requirements > > >>> > > >>> Do you think that the language in requirement 10 means "SIP > > >>> capabilities"? Or something else? > > >>> > > >>> I am thinking that issue is really about the signaling/protocol > > >>> design itself, and isn't directly related to how many > screens and > > >>> cameras a system might have. > > >>> > > >>> Stephen Botzko > > >>> > > >>> > > >>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John > > >>> wrote: > > >>> > > >>> > > >>> Allyn, > > >>> > > >>> I already made a proposal: > > >>> > > >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > > >>> > > >>> John > > >>> > > >>> > > >>> > > >>> > -----Original Message----- > > >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > >>> > > >>> > Sent: 26 May 2011 20:08 > > >>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > >>> > Cc: clue@ietf.org > > >>> > Subject: RE: [clue] legacy support in requirements > > >>> > > > >>> > Roni, Paul, John- > > >>> > Would you care to suggest the wording you > would like to > > >>> see as a > > >>> > requirement for legacy interoperability? That > would be > > >>> helpful. > > >>> > > > >>> > Thanks, > > >>> > Allyn > > >>> > > > >>> > > -----Original Message----- > > >>> > > From: clue-bounces@ietf.org > > >>> [mailto:clue-bounces@ietf.org] On Behalf > > >>> > Of > > >>> > > Roni Even > > >>> > > Sent: Wednesday, May 18, 2011 11:13 AM > > >>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > >>> > > Cc: clue@ietf.org > > >>> > > Subject: Re: [clue] legacy support in requirements > > >>> > > > > >>> > .... > > >>> > > > > >>> > > Anyhow we are discussing solution while my point > > >> is that we > > >>> > will need > > >>> > > as a > > >>> > > requirement to address the case of a call > from a CLUE > > > >>> aware endpoint > > >>> > to > > >>> > > a > > >>> > > non CLUE aware endpoint. Even if the > consensus will > > >>> be to have the > > >>> > > preferred > > >>> > > video in the first video m-line. > > >>> > > > > >>> > > Regards > > >>> > > Roni > > >>> > > > > >>> > > > > >>> > > > > >>> > > > -----Original Message----- > > >>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > >>> > > > Sent: Wednesday, May 18, 2011 4:41 PM > > >>> > > > To: Paul Kyzivat (pkyzivat); Roni Even > > >>> > > > Cc: clue@ietf.org > > >>> > > > Subject: RE: [clue] legacy support in > requirements > > >>> > > > > > >>> > > > Paul, > > >>> > > > > > >>> > > > I would agree that if the offer-answer model > > >>> semantic is that here > > >>> > > are > > >>> > > > several options and any subset of options > > is acceptable. > > >>> > > > > > >>> > > > However, if there is any grouping involved such > > >>> that you need to > > >>> > have > > >>> > > a > > >>> > > > video and audio feed integrated to make > sense then > > > >>> watch out. > > >>> > > > > > >>> > > > For example, I wouldn't want to end up with the > > >>> result of a man's > > >>> > > video > > >>> > > > paired with a woman's voice. That > could be rather > > > >>> comical. > > >>> > > > > > >>> > > > Mike > > >>> > > > > > >>> > > > > > >>> > > > -----Original Message----- > > >>> > > > From: clue-bounces@ietf.org > > >>> > [mailto:clue-bounces@ietf.org] On Behalf > > >>> > > Of > > >>> > > > Paul Kyzivat (pkyzivat) > > >>> > > > Sent: Tuesday, May 17, 2011 7:45 PM > > >>> > > > To: Roni Even > > >>> > > > Cc: clue@ietf.org > > >>> > > > Subject: Re: [clue] legacy support in > requirements > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > >>> > > > > Paul, > > >>> > > > > I think we read it differently. > > >>> > > > > If the answerer does not support the > > group attribute > > >>> > and the offer > > >>> > > > had > > >>> > > > the > > >>> > > > > fid semantics it may look to the > answerer as an > > > >>> offer with > > >>> > multiple > > >>> > > > m-lines > > >>> > > > > of the same media tyoe. In this case > > an implementation > > >>> > might also > > >>> > > > decide to > > >>> > > > > refuse the request (e.g., 488 Not Acceptable > > >>> Here, or 606 Not > > >>> > > > Acceptable), > > >>> > > > > because it contains several "m" lines of the > > >>> same media type. > > >>> > > > > > >>> > > > That is a slightly different story. > > >>> > > > > > >>> > > > Then the reason for rejection is not > > because it saw an > > >>> > attribute it > > >>> > > > didn't understand - its because it didn't like > > >>> something it *did* > > >>> > > > understand. > > >>> > > > > > >>> > > > > This is very relevant to the > multiple streams > > >>> case and we should > > >>> > > look > > >>> > > > if we > > >>> > > > > state this behavior or we will look at > > providing an > > >>> > approach that > > >>> > > > will > > >>> > > > allow > > >>> > > > > the answerer to choose one m-line that > > the offerer > > >>> > prefers even of > > >>> > > it > > >>> > > > does > > >>> > > > > not understand CLUE. > > >>> > > > > > >>> > > > IMO (lets see if others differ), if a > UA receives > > >>> an offer with at > > >>> > > > least > > >>> > > > > > >>> > > > one m-line it is happy with, then it should not > > >>> reject the call > > >>> > > because > > >>> > > > there are others that it does not "understand". > > >>> > > > > > >>> > > > Here "understand" means something different - > > >>> presumably it does > > >>> > > > understand the direct meaning of the additional > > >>> m-line, it just > > >>> > > doesn't > > >>> > > > understand the *significance* or use of it. > > >>> > > > > > >>> > > > I see little difference to getting to > > audio m-lines and > > >>> > only wanting > > >>> > > > one, and getting one audio and one > video and only > > >>> > supporting audio. > > >>> > > In > > >>> > > > general you should not reject an > audio/video call > > >>> just because you > > >>> > > only > > >>> > > > support audio. > > >>> > > > > > >>> > > > I think it will behoove clue to strongly > > recommend that > > >>> > the m-lines > > >>> > > in > > >>> > > > an offer be arranged so the first ones are the > > >>> ones it most wants > > >>> > > used > > >>> > > > if not all are. > > >>> > > > > > >>> > > > Thanks, > > >>> > > > Paul > > >>> > > > > > >>> > > > > Roni > > >>> > > > > > > >>> > > > >> -----Original Message----- > > >>> > > > >> From: Paul Kyzivat > [mailto:pkyzivat@cisco.com] > > >>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > >>> > > > >> To: Roni Even > > >>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > >>> > > > >> Subject: Re: [clue] legacy support in > > requirements > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > >>> > > > >>> Paul, > > >>> > > > >>> Look at > > >>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > >>> > > > example > > >>> > > > >>> Roni > > >>> > > > >> > > >>> > > > >> OK, I looked. It is consistent with > > what I said. > > >>> > > > >> Either a=3Dgroup: is understood, or > not. If not, > > > >>> its ignored, and > > >>> > > not > > >>> > > > put > > >>> > > > >> in the answer. Same with a=3Dmid: > > >>> > > > >> > > >>> > > > >> If a=3Dgroup: *is* understood, but some > > >> parameter within > > >>> > it is not, > > >>> > > > there > > >>> > > > >> are explicit rules for what to do. > > >>> > > > >> > > >>> > > > >> AFAICT there are no examples in > this document > > >>> where failure to > > >>> > > > >> understand an a-line in total (or even in > > >>> part) results in > > >>> > > rejecting > > >>> > > > >> the > > >>> > > > >> offer. > > >>> > > > >> > > >>> > > > >> Thanks, > > >>> > > > >> Paul > > >>> > > > >> > > >>> > > > >>>> -----Original Message----- > > >>> > > > >>>> From: clue-bounces@ietf.org > > >>> [mailto:clue-bounces@ietf.org] On > > >>> > > > Behalf > > >>> > > > >> Of > > >>> > > > >>>> Paul Kyzivat > > >>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > >>> > > > >>>> To: Stephen Botzko > > >>> > > > >>>> Cc: clue@ietf.org > > >>> > > > >>>> Subject: Re: [clue] legacy support > > in requirements > > >>> > > > >>>> > > >>> > > > >>>> > > >>> > > > >>>> > > >>> > > > >>>> On 5/17/2011 10:34 AM, Stephen > Botzko wrote: > > >>> > > > >>>> > > >>> > > > >>>>> On 5/17/2011 2:24 AM, Roni > > Even wrote: > > >>> > > > >>>> > > >>> > > > >>>>> When the offer includes > > parameters that > > >>> > the answerer > > >>> > > > does > > >>> > > > >> not > > >>> > > > >>>>> understand > > >>> > > > >>>>> there are two options, he can > > >>> ignore the unknown > > >>> > > > >> parameters > > >>> > > > >>>> or > > >>> > > > >>>>> reject > > >>> > > > >>>>> the offer. > > >>> > > > >>>>> Rejecting the offer in that case is > > >>> not really kosher. > > >>> > > > >>>>> You are required to ignore > parameters > > >>> you do not > > >>> > > > understand. > > >>> > > > >>>>> > > >>> > > > >>>>> If you reject something because you > > >>> don't like the > > >>> > > > parameters > > >>> > > > >> it > > >>> > > > >>>>> contains, then that is an implicit > > >>> statement that you > > >>> > > > >> understand > > >>> > > > >>>>> those parameters well enough to > > >>> decide to reject them. > > >>> > > > >>>>> > > >>> > > > >>>>> As far as I know, you are always > > free to reject > > >>> > offers, and it > > >>> > > > >>>> doesn't > > >>> > > > >>>>> really imply anything when you do that.. > > >>> Whether it is wise > > >>> > is > > >>> > > > >>>> perhaps > > >>> > > > >>>>> a different question. > > >>> > > > >>>>> Stephen Botzko > > >>> > > > >>>> > > >>> > > > >>>> Certainly you are always free to > > reject an offer. > > >>> > > > >>>> In general I don't know for certain > > the reason why, > > >>> > and so if I > > >>> > > > give > > >>> > > > >>>> you > > >>> > > > >>>> the benefit of the doubt I will > > assume you have a > > >>> > valid reason > > >>> > - > > >>> > > > >>>> perhaps > > >>> > > > >>>> just policy. > > >>> > > > >>>> > > >>> > > > >>>> But if the reason you reject the offer is > > >>> based on your > > >>> > > violating > > >>> > > > a > > >>> > > > >>>> spec, then you are non-conforming, > > whether I can > > >>> > determine you > > >>> > > are > > >>> > > > >>>> non-conforming or not. Whether being > > >>> non-conforming is just > > >>> > > > un-wise, > > >>> > > > >> or > > >>> > > > >>>> something stronger, is a separate > > discussion. The > > >>> > IETF does not > > >>> > > > levy > > >>> > > > >>>> any > > >>> > > > >>>> penalties for violating its specs. But > > >>> sometimes the market > > >>> > > does. > > >>> > > > >> (And > > >>> > > > >>>> sometimes not.) But we don't need > to endorse > > > >>> non-conforming > > >>> > > > behavior > > >>> > > > >> in > > >>> > > > >>>> our documents. > > >>> > > > >>>> > > >>> > > > >>>> Thanks, > > >>> > > > >>>> Paul > > >>> > > > >>>> > > _______________________________________________ > > >>> > > > >>>> clue mailing list > > >>> > > > >>>> clue@ietf.org > > >>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > > >>> > > >>> > > > >>> > > >>> > > > > > > >>> > > > > > > >>> > > > _______________________________________________ > > >>> > > > clue mailing list > > >>> > > > clue@ietf.org > > >>> > > > https://www.ietf.org/mailman/listinfo/clue > > >>> > > > > >>> > > _______________________________________________ > > >>> > > clue mailing list > > >>> > > clue@ietf.org > > >>> > > https://www.ietf.org/mailman/listinfo/clue > > >>> > > > >>> _______________________________________________ > > >>> 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 allyn@cisco.com Fri May 27 08:39:08 2011 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 EF768E0807 for ; Fri, 27 May 2011 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7FA7bNjjYogq for ; Fri, 27 May 2011 08:39:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDBEE0802 for ; Fri, 27 May 2011 08:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=10116; q=dns/txt; s=iport; t=1306510747; x=1307720347; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jGfn0gA1wUIbXnYVQzo4KFQ6ncMtaQ9hMFU7Mh0ltgM=; b=Fow8QBlS92YKt2lWg8ZEW4pwr03xr/ESqsFXJlo+L141Ru9VOHPljpCs aoMZ3FgxhSJnQFVdwmrAU5hf23HzkqsLU8OHr9wmX60BUIHFyGYNH7aG6 yz+u9hK760heZlXFpqnR5DPZORHtiHhT1I32C5mLelM05M9MfvXYd6/f6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBANbE302rRDoG/2dsb2JhbAA2Hpdrjk53qC6QJY0rhh4EhmOOJIpx X-IronPort-AV: E=Sophos;i="4.65,280,1304294400"; d="scan'208";a="704489004" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 27 May 2011 15:39:05 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4RFd5J3002240; Fri, 27 May 2011 15:39:05 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 08:39:05 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 08:39:04 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B8535@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQAAlDx0ABk+wMgAAYLHfQABL9JZA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Elwell, John" , "Roni Even" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 27 May 2011 15:39:05.0475 (UTC) FILETIME=[36096D30:01CC1C84] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 15:39:09 -0000 Hi John,=20 Your suggestion is The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference, including audio/video endpoints that do not support any telepresence extensions. I have redone the requirements so that the reqmt for heterogeneous devices as in the use case, which was reqmt 10, is now more specific. So, we would not piggy back legacy on the hetereogeneity requirement. Assuming this now refers only to the interaction of CLUE and non-CLUE, the problem is that they don't interoperate in a telepresence sense- the purpose for the WG. Therefore, I would ask you to be more specific about the legacy requirement. I should think that the general meaning would be along the lines of that CLUE would not break any existing interworking - however this is general, and it would be good to make it more specific. I think it would be really helpful if you Paul and Roni, and others if they wish, could suggest some new text to more specifically cover what you have in mind which has been discussed in detail on the list. Thanks, Allyn =20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, May 26, 2011 11:22 PM To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) Cc: clue@ietf.org Subject: RE: [clue] legacy support in requirements Allyn, I already made a proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00221.html John =20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: 26 May 2011 20:08 > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > Roni, Paul, John- > Would you care to suggest the wording you would like to see as a > requirement for legacy interoperability? That would be helpful. >=20 > Thanks, > Allyn >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Roni Even > > Sent: Wednesday, May 18, 2011 11:13 AM > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > Cc: clue@ietf.org > > Subject: Re: [clue] legacy support in requirements > >=20 > .... > >=20 > > Anyhow we are discussing solution while my point is that we=20 > will need > > as a > > requirement to address the case of a call from a CLUE aware endpoint > to > > a > > non CLUE aware endpoint. Even if the consensus will be to have the > > preferred > > video in the first video m-line. > >=20 > > Regards > > Roni > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > Paul, > > > > > > I would agree that if the offer-answer model semantic is that here > > are > > > several options and any subset of options is acceptable. > > > > > > However, if there is any grouping involved such that you need to > have > > a > > > video and audio feed integrated to make sense then watch out. > > > > > > For example, I wouldn't want to end up with the result of a man's > > video > > > paired with a woman's voice. That could be rather comical. > > > > > > Mike > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Paul Kyzivat (pkyzivat) > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > To: Roni Even > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > Paul, > > > > I think we read it differently. > > > > If the answerer does not support the group attribute=20 > and the offer > > > had > > > the > > > > fid semantics it may look to the answerer as an offer with > multiple > > > m-lines > > > > of the same media tyoe. In this case an implementation=20 > might also > > > decide to > > > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > > Acceptable), > > > > because it contains several "m" lines of the same media type. > > > > > > That is a slightly different story. > > > > > > Then the reason for rejection is not because it saw an=20 > attribute it > > > didn't understand - its because it didn't like something it *did* > > > understand. > > > > > > > This is very relevant to the multiple streams case and we should > > look > > > if we > > > > state this behavior or we will look at providing an=20 > approach that > > > will > > > allow > > > > the answerer to choose one m-line that the offerer=20 > prefers even of > > it > > > does > > > > not understand CLUE. > > > > > > IMO (lets see if others differ), if a UA receives an offer with at > > > least > > > > > > one m-line it is happy with, then it should not reject the call > > because > > > there are others that it does not "understand". > > > > > > Here "understand" means something different - presumably it does > > > understand the direct meaning of the additional m-line, it just > > doesn't > > > understand the *significance* or use of it. > > > > > > I see little difference to getting to audio m-lines and=20 > only wanting > > > one, and getting one audio and one video and only=20 > supporting audio. > > In > > > general you should not reject an audio/video call just because you > > only > > > support audio. > > > > > > I think it will behoove clue to strongly recommend that=20 > the m-lines > > in > > > an offer be arranged so the first ones are the ones it most wants > > used > > > if not all are. > > > > > > Thanks, > > > Paul > > > > > > > Roni > > > > > > > >> -----Original Message----- > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > >> To: Roni Even > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > >> Subject: Re: [clue] legacy support in requirements > > > >> > > > >> > > > >> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > >>> Paul, > > > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > example > > > >>> Roni > > > >> > > > >> OK, I looked. It is consistent with what I said. > > > >> Either a=3Dgroup: is understood, or not. If not, its ignored, = and > > not > > > put > > > >> in the answer. Same with a=3Dmid: > > > >> > > > >> If a=3Dgroup: *is* understood, but some parameter within=20 > it is not, > > > there > > > >> are explicit rules for what to do. > > > >> > > > >> AFAICT there are no examples in this document where failure to > > > >> understand an a-line in total (or even in part) results in > > rejecting > > > >> the > > > >> offer. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >>>> -----Original Message----- > > > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf > > > >> Of > > > >>>> Paul Kyzivat > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > >>>> To: Stephen Botzko > > > >>>> Cc: clue@ietf.org > > > >>>> Subject: Re: [clue] legacy support in requirements > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > >>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > >>>> > > > >>>>> When the offer includes parameters that=20 > the answerer > > > does > > > >> not > > > >>>>> understand > > > >>>>> there are two options, he can ignore the unknown > > > >> parameters > > > >>>> or > > > >>>>> reject > > > >>>>> the offer. > > > >>>>> Rejecting the offer in that case is not really kosher. > > > >>>>> You are required to ignore parameters you do not > > > understand. > > > >>>>> > > > >>>>> If you reject something because you don't like the > > > parameters > > > >> it > > > >>>>> contains, then that is an implicit statement that you > > > >> understand > > > >>>>> those parameters well enough to decide to reject them. > > > >>>>> > > > >>>>> As far as I know, you are always free to reject=20 > offers, and it > > > >>>> doesn't > > > >>>>> really imply anything when you do that.. Whether it is wise > is > > > >>>> perhaps > > > >>>>> a different question. > > > >>>>> Stephen Botzko > > > >>>> > > > >>>> Certainly you are always free to reject an offer. > > > >>>> In general I don't know for certain the reason why,=20 > and so if I > > > give > > > >>>> you > > > >>>> the benefit of the doubt I will assume you have a=20 > valid reason > - > > > >>>> perhaps > > > >>>> just policy. > > > >>>> > > > >>>> But if the reason you reject the offer is based on your > > violating > > > a > > > >>>> spec, then you are non-conforming, whether I can=20 > determine you > > are > > > >>>> non-conforming or not. Whether being non-conforming is just > > > un-wise, > > > >> or > > > >>>> something stronger, is a separate discussion. The=20 > IETF does not > > > levy > > > >>>> any > > > >>>> penalties for violating its specs. But sometimes the market > > does. > > > >> (And > > > >>>> sometimes not.) But we don't need to endorse non-conforming > > > behavior > > > >> in > > > >>>> our documents. > > > >>>> > > > >>>> Thanks, > > > >>>> Paul > > > >>>> _______________________________________________ > > > >>>> clue mailing list > > > >>>> clue@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > >>> > > > >>> > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > >=20 > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 From john.elwell@siemens-enterprise.com Fri May 27 09:28:10 2011 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 BFF75E0711 for ; Fri, 27 May 2011 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ZkZAOXJZQMeT for ; Fri, 27 May 2011 09:28:09 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id A7DB6E0618 for ; Fri, 27 May 2011 09:28:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1306513687!8069137!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 7964 invoked from network); 27 May 2011 16:28:07 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-182.messagelabs.com with SMTP; 27 May 2011 16:28:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6B1B323F03E6; Fri, 27 May 2011 18:28:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 27 May 2011 18:28:07 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , Roni Even , "Paul Kyzivat (pkyzivat)" Date: Fri, 27 May 2011 18:28:05 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwU7Gye6H2i6dY4QNG1d6DuWLG2PwAdF4QQAAlDx0ABk+wMgAAYLHfQABL9JZAAAiKvsA== Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B8535@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B8535@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 16:28:10 -0000 I was quite happy with the refinements that Paul suggested, which I hope he= lp. Unfortunately I will not be available during the next couple of weeks, = so I will have to leave it to others to help arrive at appropriate words. John=20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: 27 May 2011 16:39 > To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > Hi John,=20 > Your suggestion is >=20 > The solution MUST include a mechanism that makes it > possible for endpoints with different capabilities to > interoperate in a telepresence conference, including > audio/video endpoints that do not support any telepresence extensions. >=20 > I have redone the requirements so that the reqmt for heterogeneous > devices as in the use case, which was reqmt 10, is now more specific. > So, we would not piggy back legacy on the hetereogeneity requirement. >=20 > Assuming this now refers only to the interaction of CLUE and=20 > non-CLUE, > the problem is that they don't interoperate in a telepresence=20 > sense- the > purpose for the WG. >=20 > Therefore, I would ask you to be more specific about the legacy > requirement. I should think that the general meaning would be=20 > along the > lines of that CLUE would not break any existing interworking - however > this is general, and it would be good to make it more specific. >=20 > I think it would be really helpful if you Paul and Roni, and others if > they wish, could suggest some new text to more specifically cover what > you have in mind which has been discussed in detail on the list. >=20 > Thanks, > Allyn > =20 >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, May 26, 2011 11:22 PM > To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) > Cc: clue@ietf.org > Subject: RE: [clue] legacy support in requirements >=20 > Allyn, >=20 > I already made a proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >=20 > John > =20 >=20 > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > > Sent: 26 May 2011 20:08 > > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > >=20 > > Roni, Paul, John- > > Would you care to suggest the wording you would like to see as a > > requirement for legacy interoperability? That would be helpful. > >=20 > > Thanks, > > Allyn > >=20 > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Roni Even > > > Sent: Wednesday, May 18, 2011 11:13 AM > > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > > > Cc: clue@ietf.org > > > Subject: Re: [clue] legacy support in requirements > > >=20 > > .... > > >=20 > > > Anyhow we are discussing solution while my point is that we=20 > > will need > > > as a > > > requirement to address the case of a call from a CLUE=20 > aware endpoint > > to > > > a > > > non CLUE aware endpoint. Even if the consensus will be to have the > > > preferred > > > video in the first video m-line. > > >=20 > > > Regards > > > Roni > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > > > Sent: Wednesday, May 18, 2011 4:41 PM > > > > To: Paul Kyzivat (pkyzivat); Roni Even > > > > Cc: clue@ietf.org > > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > Paul, > > > > > > > > I would agree that if the offer-answer model semantic=20 > is that here > > > are > > > > several options and any subset of options is acceptable. > > > > > > > > However, if there is any grouping involved such that you need to > > have > > > a > > > > video and audio feed integrated to make sense then watch out. > > > > > > > > For example, I wouldn't want to end up with the result=20 > of a man's > > > video > > > > paired with a woman's voice. That could be rather comical. > > > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org=20 > > [mailto:clue-bounces@ietf.org] On Behalf > > > Of > > > > Paul Kyzivat (pkyzivat) > > > > Sent: Tuesday, May 17, 2011 7:45 PM > > > > To: Roni Even > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > On 5/17/2011 6:05 PM, Roni Even wrote: > > > > > Paul, > > > > > I think we read it differently. > > > > > If the answerer does not support the group attribute=20 > > and the offer > > > > had > > > > the > > > > > fid semantics it may look to the answerer as an offer with > > multiple > > > > m-lines > > > > > of the same media tyoe. In this case an implementation=20 > > might also > > > > decide to > > > > > refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > > > > Acceptable), > > > > > because it contains several "m" lines of the same media type. > > > > > > > > That is a slightly different story. > > > > > > > > Then the reason for rejection is not because it saw an=20 > > attribute it > > > > didn't understand - its because it didn't like=20 > something it *did* > > > > understand. > > > > > > > > > This is very relevant to the multiple streams case=20 > and we should > > > look > > > > if we > > > > > state this behavior or we will look at providing an=20 > > approach that > > > > will > > > > allow > > > > > the answerer to choose one m-line that the offerer=20 > > prefers even of > > > it > > > > does > > > > > not understand CLUE. > > > > > > > > IMO (lets see if others differ), if a UA receives an=20 > offer with at > > > > least > > > > > > > > one m-line it is happy with, then it should not reject the call > > > because > > > > there are others that it does not "understand". > > > > > > > > Here "understand" means something different - presumably it does > > > > understand the direct meaning of the additional m-line, it just > > > doesn't > > > > understand the *significance* or use of it. > > > > > > > > I see little difference to getting to audio m-lines and=20 > > only wanting > > > > one, and getting one audio and one video and only=20 > > supporting audio. > > > In > > > > general you should not reject an audio/video call just=20 > because you > > > only > > > > support audio. > > > > > > > > I think it will behoove clue to strongly recommend that=20 > > the m-lines > > > in > > > > an offer be arranged so the first ones are the ones it=20 > most wants > > > used > > > > if not all are. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Roni > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > > > > >> To: Roni Even > > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > > > > >> Subject: Re: [clue] legacy support in requirements > > > > >> > > > > >> > > > > >> > > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > > > > >>> Paul, > > > > >>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > > > > example > > > > >>> Roni > > > > >> > > > > >> OK, I looked. It is consistent with what I said. > > > > >> Either a=3Dgroup: is understood, or not. If not, its=20 > ignored, and > > > not > > > > put > > > > >> in the answer. Same with a=3Dmid: > > > > >> > > > > >> If a=3Dgroup: *is* understood, but some parameter within=20 > > it is not, > > > > there > > > > >> are explicit rules for what to do. > > > > >> > > > > >> AFAICT there are no examples in this document where=20 > failure to > > > > >> understand an a-line in total (or even in part) results in > > > rejecting > > > > >> the > > > > >> offer. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >>>> -----Original Message----- > > > > >>>> From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > >> Of > > > > >>>> Paul Kyzivat > > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > > > > >>>> To: Stephen Botzko > > > > >>>> Cc: clue@ietf.org > > > > >>>> Subject: Re: [clue] legacy support in requirements > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > > > > >>>> > > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > > > > >>>> > > > > >>>>> When the offer includes parameters that=20 > > the answerer > > > > does > > > > >> not > > > > >>>>> understand > > > > >>>>> there are two options, he can ignore the unknown > > > > >> parameters > > > > >>>> or > > > > >>>>> reject > > > > >>>>> the offer. > > > > >>>>> Rejecting the offer in that case is not=20 > really kosher. > > > > >>>>> You are required to ignore parameters you do not > > > > understand. > > > > >>>>> > > > > >>>>> If you reject something because you don't like the > > > > parameters > > > > >> it > > > > >>>>> contains, then that is an implicit=20 > statement that you > > > > >> understand > > > > >>>>> those parameters well enough to decide to=20 > reject them. > > > > >>>>> > > > > >>>>> As far as I know, you are always free to reject=20 > > offers, and it > > > > >>>> doesn't > > > > >>>>> really imply anything when you do that.. Whether=20 > it is wise > > is > > > > >>>> perhaps > > > > >>>>> a different question. > > > > >>>>> Stephen Botzko > > > > >>>> > > > > >>>> Certainly you are always free to reject an offer. > > > > >>>> In general I don't know for certain the reason why,=20 > > and so if I > > > > give > > > > >>>> you > > > > >>>> the benefit of the doubt I will assume you have a=20 > > valid reason > > - > > > > >>>> perhaps > > > > >>>> just policy. > > > > >>>> > > > > >>>> But if the reason you reject the offer is based on your > > > violating > > > > a > > > > >>>> spec, then you are non-conforming, whether I can=20 > > determine you > > > are > > > > >>>> non-conforming or not. Whether being non-conforming is just > > > > un-wise, > > > > >> or > > > > >>>> something stronger, is a separate discussion. The=20 > > IETF does not > > > > levy > > > > >>>> any > > > > >>>> penalties for violating its specs. But sometimes the market > > > does. > > > > >> (And > > > > >>>> sometimes not.) But we don't need to endorse non-conforming > > > > behavior > > > > >> in > > > > >>>> our documents. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Paul > > > > >>>> _______________________________________________ > > > > >>>> clue mailing list > > > > >>>> clue@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > > >>> > > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > >=20 > = From pkyzivat@cisco.com Fri May 27 10:16:12 2011 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 B909AE06EE for ; Fri, 27 May 2011 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.318 X-Spam-Level: X-Spam-Status: No, score=-110.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zkSM0QQtWzXq for ; Fri, 27 May 2011 10:16:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 353B6E068D for ; Fri, 27 May 2011 10:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=20257; q=dns/txt; s=iport; t=1306516571; x=1307726171; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J1GqaDxjx4sapRo5gRWBBU4xYWPt6P8rux1i00Aco4E=; b=Nt6rX2ksj9p7+VoVbLwhtHzHHFpmGJVCumyEXvSrbvwD9CsuQZ9SyR2F XSp9OMUwHrnNY1N0PczejNqIYCc7PpCpRcUJwR+kW9kmzf3mJ/pBm0PzN nqopf8JKRNts1NtPLXfYfqVtxmLPbtLx8YgtRxUsVD5vw01yYWVljipAK 8=; X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="455601557" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 27 May 2011 17:16:07 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHG6d9021982; Fri, 27 May 2011 17:16:07 GMT Message-ID: <4DDFDC56.6010205@cisco.com> Date: Fri, 27 May 2011 13:16:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com><4DDFA0C8.1050509@cisco.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] legacy support in requirements 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, 27 May 2011 17:16:12 -0000 I intentionally wrote SHOULD/MUST because I was uncertain which one to use. It bears discussion. Thanks, Paul On 5/27/2011 10:05 AM, Parthasarathi R (partr) wrote: > Paul, > > I have the doubt whether this requirement has to be "MUST" or "SHOULD" > because CLUE (telepresence) end-point may not like to interop with > simple audio end-point (SIP UA). It may be just policy not to received > audio-call in CLUE endpoint because of better utilization of costly > resources. Please let me know your opinion here. > > Apart from this doubt, I like your requirement proposal. > > Thanks > Partha > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Friday, May 27, 2011 7:25 PM > To: Paul Kyzivat (pkyzivat); clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > Yes, I like Paul's changes. > > John > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 27 May 2011 14:02 >> To: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/27/2011 8:28 AM, Elwell, John wrote: >>> I can live with Steve's proposal. I also don't mind >> separating the requirements, but I don't think we should refer to CLUE > >> in the requirement - the RFC will live a long time after CLUE is >> finished and closed down. So if we want to separate the requirements, >> I would propose: >>> >>> REQMT-10: The solution MUST include a mechanism that makes >> it possible for endpoints with different capabilities to interoperate >> in a telepresence conference. >>> REQMT-10bis: The solution MUST include a mechanism that >> makes it possible for endpoints without support for telepresence >> extensions to participate in a telepresence conference with those that > >> do. >> >> How about the following variant of that: >> >> REQMT-10bis: The solution MUST make it possible for endpoints without > >> support for telepresence extensions to participate in a telepresence >> session with those that do. >> >> I dropped "mechanism" because its unlikely to be a new mechanism that >> makes this possible. (That would require changes to the legacy >> systems.) Rather it will need to be the manner of using existing >> mechanisms. >> >> And I changed "telepresence conference" to "telepresence session" >> because this ought to work point-point as well as for conferences. >> (But we probably need more definition work here, since neither >> telepresence-conference nor telepresence-session is currently >> defined.) >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>> Sent: 27 May 2011 12:23 >>>> To: Stephen Botzko; Elwell, John >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> I think it would be clearer to formulate two different requirements >>>> >>>> >>>> >>>> 1) Two solution must provide a mechanism that make it >>>> possible for endpoints with different capabilities to interoperate, > >>>> e.g. interoperability between a 2 camera/screens and 3 >>>> camera/screens endpoint. >>>> >>>> 2) Two solution must provide a mechanism that make it >>>> possible for endpoints that are CLUE aware to interoperate with >>>> CLUE-less endpoints. >>>> >>>> >>>> >>>> Cheers >>>> >>>> >>>> >>>> -Espen >>>> >>>> >>>> >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Stephen Botzko >>>> Sent: 27. mai 2011 13:16 >>>> To: Elwell, John >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> I'm not sure that the language actually covers that (it seems >>>> ambiguous). >>>> >>>> What do you think about changing "endpoints with different >>>> capabilities" to "disparate devices"? >>>> >>>> Stephen >>>> >>>> >>>> >>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>> wrote: >>>> >>>> I thought requirement 10 would cover both (signalling/protocol >>>> capabilities as well as user interface capabilities). >>>> >>>> John >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>> >>>>> Sent: 27 May 2011 11:53 >>>>> To: Elwell, John >>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat); >>>>> clue@ietf.org >>>> >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> Do you think that the language in requirement 10 means "SIP >>>>> capabilities"? Or something else? >>>>> >>>>> I am thinking that issue is really about the signaling/protocol >>>>> design itself, and isn't directly related to how many screens and >>>>> cameras a system might have. >>>>> >>>>> Stephen Botzko >>>>> >>>>> >>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>> wrote: >>>>> >>>>> >>>>> Allyn, >>>>> >>>>> I already made a proposal: >>>>> >>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> > -----Original Message----- >>>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>> >>>>> > Sent: 26 May 2011 20:08 >>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>> > Cc: clue@ietf.org >>>>> > Subject: RE: [clue] legacy support in requirements >>>>> > >>>>> > Roni, Paul, John- >>>>> > Would you care to suggest the wording you would like to >>>>> see as a >>>>> > requirement for legacy interoperability? That would be >>>>> helpful. >>>>> > >>>>> > Thanks, >>>>> > Allyn >>>>> > >>>>> > > -----Original Message----- >>>>> > > From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>> > Of >>>>> > > Roni Even >>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>> > > Cc: clue@ietf.org >>>>> > > Subject: Re: [clue] legacy support in requirements >>>>> > > >>>>> > .... >>>>> > > >>>>> > > Anyhow we are discussing solution while my point >>>> is that we >>>>> > will need >>>>> > > as a >>>>> > > requirement to address the case of a call from a CLUE > >>>>> aware endpoint >>>>> > to >>>>> > > a >>>>> > > non CLUE aware endpoint. Even if the consensus will >>>>> be to have the >>>>> > > preferred >>>>> > > video in the first video m-line. >>>>> > > >>>>> > > Regards >>>>> > > Roni >>>>> > > >>>>> > > >>>>> > > >>>>> > > > -----Original Message----- >>>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>> > > > Cc: clue@ietf.org >>>>> > > > Subject: RE: [clue] legacy support in requirements >>>>> > > > >>>>> > > > Paul, >>>>> > > > >>>>> > > > I would agree that if the offer-answer model >>>>> semantic is that here >>>>> > > are >>>>> > > > several options and any subset of options >> is acceptable. >>>>> > > > >>>>> > > > However, if there is any grouping involved such >>>>> that you need to >>>>> > have >>>>> > > a >>>>> > > > video and audio feed integrated to make sense then > >>>>> watch out. >>>>> > > > >>>>> > > > For example, I wouldn't want to end up with the >>>>> result of a man's >>>>> > > video >>>>> > > > paired with a woman's voice. That could be rather > >>>>> comical. >>>>> > > > >>>>> > > > Mike >>>>> > > > >>>>> > > > >>>>> > > > -----Original Message----- >>>>> > > > From: clue-bounces@ietf.org >>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>> > > Of >>>>> > > > Paul Kyzivat (pkyzivat) >>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>> > > > To: Roni Even >>>>> > > > Cc: clue@ietf.org >>>>> > > > Subject: Re: [clue] legacy support in requirements >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>> > > > > Paul, >>>>> > > > > I think we read it differently. >>>>> > > > > If the answerer does not support the >> group attribute >>>>> > and the offer >>>>> > > > had >>>>> > > > the >>>>> > > > > fid semantics it may look to the answerer as an > >>>>> offer with >>>>> > multiple >>>>> > > > m-lines >>>>> > > > > of the same media tyoe. In this case >> an implementation >>>>> > might also >>>>> > > > decide to >>>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>>> Here, or 606 Not >>>>> > > > Acceptable), >>>>> > > > > because it contains several "m" lines of the >>>>> same media type. >>>>> > > > >>>>> > > > That is a slightly different story. >>>>> > > > >>>>> > > > Then the reason for rejection is not >> because it saw an >>>>> > attribute it >>>>> > > > didn't understand - its because it didn't like >>>>> something it *did* >>>>> > > > understand. >>>>> > > > >>>>> > > > > This is very relevant to the multiple streams >>>>> case and we should >>>>> > > look >>>>> > > > if we >>>>> > > > > state this behavior or we will look at >> providing an >>>>> > approach that >>>>> > > > will >>>>> > > > allow >>>>> > > > > the answerer to choose one m-line that >> the offerer >>>>> > prefers even of >>>>> > > it >>>>> > > > does >>>>> > > > > not understand CLUE. >>>>> > > > >>>>> > > > IMO (lets see if others differ), if a UA receives >>>>> an offer with at >>>>> > > > least >>>>> > > > >>>>> > > > one m-line it is happy with, then it should not >>>>> reject the call >>>>> > > because >>>>> > > > there are others that it does not "understand". >>>>> > > > >>>>> > > > Here "understand" means something different - >>>>> presumably it does >>>>> > > > understand the direct meaning of the additional >>>>> m-line, it just >>>>> > > doesn't >>>>> > > > understand the *significance* or use of it. >>>>> > > > >>>>> > > > I see little difference to getting to >> audio m-lines and >>>>> > only wanting >>>>> > > > one, and getting one audio and one video and only >>>>> > supporting audio. >>>>> > > In >>>>> > > > general you should not reject an audio/video call >>>>> just because you >>>>> > > only >>>>> > > > support audio. >>>>> > > > >>>>> > > > I think it will behoove clue to strongly >> recommend that >>>>> > the m-lines >>>>> > > in >>>>> > > > an offer be arranged so the first ones are the >>>>> ones it most wants >>>>> > > used >>>>> > > > if not all are. >>>>> > > > >>>>> > > > Thanks, >>>>> > > > Paul >>>>> > > > >>>>> > > > > Roni >>>>> > > > > >>>>> > > > >> -----Original Message----- >>>>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>>> > > > >> To: Roni Even >>>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>>> > > > >> Subject: Re: [clue] legacy support in >> requirements >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> > > > >>> Paul, >>>>> > > > >>> Look at >>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>> > > > example >>>>> > > > >>> Roni >>>>> > > > >> >>>>> > > > >> OK, I looked. It is consistent with >> what I said. >>>>> > > > >> Either a=group: is understood, or not. If not, > >>>>> its ignored, and >>>>> > > not >>>>> > > > put >>>>> > > > >> in the answer. Same with a=mid: >>>>> > > > >> >>>>> > > > >> If a=group: *is* understood, but some >>>> parameter within >>>>> > it is not, >>>>> > > > there >>>>> > > > >> are explicit rules for what to do. >>>>> > > > >> >>>>> > > > >> AFAICT there are no examples in this document >>>>> where failure to >>>>> > > > >> understand an a-line in total (or even in >>>>> part) results in >>>>> > > rejecting >>>>> > > > >> the >>>>> > > > >> offer. >>>>> > > > >> >>>>> > > > >> Thanks, >>>>> > > > >> Paul >>>>> > > > >> >>>>> > > > >>>> -----Original Message----- >>>>> > > > >>>> From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On >>>>> > > > Behalf >>>>> > > > >> Of >>>>> > > > >>>> Paul Kyzivat >>>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> > > > >>>> To: Stephen Botzko >>>>> > > > >>>> Cc: clue@ietf.org >>>>> > > > >>>> Subject: Re: [clue] legacy support >> in requirements >>>>> > > > >>>> >>>>> > > > >>>> >>>>> > > > >>>> >>>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> > > > >>>> >>>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni >> Even wrote: >>>>> > > > >>>> >>>>> > > > >>>>> When the offer includes >> parameters that >>>>> > the answerer >>>>> > > > does >>>>> > > > >> not >>>>> > > > >>>>> understand >>>>> > > > >>>>> there are two options, he can >>>>> ignore the unknown >>>>> > > > >> parameters >>>>> > > > >>>> or >>>>> > > > >>>>> reject >>>>> > > > >>>>> the offer. >>>>> > > > >>>>> Rejecting the offer in that case is >>>>> not really kosher. >>>>> > > > >>>>> You are required to ignore parameters >>>>> you do not >>>>> > > > understand. >>>>> > > > >>>>> >>>>> > > > >>>>> If you reject something because you >>>>> don't like the >>>>> > > > parameters >>>>> > > > >> it >>>>> > > > >>>>> contains, then that is an implicit >>>>> statement that you >>>>> > > > >> understand >>>>> > > > >>>>> those parameters well enough to >>>>> decide to reject them. >>>>> > > > >>>>> >>>>> > > > >>>>> As far as I know, you are always >> free to reject >>>>> > offers, and it >>>>> > > > >>>> doesn't >>>>> > > > >>>>> really imply anything when you do that.. >>>>> Whether it is wise >>>>> > is >>>>> > > > >>>> perhaps >>>>> > > > >>>>> a different question. >>>>> > > > >>>>> Stephen Botzko >>>>> > > > >>>> >>>>> > > > >>>> Certainly you are always free to >> reject an offer. >>>>> > > > >>>> In general I don't know for certain >> the reason why, >>>>> > and so if I >>>>> > > > give >>>>> > > > >>>> you >>>>> > > > >>>> the benefit of the doubt I will >> assume you have a >>>>> > valid reason >>>>> > - >>>>> > > > >>>> perhaps >>>>> > > > >>>> just policy. >>>>> > > > >>>> >>>>> > > > >>>> But if the reason you reject the offer is >>>>> based on your >>>>> > > violating >>>>> > > > a >>>>> > > > >>>> spec, then you are non-conforming, >> whether I can >>>>> > determine you >>>>> > > are >>>>> > > > >>>> non-conforming or not. Whether being >>>>> non-conforming is just >>>>> > > > un-wise, >>>>> > > > >> or >>>>> > > > >>>> something stronger, is a separate >> discussion. The >>>>> > IETF does not >>>>> > > > levy >>>>> > > > >>>> any >>>>> > > > >>>> penalties for violating its specs. But >>>>> sometimes the market >>>>> > > does. >>>>> > > > >> (And >>>>> > > > >>>> sometimes not.) But we don't need to endorse > >>>>> non-conforming >>>>> > > > behavior >>>>> > > > >> in >>>>> > > > >>>> our documents. >>>>> > > > >>>> >>>>> > > > >>>> Thanks, >>>>> > > > >>>> Paul >>>>> > > > >>>> >> _______________________________________________ >>>>> > > > >>>> clue mailing list >>>>> > > > >>>> clue@ietf.org >>>>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue >>>>> > > > >>> >>>>> > > > >>> >>>>> > > > > >>>>> > > > > >>>>> > > > _______________________________________________ >>>>> > > > clue mailing list >>>>> > > > clue@ietf.org >>>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>>> > > >>>>> > > _______________________________________________ >>>>> > > clue mailing list >>>>> > > clue@ietf.org >>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>> > >>>>> _______________________________________________ >>>>> 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@cisco.com Fri May 27 10:24:47 2011 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 0F717E0835 for ; Fri, 27 May 2011 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.325 X-Spam-Level: X-Spam-Status: No, score=-110.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 2H-j5lJXL+PU for ; Fri, 27 May 2011 10:24:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B2B32E0675 for ; Fri, 27 May 2011 10:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11880; q=dns/txt; s=iport; t=1306517085; x=1307726685; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CerDDXq8cP0GE1TgvkP2OioTNj0sj5e40+OYDkqlKak=; b=B5KJETK3Nh6j3zTMt0a880kqwqBUm/cQAvXQe1gO68K6wM5F2B1QZAEh ypOJjLfF/eidxrPdac78pz77OSoFKgQHvT1Z5jPSL6KHhgnqnGkMcQAlW 0Qc9Uo71CuWtwtpjvqHYbLYx6h+2PzUiKQ2KvHllbRtdq25ALZo/1rP8X 0=; X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="455605793" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 27 May 2011 17:24:45 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHOicC030752; Fri, 27 May 2011 17:24:44 GMT Message-ID: <4DDFDE5C.2040209@cisco.com> Date: Fri, 27 May 2011 13:24:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B8535@xmb-sjc-221.amer.cisco.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] legacy support in requirements 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, 27 May 2011 17:24:47 -0000 Allyn, It seems that what I suggested is the latest preference. Here it is again. I think it is a new requirement in addition to the existing REQMT-10: =========================== REQMT-XYZ: The solution SHOULD/MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. =========================== I dropped "mechanism" from John's because its unlikely to be a new mechanism that makes this possible. (That would require changes to the legacy systems.) Rather it will need to be the manner of using existing mechanisms. And I changed "telepresence conference" to "telepresence session" because this ought to work point-point as well as for conferences. (But we probably need more definition work here, since neither telepresence-conference nor telepresence-session is currently defined.) And I don't know if this ought to be SHOULD/MUST. I could go either way on that, but if its SHOULD, then we ought to add some words on what the criteria are for not doing it. Thanks, Paul On 5/27/2011 12:28 PM, Elwell, John wrote: > I was quite happy with the refinements that Paul suggested, which I hope help. Unfortunately I will not be available during the next couple of weeks, so I will have to leave it to others to help arrive at appropriate words. > > John > >> -----Original Message----- >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> Sent: 27 May 2011 16:39 >> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) >> Cc: clue@ietf.org >> Subject: RE: [clue] legacy support in requirements >> >> Hi John, >> Your suggestion is >> >> The solution MUST include a mechanism that makes it >> possible for endpoints with different capabilities to >> interoperate in a telepresence conference, including >> audio/video endpoints that do not support any telepresence extensions. >> >> I have redone the requirements so that the reqmt for heterogeneous >> devices as in the use case, which was reqmt 10, is now more specific. >> So, we would not piggy back legacy on the hetereogeneity requirement. >> >> Assuming this now refers only to the interaction of CLUE and >> non-CLUE, >> the problem is that they don't interoperate in a telepresence >> sense- the >> purpose for the WG. >> >> Therefore, I would ask you to be more specific about the legacy >> requirement. I should think that the general meaning would be >> along the >> lines of that CLUE would not break any existing interworking - however >> this is general, and it would be good to make it more specific. >> >> I think it would be really helpful if you Paul and Roni, and others if >> they wish, could suggest some new text to more specifically cover what >> you have in mind which has been discussed in detail on the list. >> >> Thanks, >> Allyn >> >> >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, May 26, 2011 11:22 PM >> To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) >> Cc: clue@ietf.org >> Subject: RE: [clue] legacy support in requirements >> >> Allyn, >> >> I already made a proposal: >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >> >> John >> >> >>> -----Original Message----- >>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>> Sent: 26 May 2011 20:08 >>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> Roni, Paul, John- >>> Would you care to suggest the wording you would like to see as a >>> requirement for legacy interoperability? That would be helpful. >>> >>> Thanks, >>> Allyn >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>> Roni Even >>>> Sent: Wednesday, May 18, 2011 11:13 AM >>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>> .... >>>> >>>> Anyhow we are discussing solution while my point is that we >>> will need >>>> as a >>>> requirement to address the case of a call from a CLUE >> aware endpoint >>> to >>>> a >>>> non CLUE aware endpoint. Even if the consensus will be to have the >>>> preferred >>>> video in the first video m-line. >>>> >>>> Regards >>>> Roni >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>> Sent: Wednesday, May 18, 2011 4:41 PM >>>>> To: Paul Kyzivat (pkyzivat); Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] legacy support in requirements >>>>> >>>>> Paul, >>>>> >>>>> I would agree that if the offer-answer model semantic >> is that here >>>> are >>>>> several options and any subset of options is acceptable. >>>>> >>>>> However, if there is any grouping involved such that you need to >>> have >>>> a >>>>> video and audio feed integrated to make sense then watch out. >>>>> >>>>> For example, I wouldn't want to end up with the result >> of a man's >>>> video >>>>> paired with a woman's voice. That could be rather comical. >>>>> >>>>> Mike >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>>> Paul Kyzivat (pkyzivat) >>>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>>> To: Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>> Paul, >>>>>> I think we read it differently. >>>>>> If the answerer does not support the group attribute >>> and the offer >>>>> had >>>>> the >>>>>> fid semantics it may look to the answerer as an offer with >>> multiple >>>>> m-lines >>>>>> of the same media tyoe. In this case an implementation >>> might also >>>>> decide to >>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>>> Acceptable), >>>>>> because it contains several "m" lines of the same media type. >>>>> >>>>> That is a slightly different story. >>>>> >>>>> Then the reason for rejection is not because it saw an >>> attribute it >>>>> didn't understand - its because it didn't like >> something it *did* >>>>> understand. >>>>> >>>>>> This is very relevant to the multiple streams case >> and we should >>>> look >>>>> if we >>>>>> state this behavior or we will look at providing an >>> approach that >>>>> will >>>>> allow >>>>>> the answerer to choose one m-line that the offerer >>> prefers even of >>>> it >>>>> does >>>>>> not understand CLUE. >>>>> >>>>> IMO (lets see if others differ), if a UA receives an >> offer with at >>>>> least >>>>> >>>>> one m-line it is happy with, then it should not reject the call >>>> because >>>>> there are others that it does not "understand". >>>>> >>>>> Here "understand" means something different - presumably it does >>>>> understand the direct meaning of the additional m-line, it just >>>> doesn't >>>>> understand the *significance* or use of it. >>>>> >>>>> I see little difference to getting to audio m-lines and >>> only wanting >>>>> one, and getting one audio and one video and only >>> supporting audio. >>>> In >>>>> general you should not reject an audio/video call just >> because you >>>> only >>>>> support audio. >>>>> >>>>> I think it will behoove clue to strongly recommend that >>> the m-lines >>>> in >>>>> an offer be arranged so the first ones are the ones it >> most wants >>>> used >>>>> if not all are. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Roni >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>>> To: Roni Even >>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>>> Paul, >>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>> example >>>>>>>> Roni >>>>>>> >>>>>>> OK, I looked. It is consistent with what I said. >>>>>>> Either a=group: is understood, or not. If not, its >> ignored, and >>>> not >>>>> put >>>>>>> in the answer. Same with a=mid: >>>>>>> >>>>>>> If a=group: *is* understood, but some parameter within >>> it is not, >>>>> there >>>>>>> are explicit rules for what to do. >>>>>>> >>>>>>> AFAICT there are no examples in this document where >> failure to >>>>>>> understand an a-line in total (or even in part) results in >>>> rejecting >>>>>>> the >>>>>>> offer. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On >>>>> Behalf >>>>>>> Of >>>>>>>>> Paul Kyzivat >>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>>> To: Stephen Botzko >>>>>>>>> Cc: clue@ietf.org >>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>>> >>>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>>> >>>>>>>>>> When the offer includes parameters that >>> the answerer >>>>> does >>>>>>> not >>>>>>>>>> understand >>>>>>>>>> there are two options, he can ignore the unknown >>>>>>> parameters >>>>>>>>> or >>>>>>>>>> reject >>>>>>>>>> the offer. >>>>>>>>>> Rejecting the offer in that case is not >> really kosher. >>>>>>>>>> You are required to ignore parameters you do not >>>>> understand. >>>>>>>>>> >>>>>>>>>> If you reject something because you don't like the >>>>> parameters >>>>>>> it >>>>>>>>>> contains, then that is an implicit >> statement that you >>>>>>> understand >>>>>>>>>> those parameters well enough to decide to >> reject them. >>>>>>>>>> >>>>>>>>>> As far as I know, you are always free to reject >>> offers, and it >>>>>>>>> doesn't >>>>>>>>>> really imply anything when you do that.. Whether >> it is wise >>> is >>>>>>>>> perhaps >>>>>>>>>> a different question. >>>>>>>>>> Stephen Botzko >>>>>>>>> >>>>>>>>> Certainly you are always free to reject an offer. >>>>>>>>> In general I don't know for certain the reason why, >>> and so if I >>>>> give >>>>>>>>> you >>>>>>>>> the benefit of the doubt I will assume you have a >>> valid reason >>> - >>>>>>>>> perhaps >>>>>>>>> just policy. >>>>>>>>> >>>>>>>>> But if the reason you reject the offer is based on your >>>> violating >>>>> a >>>>>>>>> spec, then you are non-conforming, whether I can >>> determine you >>>> are >>>>>>>>> non-conforming or not. Whether being non-conforming is just >>>>> un-wise, >>>>>>> or >>>>>>>>> something stronger, is a separate discussion. The >>> IETF does not >>>>> levy >>>>>>>>> any >>>>>>>>> penalties for violating its specs. But sometimes the market >>>> does. >>>>>>> (And >>>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>>> behavior >>>>>>> in >>>>>>>>> our documents. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >> From stewe@stewe.org Fri May 27 10:31:14 2011 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 93B0AE082D for ; Fri, 27 May 2011 10:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.795, 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 4JdyXsZ8HVY9 for ; Fri, 27 May 2011 10:31:13 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 87949E082B for ; Fri, 27 May 2011 10:31:12 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 5618-1743317 for multiple; Fri, 27 May 2011 19:31:11 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 27 May 2011 10:31:04 -0700 From: Stephan Wenger To: Paul Kyzivat , Message-ID: Thread-Topic: [clue] legacy support in requirements In-Reply-To: <4DDFA0C8.1050509@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:31:14 -0000 Hi Paul, The summation of the protocol work designed by CLUE is referred to as "solution". A CLUE-less device is a device without the solution. Therefore, I propose to replace "telepresence extensions" (which is undefined, and could refer to telepresence extension not defined by CLUE) with "solution". Thereafter, 10bis reads: REQMT-10bis: The solution MUST make it possible for endpoints without support for the solution to participate in a telepresence session with those that do. On 5.27.2011 06:02 , "Paul Kyzivat" wrote: > > >On 5/27/2011 8:28 AM, Elwell, John wrote: >> I can live with Steve's proposal. I also don't mind separating the >>requirements, but I don't think we should refer to CLUE in the >>requirement - the RFC will live a long time after CLUE is finished and >>closed down. So if we want to separate the requirements, I would propose: >> >> REQMT-10: The solution MUST include a mechanism that makes it possible >>for endpoints with different capabilities to interoperate in a >>telepresence conference. >> REQMT-10bis: The solution MUST include a mechanism that makes it >>possible for endpoints without support for telepresence extensions to >>participate in a telepresence conference with those that do. > >How about the following variant of that: > >REQMT-10bis: The solution MUST make it possible for endpoints without >support for telepresence extensions to participate in a telepresence >session with those that do. > >I dropped "mechanism" because its unlikely to be a new mechanism that >makes this possible. (That would require changes to the legacy systems.) >Rather it will need to be the manner of using existing mechanisms. > >And I changed "telepresence conference" to "telepresence session" >because this ought to work point-point as well as for conferences. >(But we probably need more definition work here, since neither >telepresence-conference nor telepresence-session is currently defined.) > > Thanks, > Paul > >> John >> >> >>> -----Original Message----- >>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>> Sent: 27 May 2011 12:23 >>> To: Stephen Botzko; Elwell, John >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> I think it would be clearer to formulate two different requirements >>> >>> >>> >>> 1) Two solution must provide a mechanism that make it >>> possible for endpoints with different capabilities to >>> interoperate, e.g. interoperability between a 2 >>> camera/screens and 3 camera/screens endpoint. >>> >>> 2) Two solution must provide a mechanism that make it >>> possible for endpoints that are CLUE aware to interoperate >>> with CLUE-less endpoints. >>> >>> >>> >>> Cheers >>> >>> >>> >>> -Espen >>> >>> >>> >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf Of Stephen Botzko >>> Sent: 27. mai 2011 13:16 >>> To: Elwell, John >>> Cc: clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> I'm not sure that the language actually covers that (it seems >>> ambiguous). >>> >>> What do you think about changing "endpoints with different >>> capabilities" to "disparate devices"? >>> >>> Stephen >>> >>> >>> >>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>> wrote: >>> >>> I thought requirement 10 would cover both >>> (signalling/protocol capabilities as well as user interface >>> capabilities). >>> >>> John >>> >>> >>> >>>> -----Original Message----- >>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>> >>>> Sent: 27 May 2011 11:53 >>>> To: Elwell, John >>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >>>> (pkyzivat); clue@ietf.org >>> >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> Do you think that the language in requirement 10 means "SIP >>>> capabilities"? Or something else? >>>> >>>> I am thinking that issue is really about the >>>> signaling/protocol design itself, and isn't directly related >>>> to how many screens and cameras a system might have. >>>> >>>> Stephen Botzko >>>> >>>> >>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>> wrote: >>>> >>>> >>>> Allyn, >>>> >>>> I already made a proposal: >>>> >>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>> >>>> John >>>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>> >>>> > Sent: 26 May 2011 20:08 >>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>> > Cc: clue@ietf.org >>>> > Subject: RE: [clue] legacy support in requirements >>>> > >>>> > Roni, Paul, John- >>>> > Would you care to suggest the wording you would like >>>> to see as a >>>> > requirement for legacy interoperability? That would >>>> be helpful. >>>> > >>>> > Thanks, >>>> > Allyn >>>> > >>>> > > -----Original Message----- >>>> > > From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On Behalf >>>> > Of >>>> > > Roni Even >>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>> > > Cc: clue@ietf.org >>>> > > Subject: Re: [clue] legacy support in requirements >>>> > > >>>> > .... >>>> > > >>>> > > Anyhow we are discussing solution while my point >>> is that we >>>> > will need >>>> > > as a >>>> > > requirement to address the case of a call from a >>>> CLUE aware endpoint >>>> > to >>>> > > a >>>> > > non CLUE aware endpoint. Even if the consensus will >>>> be to have the >>>> > > preferred >>>> > > video in the first video m-line. >>>> > > >>>> > > Regards >>>> > > Roni >>>> > > >>>> > > >>>> > > >>>> > > > -----Original Message----- >>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>> > > > Cc: clue@ietf.org >>>> > > > Subject: RE: [clue] legacy support in requirements >>>> > > > >>>> > > > Paul, >>>> > > > >>>> > > > I would agree that if the offer-answer model >>>> semantic is that here >>>> > > are >>>> > > > several options and any subset of options is >>>>acceptable. >>>> > > > >>>> > > > However, if there is any grouping involved such >>>> that you need to >>>> > have >>>> > > a >>>> > > > video and audio feed integrated to make sense >>>> then watch out. >>>> > > > >>>> > > > For example, I wouldn't want to end up with the >>>> result of a man's >>>> > > video >>>> > > > paired with a woman's voice. That could be >>>> rather comical. >>>> > > > >>>> > > > Mike >>>> > > > >>>> > > > >>>> > > > -----Original Message----- >>>> > > > From: clue-bounces@ietf.org >>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>> > > Of >>>> > > > Paul Kyzivat (pkyzivat) >>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>> > > > To: Roni Even >>>> > > > Cc: clue@ietf.org >>>> > > > Subject: Re: [clue] legacy support in requirements >>>> > > > >>>> > > > >>>> > > > >>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>> > > > > Paul, >>>> > > > > I think we read it differently. >>>> > > > > If the answerer does not support the group >>>>attribute >>>> > and the offer >>>> > > > had >>>> > > > the >>>> > > > > fid semantics it may look to the answerer as an >>>> offer with >>>> > multiple >>>> > > > m-lines >>>> > > > > of the same media tyoe. In this case an >>>>implementation >>>> > might also >>>> > > > decide to >>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>> Here, or 606 Not >>>> > > > Acceptable), >>>> > > > > because it contains several "m" lines of the >>>> same media type. >>>> > > > >>>> > > > That is a slightly different story. >>>> > > > >>>> > > > Then the reason for rejection is not because it saw an >>>> > attribute it >>>> > > > didn't understand - its because it didn't like >>>> something it *did* >>>> > > > understand. >>>> > > > >>>> > > > > This is very relevant to the multiple streams >>>> case and we should >>>> > > look >>>> > > > if we >>>> > > > > state this behavior or we will look at providing an >>>> > approach that >>>> > > > will >>>> > > > allow >>>> > > > > the answerer to choose one m-line that the offerer >>>> > prefers even of >>>> > > it >>>> > > > does >>>> > > > > not understand CLUE. >>>> > > > >>>> > > > IMO (lets see if others differ), if a UA receives >>>> an offer with at >>>> > > > least >>>> > > > >>>> > > > one m-line it is happy with, then it should not >>>> reject the call >>>> > > because >>>> > > > there are others that it does not "understand". >>>> > > > >>>> > > > Here "understand" means something different - >>>> presumably it does >>>> > > > understand the direct meaning of the additional >>>> m-line, it just >>>> > > doesn't >>>> > > > understand the *significance* or use of it. >>>> > > > >>>> > > > I see little difference to getting to audio m-lines >>>>and >>>> > only wanting >>>> > > > one, and getting one audio and one video and only >>>> > supporting audio. >>>> > > In >>>> > > > general you should not reject an audio/video call >>>> just because you >>>> > > only >>>> > > > support audio. >>>> > > > >>>> > > > I think it will behoove clue to strongly recommend >>>>that >>>> > the m-lines >>>> > > in >>>> > > > an offer be arranged so the first ones are the >>>> ones it most wants >>>> > > used >>>> > > > if not all are. >>>> > > > >>>> > > > Thanks, >>>> > > > Paul >>>> > > > >>>> > > > > Roni >>>> > > > > >>>> > > > >> -----Original Message----- >>>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>> > > > >> To: Roni Even >>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>> > > > >> Subject: Re: [clue] legacy support in requirements >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>> > > > >>> Paul, >>>> > > > >>> Look at >>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>> > > > example >>>> > > > >>> Roni >>>> > > > >> >>>> > > > >> OK, I looked. It is consistent with what I said. >>>> > > > >> Either a=group: is understood, or not. If not, >>>> its ignored, and >>>> > > not >>>> > > > put >>>> > > > >> in the answer. Same with a=mid: >>>> > > > >> >>>> > > > >> If a=group: *is* understood, but some >>> parameter within >>>> > it is not, >>>> > > > there >>>> > > > >> are explicit rules for what to do. >>>> > > > >> >>>> > > > >> AFAICT there are no examples in this document >>>> where failure to >>>> > > > >> understand an a-line in total (or even in >>>> part) results in >>>> > > rejecting >>>> > > > >> the >>>> > > > >> offer. >>>> > > > >> >>>> > > > >> Thanks, >>>> > > > >> Paul >>>> > > > >> >>>> > > > >>>> -----Original Message----- >>>> > > > >>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On >>>> > > > Behalf >>>> > > > >> Of >>>> > > > >>>> Paul Kyzivat >>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>> > > > >>>> To: Stephen Botzko >>>> > > > >>>> Cc: clue@ietf.org >>>> > > > >>>> Subject: Re: [clue] legacy support in >>>>requirements >>>> > > > >>>> >>>> > > > >>>> >>>> > > > >>>> >>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>> > > > >>>> >>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>> > > > >>>> >>>> > > > >>>>> When the offer includes parameters >>>>that >>>> > the answerer >>>> > > > does >>>> > > > >> not >>>> > > > >>>>> understand >>>> > > > >>>>> there are two options, he can >>>> ignore the unknown >>>> > > > >> parameters >>>> > > > >>>> or >>>> > > > >>>>> reject >>>> > > > >>>>> the offer. >>>> > > > >>>>> Rejecting the offer in that case is >>>> not really kosher. >>>> > > > >>>>> You are required to ignore parameters >>>> you do not >>>> > > > understand. >>>> > > > >>>>> >>>> > > > >>>>> If you reject something because you >>>> don't like the >>>> > > > parameters >>>> > > > >> it >>>> > > > >>>>> contains, then that is an implicit >>>> statement that you >>>> > > > >> understand >>>> > > > >>>>> those parameters well enough to >>>> decide to reject them. >>>> > > > >>>>> >>>> > > > >>>>> As far as I know, you are always free to reject >>>> > offers, and it >>>> > > > >>>> doesn't >>>> > > > >>>>> really imply anything when you do that.. >>>> Whether it is wise >>>> > is >>>> > > > >>>> perhaps >>>> > > > >>>>> a different question. >>>> > > > >>>>> Stephen Botzko >>>> > > > >>>> >>>> > > > >>>> Certainly you are always free to reject an >>>>offer. >>>> > > > >>>> In general I don't know for certain the reason >>>>why, >>>> > and so if I >>>> > > > give >>>> > > > >>>> you >>>> > > > >>>> the benefit of the doubt I will assume you have >>>>a >>>> > valid reason >>>> > - >>>> > > > >>>> perhaps >>>> > > > >>>> just policy. >>>> > > > >>>> >>>> > > > >>>> But if the reason you reject the offer is >>>> based on your >>>> > > violating >>>> > > > a >>>> > > > >>>> spec, then you are non-conforming, whether I can >>>> > determine you >>>> > > are >>>> > > > >>>> non-conforming or not. Whether being >>>> non-conforming is just >>>> > > > un-wise, >>>> > > > >> or >>>> > > > >>>> something stronger, is a separate discussion. >>>>The >>>> > IETF does not >>>> > > > levy >>>> > > > >>>> any >>>> > > > >>>> penalties for violating its specs. But >>>> sometimes the market >>>> > > does. >>>> > > > >> (And >>>> > > > >>>> sometimes not.) But we don't need to endorse >>>> non-conforming >>>> > > > behavior >>>> > > > >> in >>>> > > > >>>> our documents. >>>> > > > >>>> >>>> > > > >>>> Thanks, >>>> > > > >>>> Paul >>>> > > > >>>> _______________________________________________ >>>> > > > >>>> clue mailing list >>>> > > > >>>> clue@ietf.org >>>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue >>>> > > > >>> >>>> > > > >>> >>>> > > > > >>>> > > > > >>>> > > > _______________________________________________ >>>> > > > clue mailing list >>>> > > > clue@ietf.org >>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>> > > >>>> > > _______________________________________________ >>>> > > clue mailing list >>>> > > clue@ietf.org >>>> > > https://www.ietf.org/mailman/listinfo/clue >>>> > >>>> _______________________________________________ >>>> 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 stewe@stewe.org Fri May 27 10:33:26 2011 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 4DEB8E0843 for ; Fri, 27 May 2011 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.723, 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 2ZvEmfnTxu2g for ; Fri, 27 May 2011 10:33:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 62C69E080F for ; Fri, 27 May 2011 10:33:24 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 5621-1743317 for multiple; Fri, 27 May 2011 19:33:23 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 27 May 2011 10:33:14 -0700 From: Stephan Wenger To: Paul Kyzivat , "Elwell, John" Message-ID: Thread-Topic: [clue] legacy support in requirements In-Reply-To: <4DDFDE5C.2040209@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:33:26 -0000 As for SHOULD/MUST: I'm in favor of SHOULD, and the criteria would "if it can be done without adding excessive call setup delay, i.e. more than one round-trip time. Stephan On 5.27.2011 10:24 , "Paul Kyzivat" wrote: >Allyn, > >It seems that what I suggested is the latest preference. Here it is >again. I think it is a new requirement in addition to the existing >REQMT-10: > >=========================== >REQMT-XYZ: The solution SHOULD/MUST make it possible for endpoints >without support for telepresence extensions to participate in a >telepresence session with those that do. >=========================== > >I dropped "mechanism" from John's because its unlikely to be a new >mechanism that makes this possible. (That would require changes to the >legacy systems.) Rather it will need to be the manner of using existing >mechanisms. > >And I changed "telepresence conference" to "telepresence session" >because this ought to work point-point as well as for conferences. >(But we probably need more definition work here, since neither >telepresence-conference nor telepresence-session is currently defined.) > >And I don't know if this ought to be SHOULD/MUST. I could go either way >on that, but if its SHOULD, then we ought to add some words on what the >criteria are for not doing it. > > Thanks, > Paul > >On 5/27/2011 12:28 PM, Elwell, John wrote: >> I was quite happy with the refinements that Paul suggested, which I >>hope help. Unfortunately I will not be available during the next couple >>of weeks, so I will have to leave it to others to help arrive at >>appropriate words. >> >> John >> >>> -----Original Message----- >>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>> Sent: 27 May 2011 16:39 >>> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> Hi John, >>> Your suggestion is >>> >>> The solution MUST include a mechanism that makes it >>> possible for endpoints with different capabilities to >>> interoperate in a telepresence conference, including >>> audio/video endpoints that do not support any telepresence extensions. >>> >>> I have redone the requirements so that the reqmt for heterogeneous >>> devices as in the use case, which was reqmt 10, is now more specific. >>> So, we would not piggy back legacy on the hetereogeneity requirement. >>> >>> Assuming this now refers only to the interaction of CLUE and >>> non-CLUE, >>> the problem is that they don't interoperate in a telepresence >>> sense- the >>> purpose for the WG. >>> >>> Therefore, I would ask you to be more specific about the legacy >>> requirement. I should think that the general meaning would be >>> along the >>> lines of that CLUE would not break any existing interworking - however >>> this is general, and it would be good to make it more specific. >>> >>> I think it would be really helpful if you Paul and Roni, and others if >>> they wish, could suggest some new text to more specifically cover what >>> you have in mind which has been discussed in detail on the list. >>> >>> Thanks, >>> Allyn >>> >>> >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Thursday, May 26, 2011 11:22 PM >>> To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) >>> Cc: clue@ietf.org >>> Subject: RE: [clue] legacy support in requirements >>> >>> Allyn, >>> >>> I already made a proposal: >>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>> Sent: 26 May 2011 20:08 >>>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> Roni, Paul, John- >>>> Would you care to suggest the wording you would like to see as a >>>> requirement for legacy interoperability? That would be helpful. >>>> >>>> Thanks, >>>> Allyn >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>>> Roni Even >>>>> Sent: Wednesday, May 18, 2011 11:13 AM >>>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>> .... >>>>> >>>>> Anyhow we are discussing solution while my point is that we >>>> will need >>>>> as a >>>>> requirement to address the case of a call from a CLUE >>> aware endpoint >>>> to >>>>> a >>>>> non CLUE aware endpoint. Even if the consensus will be to have the >>>>> preferred >>>>> video in the first video m-line. >>>>> >>>>> Regards >>>>> Roni >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>>> Sent: Wednesday, May 18, 2011 4:41 PM >>>>>> To: Paul Kyzivat (pkyzivat); Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] legacy support in requirements >>>>>> >>>>>> Paul, >>>>>> >>>>>> I would agree that if the offer-answer model semantic >>> is that here >>>>> are >>>>>> several options and any subset of options is acceptable. >>>>>> >>>>>> However, if there is any grouping involved such that you need to >>>> have >>>>> a >>>>>> video and audio feed integrated to make sense then watch out. >>>>>> >>>>>> For example, I wouldn't want to end up with the result >>> of a man's >>>>> video >>>>>> paired with a woman's voice. That could be rather comical. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>> Of >>>>>> Paul Kyzivat (pkyzivat) >>>>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>>> Paul, >>>>>>> I think we read it differently. >>>>>>> If the answerer does not support the group attribute >>>> and the offer >>>>>> had >>>>>> the >>>>>>> fid semantics it may look to the answerer as an offer with >>>> multiple >>>>>> m-lines >>>>>>> of the same media tyoe. In this case an implementation >>>> might also >>>>>> decide to >>>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>>>> Acceptable), >>>>>>> because it contains several "m" lines of the same media type. >>>>>> >>>>>> That is a slightly different story. >>>>>> >>>>>> Then the reason for rejection is not because it saw an >>>> attribute it >>>>>> didn't understand - its because it didn't like >>> something it *did* >>>>>> understand. >>>>>> >>>>>>> This is very relevant to the multiple streams case >>> and we should >>>>> look >>>>>> if we >>>>>>> state this behavior or we will look at providing an >>>> approach that >>>>>> will >>>>>> allow >>>>>>> the answerer to choose one m-line that the offerer >>>> prefers even of >>>>> it >>>>>> does >>>>>>> not understand CLUE. >>>>>> >>>>>> IMO (lets see if others differ), if a UA receives an >>> offer with at >>>>>> least >>>>>> >>>>>> one m-line it is happy with, then it should not reject the call >>>>> because >>>>>> there are others that it does not "understand". >>>>>> >>>>>> Here "understand" means something different - presumably it does >>>>>> understand the direct meaning of the additional m-line, it just >>>>> doesn't >>>>>> understand the *significance* or use of it. >>>>>> >>>>>> I see little difference to getting to audio m-lines and >>>> only wanting >>>>>> one, and getting one audio and one video and only >>>> supporting audio. >>>>> In >>>>>> general you should not reject an audio/video call just >>> because you >>>>> only >>>>>> support audio. >>>>>> >>>>>> I think it will behoove clue to strongly recommend that >>>> the m-lines >>>>> in >>>>>> an offer be arranged so the first ones are the ones it >>> most wants >>>>> used >>>>>> if not all are. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>>>> To: Roni Even >>>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>>>> Paul, >>>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>> example >>>>>>>>> Roni >>>>>>>> >>>>>>>> OK, I looked. It is consistent with what I said. >>>>>>>> Either a=group: is understood, or not. If not, its >>> ignored, and >>>>> not >>>>>> put >>>>>>>> in the answer. Same with a=mid: >>>>>>>> >>>>>>>> If a=group: *is* understood, but some parameter within >>>> it is not, >>>>>> there >>>>>>>> are explicit rules for what to do. >>>>>>>> >>>>>>>> AFAICT there are no examples in this document where >>> failure to >>>>>>>> understand an a-line in total (or even in part) results in >>>>> rejecting >>>>>>>> the >>>>>>>> offer. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On >>>>>> Behalf >>>>>>>> Of >>>>>>>>>> Paul Kyzivat >>>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>>>> To: Stephen Botzko >>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>>>> >>>>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>>>> >>>>>>>>>>> When the offer includes parameters that >>>> the answerer >>>>>> does >>>>>>>> not >>>>>>>>>>> understand >>>>>>>>>>> there are two options, he can ignore the unknown >>>>>>>> parameters >>>>>>>>>> or >>>>>>>>>>> reject >>>>>>>>>>> the offer. >>>>>>>>>>> Rejecting the offer in that case is not >>> really kosher. >>>>>>>>>>> You are required to ignore parameters you do not >>>>>> understand. >>>>>>>>>>> >>>>>>>>>>> If you reject something because you don't like the >>>>>> parameters >>>>>>>> it >>>>>>>>>>> contains, then that is an implicit >>> statement that you >>>>>>>> understand >>>>>>>>>>> those parameters well enough to decide to >>> reject them. >>>>>>>>>>> >>>>>>>>>>> As far as I know, you are always free to reject >>>> offers, and it >>>>>>>>>> doesn't >>>>>>>>>>> really imply anything when you do that.. Whether >>> it is wise >>>> is >>>>>>>>>> perhaps >>>>>>>>>>> a different question. >>>>>>>>>>> Stephen Botzko >>>>>>>>>> >>>>>>>>>> Certainly you are always free to reject an offer. >>>>>>>>>> In general I don't know for certain the reason why, >>>> and so if I >>>>>> give >>>>>>>>>> you >>>>>>>>>> the benefit of the doubt I will assume you have a >>>> valid reason >>>> - >>>>>>>>>> perhaps >>>>>>>>>> just policy. >>>>>>>>>> >>>>>>>>>> But if the reason you reject the offer is based on your >>>>> violating >>>>>> a >>>>>>>>>> spec, then you are non-conforming, whether I can >>>> determine you >>>>> are >>>>>>>>>> non-conforming or not. Whether being non-conforming is just >>>>>> un-wise, >>>>>>>> or >>>>>>>>>> something stronger, is a separate discussion. The >>>> IETF does not >>>>>> levy >>>>>>>>>> any >>>>>>>>>> penalties for violating its specs. But sometimes the market >>>>> does. >>>>>>>> (And >>>>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>>>> behavior >>>>>>>> in >>>>>>>>>> our documents. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Fri May 27 10:33:39 2011 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 C8D7BE0845 for ; Fri, 27 May 2011 10:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.332 X-Spam-Level: X-Spam-Status: No, score=-110.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wYYgmwzC2Ufq for ; Fri, 27 May 2011 10:33:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC2E080F for ; Fri, 27 May 2011 10:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=17195; q=dns/txt; s=iport; t=1306517618; x=1307727218; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=HuLHm0HR4nJdLMq5ERVjjQTLSaLNBvvW8dY+2Dj2msQ=; b=G8+xVQpLMAURlsCqwqPbViCIwuuWYzHWaWLMi4Urjniew68f2PYckn/Y MzhFCj2Xr9Ivwgn4wpaRnt4culGwsjlKxR4be9RNlCe+gUhqI/T+Fp3wR eyZch1PlytCCiCewlscJPVyF1MBpvwds/45GOwryKAZeUK1INtauMP0J9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAD3g302tJXHB/2dsb2JhbAA3Hpdtjk53iHCgAZAljTKGHgSQQ4Q7hCeGTw X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="286064718" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 27 May 2011 17:33:35 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHXYBR004986 for ; Fri, 27 May 2011 17:33:34 GMT Message-ID: <4DDFE06E.7010902@cisco.com> Date: Fri, 27 May 2011 13:33:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com><023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com><4DDFA0C8.1050509@cisco.com> <4DDFDC56.6010205@cisco.com> In-Reply-To: <4DDFDC56.6010205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:33:39 -0000 On 5/27/2011 1:16 PM, Paul Kyzivat wrote: > I intentionally wrote SHOULD/MUST because I was uncertain which one to > use. It bears discussion. OOPS - I didn't. (I had started to, in a proposal I was writing before I saw John's and liked it.) But I just sent a new revision that defers the SHOULD/MUST decision. Sorry, Paul > Thanks, > Paul > > On 5/27/2011 10:05 AM, Parthasarathi R (partr) wrote: >> Paul, >> >> I have the doubt whether this requirement has to be "MUST" or "SHOULD" >> because CLUE (telepresence) end-point may not like to interop with >> simple audio end-point (SIP UA). It may be just policy not to received >> audio-call in CLUE endpoint because of better utilization of costly >> resources. Please let me know your opinion here. >> >> Apart from this doubt, I like your requirement proposal. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Elwell, John >> Sent: Friday, May 27, 2011 7:25 PM >> To: Paul Kyzivat (pkyzivat); clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> Yes, I like Paul's changes. >> >> John >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 27 May 2011 14:02 >>> To: clue@ietf.org >>> Subject: Re: [clue] legacy support in requirements >>> >>> >>> >>> On 5/27/2011 8:28 AM, Elwell, John wrote: >>>> I can live with Steve's proposal. I also don't mind >>> separating the requirements, but I don't think we should refer to CLUE >> >>> in the requirement - the RFC will live a long time after CLUE is >>> finished and closed down. So if we want to separate the requirements, >>> I would propose: >>>> >>>> REQMT-10: The solution MUST include a mechanism that makes >>> it possible for endpoints with different capabilities to interoperate >>> in a telepresence conference. >>>> REQMT-10bis: The solution MUST include a mechanism that >>> makes it possible for endpoints without support for telepresence >>> extensions to participate in a telepresence conference with those that >> >>> do. >>> >>> How about the following variant of that: >>> >>> REQMT-10bis: The solution MUST make it possible for endpoints without >> >>> support for telepresence extensions to participate in a telepresence >>> session with those that do. >>> >>> I dropped "mechanism" because its unlikely to be a new mechanism that >>> makes this possible. (That would require changes to the legacy >>> systems.) Rather it will need to be the manner of using existing >>> mechanisms. >>> >>> And I changed "telepresence conference" to "telepresence session" >>> because this ought to work point-point as well as for conferences. >>> (But we probably need more definition work here, since neither >>> telepresence-conference nor telepresence-session is currently >>> defined.) >>> >>> Thanks, >>> Paul >>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>>> Sent: 27 May 2011 12:23 >>>>> To: Stephen Botzko; Elwell, John >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] legacy support in requirements >>>>> >>>>> I think it would be clearer to formulate two different requirements >>>>> >>>>> >>>>> >>>>> 1) Two solution must provide a mechanism that make it >>>>> possible for endpoints with different capabilities to interoperate, >> >>>>> e.g. interoperability between a 2 camera/screens and 3 >>>>> camera/screens endpoint. >>>>> >>>>> 2) Two solution must provide a mechanism that make it >>>>> possible for endpoints that are CLUE aware to interoperate with >>>>> CLUE-less endpoints. >>>>> >>>>> >>>>> >>>>> Cheers >>>>> >>>>> >>>>> >>>>> -Espen >>>>> >>>>> >>>>> >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Stephen Botzko >>>>> Sent: 27. mai 2011 13:16 >>>>> To: Elwell, John >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> I'm not sure that the language actually covers that (it seems >>>>> ambiguous). >>>>> >>>>> What do you think about changing "endpoints with different >>>>> capabilities" to "disparate devices"? >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>>> wrote: >>>>> >>>>> I thought requirement 10 would cover both (signalling/protocol >>>>> capabilities as well as user interface capabilities). >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>>> >>>>>> Sent: 27 May 2011 11:53 >>>>>> To: Elwell, John >>>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat); >>>>>> clue@ietf.org >>>>> >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> Do you think that the language in requirement 10 means "SIP >>>>>> capabilities"? Or something else? >>>>>> >>>>>> I am thinking that issue is really about the signaling/protocol >>>>>> design itself, and isn't directly related to how many screens and >>>>>> cameras a system might have. >>>>>> >>>>>> Stephen Botzko >>>>>> >>>>>> >>>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>>> wrote: >>>>>> >>>>>> >>>>>> Allyn, >>>>>> >>>>>> I already made a proposal: >>>>>> >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> > -----Original Message----- >>>>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>>> >>>>>> > Sent: 26 May 2011 20:08 >>>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>>> > Cc: clue@ietf.org >>>>>> > Subject: RE: [clue] legacy support in requirements >>>>>> > >>>>>> > Roni, Paul, John- >>>>>> > Would you care to suggest the wording you would like to >>>>>> see as a >>>>>> > requirement for legacy interoperability? That would be >>>>>> helpful. >>>>>> > >>>>>> > Thanks, >>>>>> > Allyn >>>>>> > >>>>>> > > -----Original Message----- >>>>>> > > From: clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>>> > Of >>>>>> > > Roni Even >>>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>>> > > Cc: clue@ietf.org >>>>>> > > Subject: Re: [clue] legacy support in requirements >>>>>> > > >>>>>> > .... >>>>>> > > >>>>>> > > Anyhow we are discussing solution while my point >>>>> is that we >>>>>> > will need >>>>>> > > as a >>>>>> > > requirement to address the case of a call from a CLUE >> >>>>>> aware endpoint >>>>>> > to >>>>>> > > a >>>>>> > > non CLUE aware endpoint. Even if the consensus will >>>>>> be to have the >>>>>> > > preferred >>>>>> > > video in the first video m-line. >>>>>> > > >>>>>> > > Regards >>>>>> > > Roni >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > > -----Original Message----- >>>>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>>> > > > Cc: clue@ietf.org >>>>>> > > > Subject: RE: [clue] legacy support in requirements >>>>>> > > > >>>>>> > > > Paul, >>>>>> > > > >>>>>> > > > I would agree that if the offer-answer model >>>>>> semantic is that here >>>>>> > > are >>>>>> > > > several options and any subset of options >>> is acceptable. >>>>>> > > > >>>>>> > > > However, if there is any grouping involved such >>>>>> that you need to >>>>>> > have >>>>>> > > a >>>>>> > > > video and audio feed integrated to make sense then >> >>>>>> watch out. >>>>>> > > > >>>>>> > > > For example, I wouldn't want to end up with the >>>>>> result of a man's >>>>>> > > video >>>>>> > > > paired with a woman's voice. That could be rather >> >>>>>> comical. >>>>>> > > > >>>>>> > > > Mike >>>>>> > > > >>>>>> > > > >>>>>> > > > -----Original Message----- >>>>>> > > > From: clue-bounces@ietf.org >>>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>>> > > Of >>>>>> > > > Paul Kyzivat (pkyzivat) >>>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>>> > > > To: Roni Even >>>>>> > > > Cc: clue@ietf.org >>>>>> > > > Subject: Re: [clue] legacy support in requirements >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>> > > > > Paul, >>>>>> > > > > I think we read it differently. >>>>>> > > > > If the answerer does not support the >>> group attribute >>>>>> > and the offer >>>>>> > > > had >>>>>> > > > the >>>>>> > > > > fid semantics it may look to the answerer as an >> >>>>>> offer with >>>>>> > multiple >>>>>> > > > m-lines >>>>>> > > > > of the same media tyoe. In this case >>> an implementation >>>>>> > might also >>>>>> > > > decide to >>>>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>>>> Here, or 606 Not >>>>>> > > > Acceptable), >>>>>> > > > > because it contains several "m" lines of the >>>>>> same media type. >>>>>> > > > >>>>>> > > > That is a slightly different story. >>>>>> > > > >>>>>> > > > Then the reason for rejection is not >>> because it saw an >>>>>> > attribute it >>>>>> > > > didn't understand - its because it didn't like >>>>>> something it *did* >>>>>> > > > understand. >>>>>> > > > >>>>>> > > > > This is very relevant to the multiple streams >>>>>> case and we should >>>>>> > > look >>>>>> > > > if we >>>>>> > > > > state this behavior or we will look at >>> providing an >>>>>> > approach that >>>>>> > > > will >>>>>> > > > allow >>>>>> > > > > the answerer to choose one m-line that >>> the offerer >>>>>> > prefers even of >>>>>> > > it >>>>>> > > > does >>>>>> > > > > not understand CLUE. >>>>>> > > > >>>>>> > > > IMO (lets see if others differ), if a UA receives >>>>>> an offer with at >>>>>> > > > least >>>>>> > > > >>>>>> > > > one m-line it is happy with, then it should not >>>>>> reject the call >>>>>> > > because >>>>>> > > > there are others that it does not "understand". >>>>>> > > > >>>>>> > > > Here "understand" means something different - >>>>>> presumably it does >>>>>> > > > understand the direct meaning of the additional >>>>>> m-line, it just >>>>>> > > doesn't >>>>>> > > > understand the *significance* or use of it. >>>>>> > > > >>>>>> > > > I see little difference to getting to >>> audio m-lines and >>>>>> > only wanting >>>>>> > > > one, and getting one audio and one video and only >>>>>> > supporting audio. >>>>>> > > In >>>>>> > > > general you should not reject an audio/video call >>>>>> just because you >>>>>> > > only >>>>>> > > > support audio. >>>>>> > > > >>>>>> > > > I think it will behoove clue to strongly >>> recommend that >>>>>> > the m-lines >>>>>> > > in >>>>>> > > > an offer be arranged so the first ones are the >>>>>> ones it most wants >>>>>> > > used >>>>>> > > > if not all are. >>>>>> > > > >>>>>> > > > Thanks, >>>>>> > > > Paul >>>>>> > > > >>>>>> > > > > Roni >>>>>> > > > > >>>>>> > > > >> -----Original Message----- >>>>>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>> > > > >> To: Roni Even >>>>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>> > > > >> Subject: Re: [clue] legacy support in >>> requirements >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>> > > > >>> Paul, >>>>>> > > > >>> Look at >>>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>> > > > example >>>>>> > > > >>> Roni >>>>>> > > > >> >>>>>> > > > >> OK, I looked. It is consistent with >>> what I said. >>>>>> > > > >> Either a=group: is understood, or not. If not, >> >>>>>> its ignored, and >>>>>> > > not >>>>>> > > > put >>>>>> > > > >> in the answer. Same with a=mid: >>>>>> > > > >> >>>>>> > > > >> If a=group: *is* understood, but some >>>>> parameter within >>>>>> > it is not, >>>>>> > > > there >>>>>> > > > >> are explicit rules for what to do. >>>>>> > > > >> >>>>>> > > > >> AFAICT there are no examples in this document >>>>>> where failure to >>>>>> > > > >> understand an a-line in total (or even in >>>>>> part) results in >>>>>> > > rejecting >>>>>> > > > >> the >>>>>> > > > >> offer. >>>>>> > > > >> >>>>>> > > > >> Thanks, >>>>>> > > > >> Paul >>>>>> > > > >> >>>>>> > > > >>>> -----Original Message----- >>>>>> > > > >>>> From: clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] On >>>>>> > > > Behalf >>>>>> > > > >> Of >>>>>> > > > >>>> Paul Kyzivat >>>>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> > > > >>>> To: Stephen Botzko >>>>>> > > > >>>> Cc: clue@ietf.org >>>>>> > > > >>>> Subject: Re: [clue] legacy support >>> in requirements >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>> > > > >>>> >>>>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni >>> Even wrote: >>>>>> > > > >>>> >>>>>> > > > >>>>> When the offer includes >>> parameters that >>>>>> > the answerer >>>>>> > > > does >>>>>> > > > >> not >>>>>> > > > >>>>> understand >>>>>> > > > >>>>> there are two options, he can >>>>>> ignore the unknown >>>>>> > > > >> parameters >>>>>> > > > >>>> or >>>>>> > > > >>>>> reject >>>>>> > > > >>>>> the offer. >>>>>> > > > >>>>> Rejecting the offer in that case is >>>>>> not really kosher. >>>>>> > > > >>>>> You are required to ignore parameters >>>>>> you do not >>>>>> > > > understand. >>>>>> > > > >>>>> >>>>>> > > > >>>>> If you reject something because you >>>>>> don't like the >>>>>> > > > parameters >>>>>> > > > >> it >>>>>> > > > >>>>> contains, then that is an implicit >>>>>> statement that you >>>>>> > > > >> understand >>>>>> > > > >>>>> those parameters well enough to >>>>>> decide to reject them. >>>>>> > > > >>>>> >>>>>> > > > >>>>> As far as I know, you are always >>> free to reject >>>>>> > offers, and it >>>>>> > > > >>>> doesn't >>>>>> > > > >>>>> really imply anything when you do that.. >>>>>> Whether it is wise >>>>>> > is >>>>>> > > > >>>> perhaps >>>>>> > > > >>>>> a different question. >>>>>> > > > >>>>> Stephen Botzko >>>>>> > > > >>>> >>>>>> > > > >>>> Certainly you are always free to >>> reject an offer. >>>>>> > > > >>>> In general I don't know for certain >>> the reason why, >>>>>> > and so if I >>>>>> > > > give >>>>>> > > > >>>> you >>>>>> > > > >>>> the benefit of the doubt I will >>> assume you have a >>>>>> > valid reason >>>>>> > - >>>>>> > > > >>>> perhaps >>>>>> > > > >>>> just policy. >>>>>> > > > >>>> >>>>>> > > > >>>> But if the reason you reject the offer is >>>>>> based on your >>>>>> > > violating >>>>>> > > > a >>>>>> > > > >>>> spec, then you are non-conforming, >>> whether I can >>>>>> > determine you >>>>>> > > are >>>>>> > > > >>>> non-conforming or not. Whether being >>>>>> non-conforming is just >>>>>> > > > un-wise, >>>>>> > > > >> or >>>>>> > > > >>>> something stronger, is a separate >>> discussion. The >>>>>> > IETF does not >>>>>> > > > levy >>>>>> > > > >>>> any >>>>>> > > > >>>> penalties for violating its specs. But >>>>>> sometimes the market >>>>>> > > does. >>>>>> > > > >> (And >>>>>> > > > >>>> sometimes not.) But we don't need to endorse >> >>>>>> non-conforming >>>>>> > > > behavior >>>>>> > > > >> in >>>>>> > > > >>>> our documents. >>>>>> > > > >>>> >>>>>> > > > >>>> Thanks, >>>>>> > > > >>>> Paul >>>>>> > > > >>>> >>> _______________________________________________ >>>>>> > > > >>>> clue mailing list >>>>>> > > > >>>> clue@ietf.org >>>>>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> > > > >>> >>>>>> > > > >>> >>>>>> > > > > >>>>>> > > > > >>>>>> > > > _______________________________________________ >>>>>> > > > clue mailing list >>>>>> > > > clue@ietf.org >>>>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>>>> > > >>>>>> > > _______________________________________________ >>>>>> > > clue mailing list >>>>>> > > clue@ietf.org >>>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>>> > >>>>>> _______________________________________________ >>>>>> 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 allyn@cisco.com Fri May 27 10:37:03 2011 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 3F6F2E0813 for ; Fri, 27 May 2011 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 MMRH7ETN7nRj for ; Fri, 27 May 2011 10:37:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id C1344E080F for ; Fri, 27 May 2011 10:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=13150; q=dns/txt; s=iport; t=1306517821; x=1307727421; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=S1j7YzsdjuLRwRLAOT/sBEFiot8PXfuamyfxkjUKPAo=; b=Istb1GXwOKO6+h7wfV9XbQW47uYiaHJqmARco0GClQtyrBnUsGx5boJc TuCcE5n7n6ZRAz7cXLJBEeorqnhh2BgkIz/oIpVdwMI0wBo3fCV6VrJxx MOnfxkLPwa/jPfQT9ulg3PT9zxh1jkXZMMaj3ruI6yHzTdjv4ES06VKtY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAJ3g302rRDoH/2dsb2JhbAA3Hpdtjk53iHCgB5AljTKGHgSGY44kinE X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="704560272" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 May 2011 17:37:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHb1tg016270; Fri, 27 May 2011 17:37:01 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 10:37:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 10:36:59 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B85ED@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4DDFDE5C.2040209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] legacy support in requirements Thread-Index: Acwckv4QWIqSV8NJQteAhNts5FrlYAAAYrOA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com><9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com><011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com><4DD27E5F.6070200@cisco.com><4DD2901F.2000906@cisco.com><01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com><4DD2EA8A.7070407@cisco.com><01b501cc14de$9127c660$b3775320$%roni@huawei.com><4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B8535@xmb-sjc-221.amer.cisco.com> <4DDFDE5C.2040209@cisco.com> From: "Allyn Romanow (allyn)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 27 May 2011 17:37:01.0355 (UTC) FILETIME=[AF9707B0:01CC1C94] Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:37:03 -0000 Great! I must've missed seeing this before I responded to John. This works for me. Allyn > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Friday, May 27, 2011 10:25 AM > To: Elwell, John > Cc: Allyn Romanow (allyn); Roni Even; clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Allyn, >=20 > It seems that what I suggested is the latest preference. Here it is > again. I think it is a new requirement in addition to the existing > REQMT-10: >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > REQMT-XYZ: The solution SHOULD/MUST make it possible for endpoints > without support for telepresence extensions to participate in a > telepresence session with those that do. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > I dropped "mechanism" from John's because its unlikely to be a new > mechanism that makes this possible. (That would require changes to the > legacy systems.) Rather it will need to be the manner of using existing > mechanisms. >=20 > And I changed "telepresence conference" to "telepresence session" > because this ought to work point-point as well as for conferences. > (But we probably need more definition work here, since neither > telepresence-conference nor telepresence-session is currently defined.) >=20 > And I don't know if this ought to be SHOULD/MUST. I could go either way > on that, but if its SHOULD, then we ought to add some words on what the > criteria are for not doing it. >=20 > Thanks, > Paul >=20 > On 5/27/2011 12:28 PM, Elwell, John wrote: > > I was quite happy with the refinements that Paul suggested, which I > hope help. Unfortunately I will not be available during the next couple > of weeks, so I will have to leave it to others to help arrive at > appropriate words. > > > > John > > > >> -----Original Message----- > >> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >> Sent: 27 May 2011 16:39 > >> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) > >> Cc: clue@ietf.org > >> Subject: RE: [clue] legacy support in requirements > >> > >> Hi John, > >> Your suggestion is > >> > >> The solution MUST include a mechanism that makes it > >> possible for endpoints with different capabilities to > >> interoperate in a telepresence conference, including > >> audio/video endpoints that do not support any telepresence > extensions. > >> > >> I have redone the requirements so that the reqmt for heterogeneous > >> devices as in the use case, which was reqmt 10, is now more > specific. > >> So, we would not piggy back legacy on the hetereogeneity > requirement. > >> > >> Assuming this now refers only to the interaction of CLUE and > >> non-CLUE, > >> the problem is that they don't interoperate in a telepresence > >> sense- the > >> purpose for the WG. > >> > >> Therefore, I would ask you to be more specific about the legacy > >> requirement. I should think that the general meaning would be > >> along the > >> lines of that CLUE would not break any existing interworking - > however > >> this is general, and it would be good to make it more specific. > >> > >> I think it would be really helpful if you Paul and Roni, and others > if > >> they wish, could suggest some new text to more specifically cover > what > >> you have in mind which has been discussed in detail on the list. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Thursday, May 26, 2011 11:22 PM > >> To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) > >> Cc: clue@ietf.org > >> Subject: RE: [clue] legacy support in requirements > >> > >> Allyn, > >> > >> I already made a proposal: > >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>> Sent: 26 May 2011 20:08 > >>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > >>> Cc: clue@ietf.org > >>> Subject: RE: [clue] legacy support in requirements > >>> > >>> Roni, Paul, John- > >>> Would you care to suggest the wording you would like to see as a > >>> requirement for legacy interoperability? That would be helpful. > >>> > >>> Thanks, > >>> Allyn > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org > >> [mailto:clue-bounces@ietf.org] On Behalf > >>> Of > >>>> Roni Even > >>>> Sent: Wednesday, May 18, 2011 11:13 AM > >>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > >>>> Cc: clue@ietf.org > >>>> Subject: Re: [clue] legacy support in requirements > >>>> > >>> .... > >>>> > >>>> Anyhow we are discussing solution while my point is that we > >>> will need > >>>> as a > >>>> requirement to address the case of a call from a CLUE > >> aware endpoint > >>> to > >>>> a > >>>> non CLUE aware endpoint. Even if the consensus will be to have the > >>>> preferred > >>>> video in the first video m-line. > >>>> > >>>> Regards > >>>> Roni > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > >>>>> Sent: Wednesday, May 18, 2011 4:41 PM > >>>>> To: Paul Kyzivat (pkyzivat); Roni Even > >>>>> Cc: clue@ietf.org > >>>>> Subject: RE: [clue] legacy support in requirements > >>>>> > >>>>> Paul, > >>>>> > >>>>> I would agree that if the offer-answer model semantic > >> is that here > >>>> are > >>>>> several options and any subset of options is acceptable. > >>>>> > >>>>> However, if there is any grouping involved such that you need to > >>> have > >>>> a > >>>>> video and audio feed integrated to make sense then watch out. > >>>>> > >>>>> For example, I wouldn't want to end up with the result > >> of a man's > >>>> video > >>>>> paired with a woman's voice. That could be rather comical. > >>>>> > >>>>> Mike > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org > >>> [mailto:clue-bounces@ietf.org] On Behalf > >>>> Of > >>>>> Paul Kyzivat (pkyzivat) > >>>>> Sent: Tuesday, May 17, 2011 7:45 PM > >>>>> To: Roni Even > >>>>> Cc: clue@ietf.org > >>>>> Subject: Re: [clue] legacy support in requirements > >>>>> > >>>>> > >>>>> > >>>>> On 5/17/2011 6:05 PM, Roni Even wrote: > >>>>>> Paul, > >>>>>> I think we read it differently. > >>>>>> If the answerer does not support the group attribute > >>> and the offer > >>>>> had > >>>>> the > >>>>>> fid semantics it may look to the answerer as an offer with > >>> multiple > >>>>> m-lines > >>>>>> of the same media tyoe. In this case an implementation > >>> might also > >>>>> decide to > >>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > >>>>> Acceptable), > >>>>>> because it contains several "m" lines of the same media type. > >>>>> > >>>>> That is a slightly different story. > >>>>> > >>>>> Then the reason for rejection is not because it saw an > >>> attribute it > >>>>> didn't understand - its because it didn't like > >> something it *did* > >>>>> understand. > >>>>> > >>>>>> This is very relevant to the multiple streams case > >> and we should > >>>> look > >>>>> if we > >>>>>> state this behavior or we will look at providing an > >>> approach that > >>>>> will > >>>>> allow > >>>>>> the answerer to choose one m-line that the offerer > >>> prefers even of > >>>> it > >>>>> does > >>>>>> not understand CLUE. > >>>>> > >>>>> IMO (lets see if others differ), if a UA receives an > >> offer with at > >>>>> least > >>>>> > >>>>> one m-line it is happy with, then it should not reject the call > >>>> because > >>>>> there are others that it does not "understand". > >>>>> > >>>>> Here "understand" means something different - presumably it does > >>>>> understand the direct meaning of the additional m-line, it just > >>>> doesn't > >>>>> understand the *significance* or use of it. > >>>>> > >>>>> I see little difference to getting to audio m-lines and > >>> only wanting > >>>>> one, and getting one audio and one video and only > >>> supporting audio. > >>>> In > >>>>> general you should not reject an audio/video call just > >> because you > >>>> only > >>>>> support audio. > >>>>> > >>>>> I think it will behoove clue to strongly recommend that > >>> the m-lines > >>>> in > >>>>> an offer be arranged so the first ones are the ones it > >> most wants > >>>> used > >>>>> if not all are. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Roni > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM > >>>>>>> To: Roni Even > >>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org > >>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>>>>>> Paul, > >>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>>>> example > >>>>>>>> Roni > >>>>>>> > >>>>>>> OK, I looked. It is consistent with what I said. > >>>>>>> Either a=3Dgroup: is understood, or not. If not, its > >> ignored, and > >>>> not > >>>>> put > >>>>>>> in the answer. Same with a=3Dmid: > >>>>>>> > >>>>>>> If a=3Dgroup: *is* understood, but some parameter within > >>> it is not, > >>>>> there > >>>>>>> are explicit rules for what to do. > >>>>>>> > >>>>>>> AFAICT there are no examples in this document where > >> failure to > >>>>>>> understand an a-line in total (or even in part) results in > >>>> rejecting > >>>>>>> the > >>>>>>> offer. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: clue-bounces@ietf.org > >> [mailto:clue-bounces@ietf.org] On > >>>>> Behalf > >>>>>>> Of > >>>>>>>>> Paul Kyzivat > >>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>>>>>> To: Stephen Botzko > >>>>>>>>> Cc: clue@ietf.org > >>>>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>>>>>> > >>>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>>>>>> > >>>>>>>>>> When the offer includes parameters that > >>> the answerer > >>>>> does > >>>>>>> not > >>>>>>>>>> understand > >>>>>>>>>> there are two options, he can ignore the unknown > >>>>>>> parameters > >>>>>>>>> or > >>>>>>>>>> reject > >>>>>>>>>> the offer. > >>>>>>>>>> Rejecting the offer in that case is not > >> really kosher. > >>>>>>>>>> You are required to ignore parameters you do not > >>>>> understand. > >>>>>>>>>> > >>>>>>>>>> If you reject something because you don't like the > >>>>> parameters > >>>>>>> it > >>>>>>>>>> contains, then that is an implicit > >> statement that you > >>>>>>> understand > >>>>>>>>>> those parameters well enough to decide to > >> reject them. > >>>>>>>>>> > >>>>>>>>>> As far as I know, you are always free to reject > >>> offers, and it > >>>>>>>>> doesn't > >>>>>>>>>> really imply anything when you do that.. Whether > >> it is wise > >>> is > >>>>>>>>> perhaps > >>>>>>>>>> a different question. > >>>>>>>>>> Stephen Botzko > >>>>>>>>> > >>>>>>>>> Certainly you are always free to reject an offer. > >>>>>>>>> In general I don't know for certain the reason why, > >>> and so if I > >>>>> give > >>>>>>>>> you > >>>>>>>>> the benefit of the doubt I will assume you have a > >>> valid reason > >>> - > >>>>>>>>> perhaps > >>>>>>>>> just policy. > >>>>>>>>> > >>>>>>>>> But if the reason you reject the offer is based on your > >>>> violating > >>>>> a > >>>>>>>>> spec, then you are non-conforming, whether I can > >>> determine you > >>>> are > >>>>>>>>> non-conforming or not. Whether being non-conforming is just > >>>>> un-wise, > >>>>>>> or > >>>>>>>>> something stronger, is a separate discussion. The > >>> IETF does not > >>>>> levy > >>>>>>>>> any > >>>>>>>>> penalties for violating its specs. But sometimes the market > >>>> does. > >>>>>>> (And > >>>>>>>>> sometimes not.) But we don't need to endorse non-conforming > >>>>> behavior > >>>>>>> in > >>>>>>>>> our documents. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> _______________________________________________ > >>>>>>>>> clue mailing list > >>>>>>>>> clue@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> From pkyzivat@cisco.com Fri May 27 10:37:51 2011 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 7173EE0849 for ; Fri, 27 May 2011 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.338 X-Spam-Level: X-Spam-Status: No, score=-110.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ZABGQ10MKsRj for ; Fri, 27 May 2011 10:37:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C5E0847 for ; Fri, 27 May 2011 10:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13417; q=dns/txt; s=iport; t=1306517870; x=1307727470; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vkcL48p1/zMsJNlvoanBWpsW+JSh2CKbZ9KYQ0DeTkc=; b=Bx2gnUzVP0gJfYfHSAPg50JW3/sYSkOxx3lScJfSLGBrCb5J/Yk/kFTk 3qzUTKeB4VsDAHWk5PXu5Uvb3r3Wlbn7nBNUy7u5mJDfFhCoTGtzyR0u9 6ANgmFrzdAfgRmF0feP+S85TUWoMv4g7nuTRgGEon9nMtFwygBDUH6M5o I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAJ3g302rRDoG/2dsb2JhbAA3Hpdtjk53iHCgB5AljTKGHgSQQ4Q7inY X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="455612116" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 27 May 2011 17:37:49 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHbm5O009733; Fri, 27 May 2011 17:37:49 GMT Message-ID: <4DDFE16C.1030106@cisco.com> Date: Fri, 27 May 2011 13:37:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:37:51 -0000 On 5/27/2011 1:33 PM, Stephan Wenger wrote: > As for SHOULD/MUST: > I'm in favor of SHOULD, and the criteria would "if it can be done without > adding excessive call setup delay, i.e. more than one round-trip time. > Stephan I'm ok with that - at least the "excessive" part, but maybe not the i.e. (IMO it would not be unreasonable if it took two o/a cycles in the same INVITE, maybe even three. If it took two separate INVITEs then it seems pretty unreasonable.) Thanks, Paul > On 5.27.2011 10:24 , "Paul Kyzivat" wrote: > >> Allyn, >> >> It seems that what I suggested is the latest preference. Here it is >> again. I think it is a new requirement in addition to the existing >> REQMT-10: >> >> =========================== >> REQMT-XYZ: The solution SHOULD/MUST make it possible for endpoints >> without support for telepresence extensions to participate in a >> telepresence session with those that do. >> =========================== >> >> I dropped "mechanism" from John's because its unlikely to be a new >> mechanism that makes this possible. (That would require changes to the >> legacy systems.) Rather it will need to be the manner of using existing >> mechanisms. >> >> And I changed "telepresence conference" to "telepresence session" >> because this ought to work point-point as well as for conferences. >> (But we probably need more definition work here, since neither >> telepresence-conference nor telepresence-session is currently defined.) >> >> And I don't know if this ought to be SHOULD/MUST. I could go either way >> on that, but if its SHOULD, then we ought to add some words on what the >> criteria are for not doing it. >> >> Thanks, >> Paul >> >> On 5/27/2011 12:28 PM, Elwell, John wrote: >>> I was quite happy with the refinements that Paul suggested, which I >>> hope help. Unfortunately I will not be available during the next couple >>> of weeks, so I will have to leave it to others to help arrive at >>> appropriate words. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>> Sent: 27 May 2011 16:39 >>>> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> Hi John, >>>> Your suggestion is >>>> >>>> The solution MUST include a mechanism that makes it >>>> possible for endpoints with different capabilities to >>>> interoperate in a telepresence conference, including >>>> audio/video endpoints that do not support any telepresence extensions. >>>> >>>> I have redone the requirements so that the reqmt for heterogeneous >>>> devices as in the use case, which was reqmt 10, is now more specific. >>>> So, we would not piggy back legacy on the hetereogeneity requirement. >>>> >>>> Assuming this now refers only to the interaction of CLUE and >>>> non-CLUE, >>>> the problem is that they don't interoperate in a telepresence >>>> sense- the >>>> purpose for the WG. >>>> >>>> Therefore, I would ask you to be more specific about the legacy >>>> requirement. I should think that the general meaning would be >>>> along the >>>> lines of that CLUE would not break any existing interworking - however >>>> this is general, and it would be good to make it more specific. >>>> >>>> I think it would be really helpful if you Paul and Roni, and others if >>>> they wish, could suggest some new text to more specifically cover what >>>> you have in mind which has been discussed in detail on the list. >>>> >>>> Thanks, >>>> Allyn >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Thursday, May 26, 2011 11:22 PM >>>> To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> Allyn, >>>> >>>> I already made a proposal: >>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>> Sent: 26 May 2011 20:08 >>>>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] legacy support in requirements >>>>> >>>>> Roni, Paul, John- >>>>> Would you care to suggest the wording you would like to see as a >>>>> requirement for legacy interoperability? That would be helpful. >>>>> >>>>> Thanks, >>>>> Allyn >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>> Of >>>>>> Roni Even >>>>>> Sent: Wednesday, May 18, 2011 11:13 AM >>>>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>> .... >>>>>> >>>>>> Anyhow we are discussing solution while my point is that we >>>>> will need >>>>>> as a >>>>>> requirement to address the case of a call from a CLUE >>>> aware endpoint >>>>> to >>>>>> a >>>>>> non CLUE aware endpoint. Even if the consensus will be to have the >>>>>> preferred >>>>>> video in the first video m-line. >>>>>> >>>>>> Regards >>>>>> Roni >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>>>> Sent: Wednesday, May 18, 2011 4:41 PM >>>>>>> To: Paul Kyzivat (pkyzivat); Roni Even >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: RE: [clue] legacy support in requirements >>>>>>> >>>>>>> Paul, >>>>>>> >>>>>>> I would agree that if the offer-answer model semantic >>>> is that here >>>>>> are >>>>>>> several options and any subset of options is acceptable. >>>>>>> >>>>>>> However, if there is any grouping involved such that you need to >>>>> have >>>>>> a >>>>>>> video and audio feed integrated to make sense then watch out. >>>>>>> >>>>>>> For example, I wouldn't want to end up with the result >>>> of a man's >>>>>> video >>>>>>> paired with a woman's voice. That could be rather comical. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>>> Of >>>>>>> Paul Kyzivat (pkyzivat) >>>>>>> Sent: Tuesday, May 17, 2011 7:45 PM >>>>>>> To: Roni Even >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>>>> Paul, >>>>>>>> I think we read it differently. >>>>>>>> If the answerer does not support the group attribute >>>>> and the offer >>>>>>> had >>>>>>> the >>>>>>>> fid semantics it may look to the answerer as an offer with >>>>> multiple >>>>>>> m-lines >>>>>>>> of the same media tyoe. In this case an implementation >>>>> might also >>>>>>> decide to >>>>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not >>>>>>> Acceptable), >>>>>>>> because it contains several "m" lines of the same media type. >>>>>>> >>>>>>> That is a slightly different story. >>>>>>> >>>>>>> Then the reason for rejection is not because it saw an >>>>> attribute it >>>>>>> didn't understand - its because it didn't like >>>> something it *did* >>>>>>> understand. >>>>>>> >>>>>>>> This is very relevant to the multiple streams case >>>> and we should >>>>>> look >>>>>>> if we >>>>>>>> state this behavior or we will look at providing an >>>>> approach that >>>>>>> will >>>>>>> allow >>>>>>>> the answerer to choose one m-line that the offerer >>>>> prefers even of >>>>>> it >>>>>>> does >>>>>>>> not understand CLUE. >>>>>>> >>>>>>> IMO (lets see if others differ), if a UA receives an >>>> offer with at >>>>>>> least >>>>>>> >>>>>>> one m-line it is happy with, then it should not reject the call >>>>>> because >>>>>>> there are others that it does not "understand". >>>>>>> >>>>>>> Here "understand" means something different - presumably it does >>>>>>> understand the direct meaning of the additional m-line, it just >>>>>> doesn't >>>>>>> understand the *significance* or use of it. >>>>>>> >>>>>>> I see little difference to getting to audio m-lines and >>>>> only wanting >>>>>>> one, and getting one audio and one video and only >>>>> supporting audio. >>>>>> In >>>>>>> general you should not reject an audio/video call just >>>> because you >>>>>> only >>>>>>> support audio. >>>>>>> >>>>>>> I think it will behoove clue to strongly recommend that >>>>> the m-lines >>>>>> in >>>>>>> an offer be arranged so the first ones are the ones it >>>> most wants >>>>>> used >>>>>>> if not all are. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Roni >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>>>>> To: Roni Even >>>>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>>>>> Paul, >>>>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>>> example >>>>>>>>>> Roni >>>>>>>>> >>>>>>>>> OK, I looked. It is consistent with what I said. >>>>>>>>> Either a=group: is understood, or not. If not, its >>>> ignored, and >>>>>> not >>>>>>> put >>>>>>>>> in the answer. Same with a=mid: >>>>>>>>> >>>>>>>>> If a=group: *is* understood, but some parameter within >>>>> it is not, >>>>>>> there >>>>>>>>> are explicit rules for what to do. >>>>>>>>> >>>>>>>>> AFAICT there are no examples in this document where >>>> failure to >>>>>>>>> understand an a-line in total (or even in part) results in >>>>>> rejecting >>>>>>>>> the >>>>>>>>> offer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On >>>>>>> Behalf >>>>>>>>> Of >>>>>>>>>>> Paul Kyzivat >>>>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>>>>>> To: Stephen Botzko >>>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>>>>>>>> >>>>>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>>>>>>>> >>>>>>>>>>>> When the offer includes parameters that >>>>> the answerer >>>>>>> does >>>>>>>>> not >>>>>>>>>>>> understand >>>>>>>>>>>> there are two options, he can ignore the unknown >>>>>>>>> parameters >>>>>>>>>>> or >>>>>>>>>>>> reject >>>>>>>>>>>> the offer. >>>>>>>>>>>> Rejecting the offer in that case is not >>>> really kosher. >>>>>>>>>>>> You are required to ignore parameters you do not >>>>>>> understand. >>>>>>>>>>>> >>>>>>>>>>>> If you reject something because you don't like the >>>>>>> parameters >>>>>>>>> it >>>>>>>>>>>> contains, then that is an implicit >>>> statement that you >>>>>>>>> understand >>>>>>>>>>>> those parameters well enough to decide to >>>> reject them. >>>>>>>>>>>> >>>>>>>>>>>> As far as I know, you are always free to reject >>>>> offers, and it >>>>>>>>>>> doesn't >>>>>>>>>>>> really imply anything when you do that.. Whether >>>> it is wise >>>>> is >>>>>>>>>>> perhaps >>>>>>>>>>>> a different question. >>>>>>>>>>>> Stephen Botzko >>>>>>>>>>> >>>>>>>>>>> Certainly you are always free to reject an offer. >>>>>>>>>>> In general I don't know for certain the reason why, >>>>> and so if I >>>>>>> give >>>>>>>>>>> you >>>>>>>>>>> the benefit of the doubt I will assume you have a >>>>> valid reason >>>>> - >>>>>>>>>>> perhaps >>>>>>>>>>> just policy. >>>>>>>>>>> >>>>>>>>>>> But if the reason you reject the offer is based on your >>>>>> violating >>>>>>> a >>>>>>>>>>> spec, then you are non-conforming, whether I can >>>>> determine you >>>>>> are >>>>>>>>>>> non-conforming or not. Whether being non-conforming is just >>>>>>> un-wise, >>>>>>>>> or >>>>>>>>>>> something stronger, is a separate discussion. The >>>>> IETF does not >>>>>>> levy >>>>>>>>>>> any >>>>>>>>>>> penalties for violating its specs. But sometimes the market >>>>>> does. >>>>>>>>> (And >>>>>>>>>>> sometimes not.) But we don't need to endorse non-conforming >>>>>>> behavior >>>>>>>>> in >>>>>>>>>>> our documents. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> clue mailing list >>>>>>>>>>> clue@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > From pkyzivat@cisco.com Fri May 27 10:42:57 2011 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 2FFEFE083D for ; Fri, 27 May 2011 10:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.344 X-Spam-Level: X-Spam-Status: No, score=-110.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HEGZsH2mkNFo for ; Fri, 27 May 2011 10:42:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C612E080F for ; Fri, 27 May 2011 10:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=19925; q=dns/txt; s=iport; t=1306518175; x=1307727775; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oxOKV4pviPEagZAp9WE+Pqw5nxieBu75QD60LVkDxTc=; b=gxoEVnh6s1cVXuM6t2n4QyyJd5v1YZgySl1JhSrtLoPKWnleaNnt1lql aeJxFflStZLYvh5OaLj19b6GE+YPglD0A6G3QyhoyJejyMp7QYM0dXUXW f22l1oLEITz3U+QfxQHHafAmCdqBrPk0VTEhlX4dy9C4NieaSsml7gqgx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAOTh302tJV2Z/2dsb2JhbAA3Hpdtjk53iHCgGJAljTGGHgSQQ4Q7hCeGTw X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="325064212" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 27 May 2011 17:42:54 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4RHgrKm017141; Fri, 27 May 2011 17:42:54 GMT Message-ID: <4DDFE29D.7010807@cisco.com> Date: Fri, 27 May 2011 13:42:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 17:42:57 -0000 Stephan, On 5/27/2011 1:31 PM, Stephan Wenger wrote: > Hi Paul, > The summation of the protocol work designed by CLUE is referred to as > "solution". A CLUE-less device is a device without the solution. > Therefore, I propose to replace "telepresence extensions" (which is > undefined, and could refer to telepresence extension not defined by CLUE) > with "solution". Thereafter, 10bis reads: > > REQMT-10bis: The solution MUST make it possible for endpoints without > support for the solution to participate in a telepresence > session with those that do. I appreciate what you are trying to accomplish, but I'm not too fond of the result. I think it would be unwise to formally define the term "solution" to have this meaning - its too general a word to co-opt. I would be ok with something like telepresence-solution. But whatever it is, it should then be added to the definitions. Thanks, Paul > On 5.27.2011 06:02 , "Paul Kyzivat" wrote: > >> >> >> On 5/27/2011 8:28 AM, Elwell, John wrote: >>> I can live with Steve's proposal. I also don't mind separating the >>> requirements, but I don't think we should refer to CLUE in the >>> requirement - the RFC will live a long time after CLUE is finished and >>> closed down. So if we want to separate the requirements, I would propose: >>> >>> REQMT-10: The solution MUST include a mechanism that makes it possible >>> for endpoints with different capabilities to interoperate in a >>> telepresence conference. >>> REQMT-10bis: The solution MUST include a mechanism that makes it >>> possible for endpoints without support for telepresence extensions to >>> participate in a telepresence conference with those that do. >> >> How about the following variant of that: >> >> REQMT-10bis: The solution MUST make it possible for endpoints without >> support for telepresence extensions to participate in a telepresence >> session with those that do. >> >> I dropped "mechanism" because its unlikely to be a new mechanism that >> makes this possible. (That would require changes to the legacy systems.) >> Rather it will need to be the manner of using existing mechanisms. >> >> And I changed "telepresence conference" to "telepresence session" >> because this ought to work point-point as well as for conferences. >> (But we probably need more definition work here, since neither >> telepresence-conference nor telepresence-session is currently defined.) >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>> Sent: 27 May 2011 12:23 >>>> To: Stephen Botzko; Elwell, John >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] legacy support in requirements >>>> >>>> I think it would be clearer to formulate two different requirements >>>> >>>> >>>> >>>> 1) Two solution must provide a mechanism that make it >>>> possible for endpoints with different capabilities to >>>> interoperate, e.g. interoperability between a 2 >>>> camera/screens and 3 camera/screens endpoint. >>>> >>>> 2) Two solution must provide a mechanism that make it >>>> possible for endpoints that are CLUE aware to interoperate >>>> with CLUE-less endpoints. >>>> >>>> >>>> >>>> Cheers >>>> >>>> >>>> >>>> -Espen >>>> >>>> >>>> >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Stephen Botzko >>>> Sent: 27. mai 2011 13:16 >>>> To: Elwell, John >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] legacy support in requirements >>>> >>>> >>>> >>>> I'm not sure that the language actually covers that (it seems >>>> ambiguous). >>>> >>>> What do you think about changing "endpoints with different >>>> capabilities" to "disparate devices"? >>>> >>>> Stephen >>>> >>>> >>>> >>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>> wrote: >>>> >>>> I thought requirement 10 would cover both >>>> (signalling/protocol capabilities as well as user interface >>>> capabilities). >>>> >>>> John >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>> >>>>> Sent: 27 May 2011 11:53 >>>>> To: Elwell, John >>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >>>>> (pkyzivat); clue@ietf.org >>>> >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> Do you think that the language in requirement 10 means "SIP >>>>> capabilities"? Or something else? >>>>> >>>>> I am thinking that issue is really about the >>>>> signaling/protocol design itself, and isn't directly related >>>>> to how many screens and cameras a system might have. >>>>> >>>>> Stephen Botzko >>>>> >>>>> >>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>> wrote: >>>>> >>>>> >>>>> Allyn, >>>>> >>>>> I already made a proposal: >>>>> >>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> > -----Original Message----- >>>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>> >>>>> > Sent: 26 May 2011 20:08 >>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>> > Cc: clue@ietf.org >>>>> > Subject: RE: [clue] legacy support in requirements >>>>> > >>>>> > Roni, Paul, John- >>>>> > Would you care to suggest the wording you would like >>>>> to see as a >>>>> > requirement for legacy interoperability? That would >>>>> be helpful. >>>>> > >>>>> > Thanks, >>>>> > Allyn >>>>> > >>>>> > > -----Original Message----- >>>>> > > From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>> > Of >>>>> > > Roni Even >>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>> > > Cc: clue@ietf.org >>>>> > > Subject: Re: [clue] legacy support in requirements >>>>> > > >>>>> > .... >>>>> > > >>>>> > > Anyhow we are discussing solution while my point >>>> is that we >>>>> > will need >>>>> > > as a >>>>> > > requirement to address the case of a call from a >>>>> CLUE aware endpoint >>>>> > to >>>>> > > a >>>>> > > non CLUE aware endpoint. Even if the consensus will >>>>> be to have the >>>>> > > preferred >>>>> > > video in the first video m-line. >>>>> > > >>>>> > > Regards >>>>> > > Roni >>>>> > > >>>>> > > >>>>> > > >>>>> > > > -----Original Message----- >>>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>> > > > Cc: clue@ietf.org >>>>> > > > Subject: RE: [clue] legacy support in requirements >>>>> > > > >>>>> > > > Paul, >>>>> > > > >>>>> > > > I would agree that if the offer-answer model >>>>> semantic is that here >>>>> > > are >>>>> > > > several options and any subset of options is >>>>> acceptable. >>>>> > > > >>>>> > > > However, if there is any grouping involved such >>>>> that you need to >>>>> > have >>>>> > > a >>>>> > > > video and audio feed integrated to make sense >>>>> then watch out. >>>>> > > > >>>>> > > > For example, I wouldn't want to end up with the >>>>> result of a man's >>>>> > > video >>>>> > > > paired with a woman's voice. That could be >>>>> rather comical. >>>>> > > > >>>>> > > > Mike >>>>> > > > >>>>> > > > >>>>> > > > -----Original Message----- >>>>> > > > From: clue-bounces@ietf.org >>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>> > > Of >>>>> > > > Paul Kyzivat (pkyzivat) >>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>> > > > To: Roni Even >>>>> > > > Cc: clue@ietf.org >>>>> > > > Subject: Re: [clue] legacy support in requirements >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>> > > > > Paul, >>>>> > > > > I think we read it differently. >>>>> > > > > If the answerer does not support the group >>>>> attribute >>>>> > and the offer >>>>> > > > had >>>>> > > > the >>>>> > > > > fid semantics it may look to the answerer as an >>>>> offer with >>>>> > multiple >>>>> > > > m-lines >>>>> > > > > of the same media tyoe. In this case an >>>>> implementation >>>>> > might also >>>>> > > > decide to >>>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>>> Here, or 606 Not >>>>> > > > Acceptable), >>>>> > > > > because it contains several "m" lines of the >>>>> same media type. >>>>> > > > >>>>> > > > That is a slightly different story. >>>>> > > > >>>>> > > > Then the reason for rejection is not because it saw an >>>>> > attribute it >>>>> > > > didn't understand - its because it didn't like >>>>> something it *did* >>>>> > > > understand. >>>>> > > > >>>>> > > > > This is very relevant to the multiple streams >>>>> case and we should >>>>> > > look >>>>> > > > if we >>>>> > > > > state this behavior or we will look at providing an >>>>> > approach that >>>>> > > > will >>>>> > > > allow >>>>> > > > > the answerer to choose one m-line that the offerer >>>>> > prefers even of >>>>> > > it >>>>> > > > does >>>>> > > > > not understand CLUE. >>>>> > > > >>>>> > > > IMO (lets see if others differ), if a UA receives >>>>> an offer with at >>>>> > > > least >>>>> > > > >>>>> > > > one m-line it is happy with, then it should not >>>>> reject the call >>>>> > > because >>>>> > > > there are others that it does not "understand". >>>>> > > > >>>>> > > > Here "understand" means something different - >>>>> presumably it does >>>>> > > > understand the direct meaning of the additional >>>>> m-line, it just >>>>> > > doesn't >>>>> > > > understand the *significance* or use of it. >>>>> > > > >>>>> > > > I see little difference to getting to audio m-lines >>>>> and >>>>> > only wanting >>>>> > > > one, and getting one audio and one video and only >>>>> > supporting audio. >>>>> > > In >>>>> > > > general you should not reject an audio/video call >>>>> just because you >>>>> > > only >>>>> > > > support audio. >>>>> > > > >>>>> > > > I think it will behoove clue to strongly recommend >>>>> that >>>>> > the m-lines >>>>> > > in >>>>> > > > an offer be arranged so the first ones are the >>>>> ones it most wants >>>>> > > used >>>>> > > > if not all are. >>>>> > > > >>>>> > > > Thanks, >>>>> > > > Paul >>>>> > > > >>>>> > > > > Roni >>>>> > > > > >>>>> > > > >> -----Original Message----- >>>>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>>> > > > >> To: Roni Even >>>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>>> > > > >> Subject: Re: [clue] legacy support in requirements >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> >>>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>> > > > >>> Paul, >>>>> > > > >>> Look at >>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>> > > > example >>>>> > > > >>> Roni >>>>> > > > >> >>>>> > > > >> OK, I looked. It is consistent with what I said. >>>>> > > > >> Either a=group: is understood, or not. If not, >>>>> its ignored, and >>>>> > > not >>>>> > > > put >>>>> > > > >> in the answer. Same with a=mid: >>>>> > > > >> >>>>> > > > >> If a=group: *is* understood, but some >>>> parameter within >>>>> > it is not, >>>>> > > > there >>>>> > > > >> are explicit rules for what to do. >>>>> > > > >> >>>>> > > > >> AFAICT there are no examples in this document >>>>> where failure to >>>>> > > > >> understand an a-line in total (or even in >>>>> part) results in >>>>> > > rejecting >>>>> > > > >> the >>>>> > > > >> offer. >>>>> > > > >> >>>>> > > > >> Thanks, >>>>> > > > >> Paul >>>>> > > > >> >>>>> > > > >>>> -----Original Message----- >>>>> > > > >>>> From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On >>>>> > > > Behalf >>>>> > > > >> Of >>>>> > > > >>>> Paul Kyzivat >>>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>> > > > >>>> To: Stephen Botzko >>>>> > > > >>>> Cc: clue@ietf.org >>>>> > > > >>>> Subject: Re: [clue] legacy support in >>>>> requirements >>>>> > > > >>>> >>>>> > > > >>>> >>>>> > > > >>>> >>>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: >>>>> > > > >>>> >>>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: >>>>> > > > >>>> >>>>> > > > >>>>> When the offer includes parameters >>>>> that >>>>> > the answerer >>>>> > > > does >>>>> > > > >> not >>>>> > > > >>>>> understand >>>>> > > > >>>>> there are two options, he can >>>>> ignore the unknown >>>>> > > > >> parameters >>>>> > > > >>>> or >>>>> > > > >>>>> reject >>>>> > > > >>>>> the offer. >>>>> > > > >>>>> Rejecting the offer in that case is >>>>> not really kosher. >>>>> > > > >>>>> You are required to ignore parameters >>>>> you do not >>>>> > > > understand. >>>>> > > > >>>>> >>>>> > > > >>>>> If you reject something because you >>>>> don't like the >>>>> > > > parameters >>>>> > > > >> it >>>>> > > > >>>>> contains, then that is an implicit >>>>> statement that you >>>>> > > > >> understand >>>>> > > > >>>>> those parameters well enough to >>>>> decide to reject them. >>>>> > > > >>>>> >>>>> > > > >>>>> As far as I know, you are always free to reject >>>>> > offers, and it >>>>> > > > >>>> doesn't >>>>> > > > >>>>> really imply anything when you do that.. >>>>> Whether it is wise >>>>> > is >>>>> > > > >>>> perhaps >>>>> > > > >>>>> a different question. >>>>> > > > >>>>> Stephen Botzko >>>>> > > > >>>> >>>>> > > > >>>> Certainly you are always free to reject an >>>>> offer. >>>>> > > > >>>> In general I don't know for certain the reason >>>>> why, >>>>> > and so if I >>>>> > > > give >>>>> > > > >>>> you >>>>> > > > >>>> the benefit of the doubt I will assume you have >>>>> a >>>>> > valid reason >>>>> > - >>>>> > > > >>>> perhaps >>>>> > > > >>>> just policy. >>>>> > > > >>>> >>>>> > > > >>>> But if the reason you reject the offer is >>>>> based on your >>>>> > > violating >>>>> > > > a >>>>> > > > >>>> spec, then you are non-conforming, whether I can >>>>> > determine you >>>>> > > are >>>>> > > > >>>> non-conforming or not. Whether being >>>>> non-conforming is just >>>>> > > > un-wise, >>>>> > > > >> or >>>>> > > > >>>> something stronger, is a separate discussion. >>>>> The >>>>> > IETF does not >>>>> > > > levy >>>>> > > > >>>> any >>>>> > > > >>>> penalties for violating its specs. But >>>>> sometimes the market >>>>> > > does. >>>>> > > > >> (And >>>>> > > > >>>> sometimes not.) But we don't need to endorse >>>>> non-conforming >>>>> > > > behavior >>>>> > > > >> in >>>>> > > > >>>> our documents. >>>>> > > > >>>> >>>>> > > > >>>> Thanks, >>>>> > > > >>>> Paul >>>>> > > > >>>> _______________________________________________ >>>>> > > > >>>> clue mailing list >>>>> > > > >>>> clue@ietf.org >>>>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue >>>>> > > > >>> >>>>> > > > >>> >>>>> > > > > >>>>> > > > > >>>>> > > > _______________________________________________ >>>>> > > > clue mailing list >>>>> > > > clue@ietf.org >>>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>>> > > >>>>> > > _______________________________________________ >>>>> > > clue mailing list >>>>> > > clue@ietf.org >>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>> > >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > From Even.roni@huawei.com Fri May 27 11:36:20 2011 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 403C3E0857 for ; Fri, 27 May 2011 11:36:20 -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 IF3RhN2jGWYg for ; Fri, 27 May 2011 11:36:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2B902E084C for ; Fri, 27 May 2011 11:36:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLV001HIACBIY@szxga05-in.huawei.com> for clue@ietf.org; Sat, 28 May 2011 02:36:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLV009HKACAJC@szxga05-in.huawei.com> for clue@ietf.org; Sat, 28 May 2011 02:36:11 +0800 (CST) Received: from windows8d787f9 ([109.65.42.220]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLV0032FABYH1@szxml12-in.huawei.com>; Sat, 28 May 2011 02:36:10 +0800 (CST) Date: Fri, 27 May 2011 21:33:57 +0300 From: Roni Even In-reply-to: To: 'Songhaibin' , 'Stephen Botzko' Message-id: <032201cc1c9c$ad642880$082c7980$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwQQsfyDe16b2f6TF+yrvF5QY9m8AALNxPQACR7JIAA1j2M4P//+Q+AgAAK9ICAAAo1gIAA8gyn//+BrICAABupgIAA6bSAgAA59ACAACsdgIAAQaoAgADuigCAAASkAIABMwAA//e7oGD/7v0yMP/dN4PA/7roOAD/dTTOEP7n3t5g iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <9ECCF01B52E7AB408A7EB8535264214102D6CBD2@ftrdmel0.rd.francetelecom.fr> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC046558F5@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <4DD3FD0E.8020503@cisco.com> <4DD4584E.30405@cisco.com> <4DD5244C.8090801@cisco.com> Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 18:36:20 -0000 Hi Haibin, We are not talking about the solution at the moment. The solution is probably a mixture protocol and implementation. If (and this is a = question) we do a new protocol or extension to a current protocol it should allow = EPs that support the protocol or extension to establish a media connection = with EPS who do not. Still it will be implmenation dependent if the "CLUE" = EPs will try to establish such a connection. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Songhaibin > Sent: Thursday, May 26, 2011 6:53 AM > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Hi Stephen, >=20 > I just would like to dig out that if there is much work to do from the > protocol perspective to make the CLUE "legacy friendly", or it can be > just an implementation issue. >=20 > I understand that the intent is important, and I also think that the > second path makes more sense:) >=20 > BR, > -Haibin >=20 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Thursday, May 26, 2011 10:22 AM > To: Songhaibin > Cc: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr); clue@ietf.org > Subject: Re: [clue] legacy support in requirements >=20 > Hi Haibin >=20 > Some ways of structuring the CLUE protocol might be very difficult for > existing endpoints to deal with.=A0 Other ways might be more "legacy > friendly", in the sense that the ability to negotiate a CLUEless call > between a CLUEd endpoint and a normal SIP endpoint would be > straightforward. >=20 > I think the intent of the requirement is to make sure the protocol > design takes the second path. >=20 > The challenge is that AFAIK there is are no guarantees in SIP itself > that assure any interoperability between the SIP endpoints.=A0 For > example, there is nothing in the SIP RFCs that mandate common codecs. > Since compliant SIP endpoints might not interoperate anyway, you can > not guarantee that a CLUE endpoint can interoperate with them either. > However, I think the intent is important, so we should try to craft > wording that captures it. >=20 > Regards, > Stephen Botzko >=20 >=20 > On Wed, May 25, 2011 at 9:50 PM, Songhaibin > wrote: > Hi John and Paul, >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, May 25, 2011 10:00 PM > > To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr) > > Cc: clue@ietf.org > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > -----Original Message----- > > > From: Songhaibin [mailto:haibin.song@huawei.com] > > > Sent: 25 May 2011 07:44 > > > To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr) > > > Cc: clue@ietf.org > > > Subject: RE: [clue] legacy support in requirements > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > > > On Behalf Of > > > > Elwell, John > > > > Sent: Friday, May 20, 2011 4:27 PM > > > > To: Paul Kyzivat; Mike Hammer (hmmr) > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > > Behalf Of Paul Kyzivat > > > > > Sent: 19 May 2011 15:08 > > > > > To: Mike Hammer (hmmr) > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] legacy support in requirements > > > > > > > > > > Mike, > > > > > > > > > > On 5/19/2011 9:51 AM, Mike Hammer (hmmr) wrote: > > > > > > Paul, > > > > > > > > > > > > What I am trying to say is that Telepresence is all about > > > > > the end-user > > > > > > experience, and that with multiple microphones, > > > speakers, cameras, > > > > > > displays, and data feeds there is more complexity and > > > > > chance to screw > > > > > > that up. =A0And a key point is that spatial relationships = are > > > > > significant > > > > > > to the user experience. =A0As a result, more rigor is needed > > > > > to design the > > > > > > system to ensure that backward compatible means that legacy > > > > > systems are > > > > > > handled as such. > > > > > > > > > > > > I am not sure if the protocol design is far enough > > > along to analyze > > > > > > whether correct protocol operation still results in bad > > > > > user experience, > > > > > > but would suggest that if certain key concepts like spatial > > > > > awareness > > > > > > are not understood, then that leg needs to devolve to a > > > known legacy > > > > > > state and handled by the MCU as such. =A0That might mean > > > tagging some > > > > > > parameters as mandatory to understand to force the > > > > > determination and not > > > > > > leave it ambiguous. > > > > > > > > > > > > I believe some current systems treat legacy systems > > > differently and > > > > > > don't expect them to behave like ones that understands > > > the dynamic > > > > > > speaker controls. > > > > > > > > > > I suspect we are talking past each other and are not really > > > > > in disagreement. > > > > > > > > > > I expect that the clue specs, whatever they turn out to be, > > > > > will require > > > > > support for a bunch of existing sip/sdp mechanisms that > > > are generally > > > > > optional and not widely implemented in lower end devices. > > > > > > > > > > If so, then if we have two clueful systems attempting to > > > connect, we > > > > > will be in the realm of negotiating using syntax that both > > > > > understand. > > > > > In that case, this discussion of how to behave when > > > something *isn't* > > > > > understood is moot. Rather that situation will arise when > > > we have a > > > > > clueful system attempting to connect to a clueless system, or > visa > > > > > versa. That is where my focus is in this discussion. > > > > [JRE] And furthermore, we might have a conference > > > comprising a number of > > > > CLUEful endpoints and a number of CLUEless endpoints. We > > > would ideally like > > > > to be in a position where the CLUEful endpoint users can > > > share a telepresence > > > > experience, and yet the CLUEless endpoint users can still > > > participate > > > > meaningfully in the conference. > > > > > > > > John > > > > > > > > > > I think this is out of the scope of CLUE WG. > > [JRE] I don't know why you say that. In fact it is covered in the = use > cases draft, > > section 4.5. > > > > John > IMHO, the interworking with the CLUEless endpoints may mostly rely on > the existing standard for video conference, which will not be re- > invented in this WG. The CLUEful endpoints/MCU(maybe not all of them) > need to understand the existing standard in order to connect. What = kind > of signaling or parameters MUST be communicated between the CLUEful > endpoints or between CLUEful endpoint and CLUEful MCU, for the > interworking with CLUEless endpoints? Can they also be done by the > internal implementation in MCU or the endpoint? >=20 >=20 > By the way, I am not an expert on telepresence, maybe the question > seems stupid. >=20 > Thanks, > -Haibin >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Fri May 27 11:39:07 2011 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 C7BF4E0740 for ; Fri, 27 May 2011 11:39:07 -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 y2csKu-zYYec for ; Fri, 27 May 2011 11:39:06 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D7E36E06BF for ; Fri, 27 May 2011 11:39:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLV00GQ3AH5GL@szxga05-in.huawei.com> for clue@ietf.org; Sat, 28 May 2011 02:39:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLV007NBAH487@szxga05-in.huawei.com> for clue@ietf.org; Sat, 28 May 2011 02:39:05 +0800 (CST) Received: from windows8d787f9 ([109.65.42.220]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLV0032GAGUIN@szxml11-in.huawei.com>; Sat, 28 May 2011 02:39:04 +0800 (CST) Date: Fri, 27 May 2011 21:36:58 +0300 From: Roni Even In-reply-to: <4DDFA0C8.1050509@cisco.com> To: 'Paul Kyzivat' , clue@ietf.org Message-id: <032301cc1c9d$144b1590$3ce140b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwcbrGw7RAG06uRTvWAqfAyhBQmuwALlXAQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04583C96@xmb-sjc-221.amer.cisco.com> <011f01cc145b$141f0b20$3c5d2160$%roni@huawei.com> <4DD27E5F.6070200@cisco.com> <4DD2901F.2000906@cisco.com> <01ae01cc14d8$52c845d0$f858d170$%roni@huawei.com> <4DD2EA8A.7070407@cisco.com> <01b501cc14de$9127c660$b3775320$%roni@huawei.com> <4DD30865.90103@cisco.com> <023601cc1587$4bba71a0$e32f54e0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC047B823C@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E6B2221@XMB-AMS-214.cisco.com> <4DDFA0C8.1050509@cisco.com> Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 18:39:07 -0000 Looks OK to me Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, May 27, 2011 4:02 PM > To: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/27/2011 8:28 AM, Elwell, John wrote: > > I can live with Steve's proposal. I also don't mind separating the > requirements, but I don't think we should refer to CLUE in the > requirement - the RFC will live a long time after CLUE is finished and > closed down. So if we want to separate the requirements, I would > propose: > > > > REQMT-10: The solution MUST include a mechanism that makes it > possible for endpoints with different capabilities to interoperate in a > telepresence conference. > > REQMT-10bis: The solution MUST include a mechanism that makes it > possible for endpoints without support for telepresence extensions to > participate in a telepresence conference with those that do. > > How about the following variant of that: > > REQMT-10bis: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a telepresence > session with those that do. > > I dropped "mechanism" because its unlikely to be a new mechanism that > makes this possible. (That would require changes to the legacy > systems.) > Rather it will need to be the manner of using existing mechanisms. > > And I changed "telepresence conference" to "telepresence session" > because this ought to work point-point as well as for conferences. > (But we probably need more definition work here, since neither > telepresence-conference nor telepresence-session is currently defined.) > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >> Sent: 27 May 2011 12:23 > >> To: Stephen Botzko; Elwell, John > >> Cc: clue@ietf.org > >> Subject: RE: [clue] legacy support in requirements > >> > >> I think it would be clearer to formulate two different requirements > >> > >> > >> > >> 1) Two solution must provide a mechanism that make it > >> possible for endpoints with different capabilities to > >> interoperate, e.g. interoperability between a 2 > >> camera/screens and 3 camera/screens endpoint. > >> > >> 2) Two solution must provide a mechanism that make it > >> possible for endpoints that are CLUE aware to interoperate > >> with CLUE-less endpoints. > >> > >> > >> > >> Cheers > >> > >> > >> > >> -Espen > >> > >> > >> > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf Of Stephen Botzko > >> Sent: 27. mai 2011 13:16 > >> To: Elwell, John > >> Cc: clue@ietf.org > >> Subject: Re: [clue] legacy support in requirements > >> > >> > >> > >> I'm not sure that the language actually covers that (it seems > >> ambiguous). > >> > >> What do you think about changing "endpoints with different > >> capabilities" to "disparate devices"? > >> > >> Stephen > >> > >> > >> > >> On Fri, May 27, 2011 at 7:03 AM, Elwell, John > >> wrote: > >> > >> I thought requirement 10 would cover both > >> (signalling/protocol capabilities as well as user interface > >> capabilities). > >> > >> John > >> > >> > >> > >>> -----Original Message----- > >>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > >> > >>> Sent: 27 May 2011 11:53 > >>> To: Elwell, John > >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > >>> (pkyzivat); clue@ietf.org > >> > >>> Subject: Re: [clue] legacy support in requirements > >>> > >>> Do you think that the language in requirement 10 means "SIP > >>> capabilities"? Or something else? > >>> > >>> I am thinking that issue is really about the > >>> signaling/protocol design itself, and isn't directly related > >>> to how many screens and cameras a system might have. > >>> > >>> Stephen Botzko > >>> > >>> > >>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John > >>> wrote: > >>> > >>> > >>> Allyn, > >>> > >>> I already made a proposal: > >>> > >> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >>> > >>> John > >>> > >>> > >>> > >>> > -----Original Message----- > >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>> > >>> > Sent: 26 May 2011 20:08 > >>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > >>> > Cc: clue@ietf.org > >>> > Subject: RE: [clue] legacy support in requirements > >>> > > >>> > Roni, Paul, John- > >>> > Would you care to suggest the wording you would like > >>> to see as a > >>> > requirement for legacy interoperability? That would > >>> be helpful. > >>> > > >>> > Thanks, > >>> > Allyn > >>> > > >>> > > -----Original Message----- > >>> > > From: clue-bounces@ietf.org > >>> [mailto:clue-bounces@ietf.org] On Behalf > >>> > Of > >>> > > Roni Even > >>> > > Sent: Wednesday, May 18, 2011 11:13 AM > >>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > >>> > > Cc: clue@ietf.org > >>> > > Subject: Re: [clue] legacy support in requirements > >>> > > > >>> > .... > >>> > > > >>> > > Anyhow we are discussing solution while my point > >> is that we > >>> > will need > >>> > > as a > >>> > > requirement to address the case of a call from a > >>> CLUE aware endpoint > >>> > to > >>> > > a > >>> > > non CLUE aware endpoint. Even if the consensus will > >>> be to have the > >>> > > preferred > >>> > > video in the first video m-line. > >>> > > > >>> > > Regards > >>> > > Roni > >>> > > > >>> > > > >>> > > > >>> > > > -----Original Message----- > >>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > >>> > > > Sent: Wednesday, May 18, 2011 4:41 PM > >>> > > > To: Paul Kyzivat (pkyzivat); Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: RE: [clue] legacy support in requirements > >>> > > > > >>> > > > Paul, > >>> > > > > >>> > > > I would agree that if the offer-answer model > >>> semantic is that here > >>> > > are > >>> > > > several options and any subset of options is > acceptable. > >>> > > > > >>> > > > However, if there is any grouping involved such > >>> that you need to > >>> > have > >>> > > a > >>> > > > video and audio feed integrated to make sense > >>> then watch out. > >>> > > > > >>> > > > For example, I wouldn't want to end up with the > >>> result of a man's > >>> > > video > >>> > > > paired with a woman's voice. That could be > >>> rather comical. > >>> > > > > >>> > > > Mike > >>> > > > > >>> > > > > >>> > > > -----Original Message----- > >>> > > > From: clue-bounces@ietf.org > >>> > [mailto:clue-bounces@ietf.org] On Behalf > >>> > > Of > >>> > > > Paul Kyzivat (pkyzivat) > >>> > > > Sent: Tuesday, May 17, 2011 7:45 PM > >>> > > > To: Roni Even > >>> > > > Cc: clue@ietf.org > >>> > > > Subject: Re: [clue] legacy support in requirements > >>> > > > > >>> > > > > >>> > > > > >>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >>> > > > > Paul, > >>> > > > > I think we read it differently. > >>> > > > > If the answerer does not support the group > attribute > >>> > and the offer > >>> > > > had > >>> > > > the > >>> > > > > fid semantics it may look to the answerer as an > >>> offer with > >>> > multiple > >>> > > > m-lines > >>> > > > > of the same media tyoe. In this case an > implementation > >>> > might also > >>> > > > decide to > >>> > > > > refuse the request (e.g., 488 Not Acceptable > >>> Here, or 606 Not > >>> > > > Acceptable), > >>> > > > > because it contains several "m" lines of the > >>> same media type. > >>> > > > > >>> > > > That is a slightly different story. > >>> > > > > >>> > > > Then the reason for rejection is not because it saw > an > >>> > attribute it > >>> > > > didn't understand - its because it didn't like > >>> something it *did* > >>> > > > understand. > >>> > > > > >>> > > > > This is very relevant to the multiple streams > >>> case and we should > >>> > > look > >>> > > > if we > >>> > > > > state this behavior or we will look at providing > an > >>> > approach that > >>> > > > will > >>> > > > allow > >>> > > > > the answerer to choose one m-line that the > offerer > >>> > prefers even of > >>> > > it > >>> > > > does > >>> > > > > not understand CLUE. > >>> > > > > >>> > > > IMO (lets see if others differ), if a UA receives > >>> an offer with at > >>> > > > least > >>> > > > > >>> > > > one m-line it is happy with, then it should not > >>> reject the call > >>> > > because > >>> > > > there are others that it does not "understand". > >>> > > > > >>> > > > Here "understand" means something different - > >>> presumably it does > >>> > > > understand the direct meaning of the additional > >>> m-line, it just > >>> > > doesn't > >>> > > > understand the *significance* or use of it. > >>> > > > > >>> > > > I see little difference to getting to audio m-lines > and > >>> > only wanting > >>> > > > one, and getting one audio and one video and only > >>> > supporting audio. > >>> > > In > >>> > > > general you should not reject an audio/video call > >>> just because you > >>> > > only > >>> > > > support audio. > >>> > > > > >>> > > > I think it will behoove clue to strongly recommend > that > >>> > the m-lines > >>> > > in > >>> > > > an offer be arranged so the first ones are the > >>> ones it most wants > >>> > > used > >>> > > > if not all are. > >>> > > > > >>> > > > Thanks, > >>> > > > Paul > >>> > > > > >>> > > > > Roni > >>> > > > > > >>> > > > >> -----Original Message----- > >>> > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM > >>> > > > >> To: Roni Even > >>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org > >>> > > > >> Subject: Re: [clue] legacy support in > requirements > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: > >>> > > > >>> Paul, > >>> > > > >>> Look at > >>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>> > > > example > >>> > > > >>> Roni > >>> > > > >> > >>> > > > >> OK, I looked. It is consistent with what I > said. > >>> > > > >> Either a=group: is understood, or not. If not, > >>> its ignored, and > >>> > > not > >>> > > > put > >>> > > > >> in the answer. Same with a=mid: > >>> > > > >> > >>> > > > >> If a=group: *is* understood, but some > >> parameter within > >>> > it is not, > >>> > > > there > >>> > > > >> are explicit rules for what to do. > >>> > > > >> > >>> > > > >> AFAICT there are no examples in this document > >>> where failure to > >>> > > > >> understand an a-line in total (or even in > >>> part) results in > >>> > > rejecting > >>> > > > >> the > >>> > > > >> offer. > >>> > > > >> > >>> > > > >> Thanks, > >>> > > > >> Paul > >>> > > > >> > >>> > > > >>>> -----Original Message----- > >>> > > > >>>> From: clue-bounces@ietf.org > >>> [mailto:clue-bounces@ietf.org] On > >>> > > > Behalf > >>> > > > >> Of > >>> > > > >>>> Paul Kyzivat > >>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>> > > > >>>> To: Stephen Botzko > >>> > > > >>>> Cc: clue@ietf.org > >>> > > > >>>> Subject: Re: [clue] legacy support in > requirements > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> > >>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>> > > > >>>> > >>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>> > > > >>>> > >>> > > > >>>>> When the offer includes parameters > that > >>> > the answerer > >>> > > > does > >>> > > > >> not > >>> > > > >>>>> understand > >>> > > > >>>>> there are two options, he can > >>> ignore the unknown > >>> > > > >> parameters > >>> > > > >>>> or > >>> > > > >>>>> reject > >>> > > > >>>>> the offer. > >>> > > > >>>>> Rejecting the offer in that case is > >>> not really kosher. > >>> > > > >>>>> You are required to ignore parameters > >>> you do not > >>> > > > understand. > >>> > > > >>>>> > >>> > > > >>>>> If you reject something because you > >>> don't like the > >>> > > > parameters > >>> > > > >> it > >>> > > > >>>>> contains, then that is an implicit > >>> statement that you > >>> > > > >> understand > >>> > > > >>>>> those parameters well enough to > >>> decide to reject them. > >>> > > > >>>>> > >>> > > > >>>>> As far as I know, you are always free to > reject > >>> > offers, and it > >>> > > > >>>> doesn't > >>> > > > >>>>> really imply anything when you do that.. > >>> Whether it is wise > >>> > is > >>> > > > >>>> perhaps > >>> > > > >>>>> a different question. > >>> > > > >>>>> Stephen Botzko > >>> > > > >>>> > >>> > > > >>>> Certainly you are always free to reject an > offer. > >>> > > > >>>> In general I don't know for certain the > reason why, > >>> > and so if I > >>> > > > give > >>> > > > >>>> you > >>> > > > >>>> the benefit of the doubt I will assume you > have a > >>> > valid reason > >>> > - > >>> > > > >>>> perhaps > >>> > > > >>>> just policy. > >>> > > > >>>> > >>> > > > >>>> But if the reason you reject the offer is > >>> based on your > >>> > > violating > >>> > > > a > >>> > > > >>>> spec, then you are non-conforming, whether I > can > >>> > determine you > >>> > > are > >>> > > > >>>> non-conforming or not. Whether being > >>> non-conforming is just > >>> > > > un-wise, > >>> > > > >> or > >>> > > > >>>> something stronger, is a separate discussion. > The > >>> > IETF does not > >>> > > > levy > >>> > > > >>>> any > >>> > > > >>>> penalties for violating its specs. But > >>> sometimes the market > >>> > > does. > >>> > > > >> (And > >>> > > > >>>> sometimes not.) But we don't need to endorse > >>> non-conforming > >>> > > > behavior > >>> > > > >> in > >>> > > > >>>> our documents. > >>> > > > >>>> > >>> > > > >>>> Thanks, > >>> > > > >>>> Paul > >>> > > > >>>> > _______________________________________________ > >>> > > > >>>> clue mailing list > >>> > > > >>>> clue@ietf.org > >>> > > > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > >>> > > > >>> > >>> > > > > > >>> > > > > > >>> > > > _______________________________________________ > >>> > > > clue mailing list > >>> > > > clue@ietf.org > >>> > > > https://www.ietf.org/mailman/listinfo/clue > >>> > > > >>> > > _______________________________________________ > >>> > > clue mailing list > >>> > > clue@ietf.org > >>> > > https://www.ietf.org/mailman/listinfo/clue > >>> > > >>> _______________________________________________ > >>> 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 stewe@stewe.org Fri May 27 13:07:50 2011 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 ABAD7E0711 for ; Fri, 27 May 2011 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 Z7+IBtvlpQP2 for ; Fri, 27 May 2011 13:07:49 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 51CFDE0718 for ; Fri, 27 May 2011 13:07:47 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 5654-1743317 for multiple; Fri, 27 May 2011 22:07:46 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 27 May 2011 13:07:38 -0700 From: Stephan Wenger To: Paul Kyzivat Message-ID: Thread-Topic: [clue] legacy support in requirements In-Reply-To: <4DDFE29D.7010807@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 20:07:50 -0000 Ok. How about: "Telepresence Extensions": The protocol extensions beyond non-telepresence SIP specified by the CLUE WG. (The protocol and architecture docs may wish to include something like "as defined herein") "Solution": Telepresence Extensions specification(s) and their implementation. Stephan On 5.27.2011 10:42 , "Paul Kyzivat" wrote: >Stephan, > >On 5/27/2011 1:31 PM, Stephan Wenger wrote: >> Hi Paul, >> The summation of the protocol work designed by CLUE is referred to as >> "solution". A CLUE-less device is a device without the solution. >> Therefore, I propose to replace "telepresence extensions" (which is >> undefined, and could refer to telepresence extension not defined by >>CLUE) >> with "solution". Thereafter, 10bis reads: >> >> REQMT-10bis: The solution MUST make it possible for endpoints without >> support for the solution to participate in a telepresence >> session with those that do. > >I appreciate what you are trying to accomplish, but I'm not too fond of >the result. I think it would be unwise to formally define the term >"solution" to have this meaning - its too general a word to co-opt. > >I would be ok with something like telepresence-solution. But whatever it >is, it should then be added to the definitions. > > Thanks, > Paul > >> On 5.27.2011 06:02 , "Paul Kyzivat" wrote: >> >>> >>> >>> On 5/27/2011 8:28 AM, Elwell, John wrote: >>>> I can live with Steve's proposal. I also don't mind separating the >>>> requirements, but I don't think we should refer to CLUE in the >>>> requirement - the RFC will live a long time after CLUE is finished and >>>> closed down. So if we want to separate the requirements, I would >>>>propose: >>>> >>>> REQMT-10: The solution MUST include a mechanism that makes it >>>>possible >>>> for endpoints with different capabilities to interoperate in a >>>> telepresence conference. >>>> REQMT-10bis: The solution MUST include a mechanism that makes it >>>> possible for endpoints without support for telepresence extensions to >>>> participate in a telepresence conference with those that do. >>> >>> How about the following variant of that: >>> >>> REQMT-10bis: The solution MUST make it possible for endpoints without >>> support for telepresence extensions to participate in a telepresence >>> session with those that do. >>> >>> I dropped "mechanism" because its unlikely to be a new mechanism that >>> makes this possible. (That would require changes to the legacy >>>systems.) >>> Rather it will need to be the manner of using existing mechanisms. >>> >>> And I changed "telepresence conference" to "telepresence session" >>> because this ought to work point-point as well as for conferences. >>> (But we probably need more definition work here, since neither >>> telepresence-conference nor telepresence-session is currently defined.) >>> >>> Thanks, >>> Paul >>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>>> Sent: 27 May 2011 12:23 >>>>> To: Stephen Botzko; Elwell, John >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] legacy support in requirements >>>>> >>>>> I think it would be clearer to formulate two different requirements >>>>> >>>>> >>>>> >>>>> 1) Two solution must provide a mechanism that make it >>>>> possible for endpoints with different capabilities to >>>>> interoperate, e.g. interoperability between a 2 >>>>> camera/screens and 3 camera/screens endpoint. >>>>> >>>>> 2) Two solution must provide a mechanism that make it >>>>> possible for endpoints that are CLUE aware to interoperate >>>>> with CLUE-less endpoints. >>>>> >>>>> >>>>> >>>>> Cheers >>>>> >>>>> >>>>> >>>>> -Espen >>>>> >>>>> >>>>> >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Stephen Botzko >>>>> Sent: 27. mai 2011 13:16 >>>>> To: Elwell, John >>>>> Cc: clue@ietf.org >>>>> Subject: Re: [clue] legacy support in requirements >>>>> >>>>> >>>>> >>>>> I'm not sure that the language actually covers that (it seems >>>>> ambiguous). >>>>> >>>>> What do you think about changing "endpoints with different >>>>> capabilities" to "disparate devices"? >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>>> wrote: >>>>> >>>>> I thought requirement 10 would cover both >>>>> (signalling/protocol capabilities as well as user interface >>>>> capabilities). >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>>> >>>>>> Sent: 27 May 2011 11:53 >>>>>> To: Elwell, John >>>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >>>>>> (pkyzivat); clue@ietf.org >>>>> >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> Do you think that the language in requirement 10 means "SIP >>>>>> capabilities"? Or something else? >>>>>> >>>>>> I am thinking that issue is really about the >>>>>> signaling/protocol design itself, and isn't directly related >>>>>> to how many screens and cameras a system might have. >>>>>> >>>>>> Stephen Botzko >>>>>> >>>>>> >>>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>>> wrote: >>>>>> >>>>>> >>>>>> Allyn, >>>>>> >>>>>> I already made a proposal: >>>>>> >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> > -----Original Message----- >>>>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>>> >>>>>> > Sent: 26 May 2011 20:08 >>>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>>> > Cc: clue@ietf.org >>>>>> > Subject: RE: [clue] legacy support in requirements >>>>>> > >>>>>> > Roni, Paul, John- >>>>>> > Would you care to suggest the wording you would like >>>>>> to see as a >>>>>> > requirement for legacy interoperability? That would >>>>>> be helpful. >>>>>> > >>>>>> > Thanks, >>>>>> > Allyn >>>>>> > >>>>>> > > -----Original Message----- >>>>>> > > From: clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>>> > Of >>>>>> > > Roni Even >>>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>>> > > Cc: clue@ietf.org >>>>>> > > Subject: Re: [clue] legacy support in requirements >>>>>> > > >>>>>> > .... >>>>>> > > >>>>>> > > Anyhow we are discussing solution while my point >>>>> is that we >>>>>> > will need >>>>>> > > as a >>>>>> > > requirement to address the case of a call from a >>>>>> CLUE aware endpoint >>>>>> > to >>>>>> > > a >>>>>> > > non CLUE aware endpoint. Even if the consensus will >>>>>> be to have the >>>>>> > > preferred >>>>>> > > video in the first video m-line. >>>>>> > > >>>>>> > > Regards >>>>>> > > Roni >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > > -----Original Message----- >>>>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>>> > > > Cc: clue@ietf.org >>>>>> > > > Subject: RE: [clue] legacy support in >>>>>>requirements >>>>>> > > > >>>>>> > > > Paul, >>>>>> > > > >>>>>> > > > I would agree that if the offer-answer model >>>>>> semantic is that here >>>>>> > > are >>>>>> > > > several options and any subset of options is >>>>>> acceptable. >>>>>> > > > >>>>>> > > > However, if there is any grouping involved such >>>>>> that you need to >>>>>> > have >>>>>> > > a >>>>>> > > > video and audio feed integrated to make sense >>>>>> then watch out. >>>>>> > > > >>>>>> > > > For example, I wouldn't want to end up with the >>>>>> result of a man's >>>>>> > > video >>>>>> > > > paired with a woman's voice. That could be >>>>>> rather comical. >>>>>> > > > >>>>>> > > > Mike >>>>>> > > > >>>>>> > > > >>>>>> > > > -----Original Message----- >>>>>> > > > From: clue-bounces@ietf.org >>>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>>> > > Of >>>>>> > > > Paul Kyzivat (pkyzivat) >>>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>>> > > > To: Roni Even >>>>>> > > > Cc: clue@ietf.org >>>>>> > > > Subject: Re: [clue] legacy support in >>>>>>requirements >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>> > > > > Paul, >>>>>> > > > > I think we read it differently. >>>>>> > > > > If the answerer does not support the group >>>>>> attribute >>>>>> > and the offer >>>>>> > > > had >>>>>> > > > the >>>>>> > > > > fid semantics it may look to the answerer >>>>>>as an >>>>>> offer with >>>>>> > multiple >>>>>> > > > m-lines >>>>>> > > > > of the same media tyoe. In this case an >>>>>> implementation >>>>>> > might also >>>>>> > > > decide to >>>>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>>>> Here, or 606 Not >>>>>> > > > Acceptable), >>>>>> > > > > because it contains several "m" lines of the >>>>>> same media type. >>>>>> > > > >>>>>> > > > That is a slightly different story. >>>>>> > > > >>>>>> > > > Then the reason for rejection is not because it >>>>>>saw an >>>>>> > attribute it >>>>>> > > > didn't understand - its because it didn't like >>>>>> something it *did* >>>>>> > > > understand. >>>>>> > > > >>>>>> > > > > This is very relevant to the multiple >>>>>>streams >>>>>> case and we should >>>>>> > > look >>>>>> > > > if we >>>>>> > > > > state this behavior or we will look at >>>>>>providing an >>>>>> > approach that >>>>>> > > > will >>>>>> > > > allow >>>>>> > > > > the answerer to choose one m-line that the >>>>>>offerer >>>>>> > prefers even of >>>>>> > > it >>>>>> > > > does >>>>>> > > > > not understand CLUE. >>>>>> > > > >>>>>> > > > IMO (lets see if others differ), if a UA >>>>>>receives >>>>>> an offer with at >>>>>> > > > least >>>>>> > > > >>>>>> > > > one m-line it is happy with, then it should not >>>>>> reject the call >>>>>> > > because >>>>>> > > > there are others that it does not "understand". >>>>>> > > > >>>>>> > > > Here "understand" means something different - >>>>>> presumably it does >>>>>> > > > understand the direct meaning of the additional >>>>>> m-line, it just >>>>>> > > doesn't >>>>>> > > > understand the *significance* or use of it. >>>>>> > > > >>>>>> > > > I see little difference to getting to audio >>>>>>m-lines >>>>>> and >>>>>> > only wanting >>>>>> > > > one, and getting one audio and one video and >>>>>>only >>>>>> > supporting audio. >>>>>> > > In >>>>>> > > > general you should not reject an audio/video >>>>>>call >>>>>> just because you >>>>>> > > only >>>>>> > > > support audio. >>>>>> > > > >>>>>> > > > I think it will behoove clue to strongly >>>>>>recommend >>>>>> that >>>>>> > the m-lines >>>>>> > > in >>>>>> > > > an offer be arranged so the first ones are the >>>>>> ones it most wants >>>>>> > > used >>>>>> > > > if not all are. >>>>>> > > > >>>>>> > > > Thanks, >>>>>> > > > Paul >>>>>> > > > >>>>>> > > > > Roni >>>>>> > > > > >>>>>> > > > >> -----Original Message----- >>>>>> > > > >> From: Paul Kyzivat >>>>>>[mailto:pkyzivat@cisco.com] >>>>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>> > > > >> To: Roni Even >>>>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>> > > > >> Subject: Re: [clue] legacy support in >>>>>>requirements >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> >>>>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>> > > > >>> Paul, >>>>>> > > > >>> Look at >>>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>> > > > example >>>>>> > > > >>> Roni >>>>>> > > > >> >>>>>> > > > >> OK, I looked. It is consistent with what I >>>>>>said. >>>>>> > > > >> Either a=group: is understood, or not. If >>>>>>not, >>>>>> its ignored, and >>>>>> > > not >>>>>> > > > put >>>>>> > > > >> in the answer. Same with a=mid: >>>>>> > > > >> >>>>>> > > > >> If a=group: *is* understood, but some >>>>> parameter within >>>>>> > it is not, >>>>>> > > > there >>>>>> > > > >> are explicit rules for what to do. >>>>>> > > > >> >>>>>> > > > >> AFAICT there are no examples in this >>>>>>document >>>>>> where failure to >>>>>> > > > >> understand an a-line in total (or even in >>>>>> part) results in >>>>>> > > rejecting >>>>>> > > > >> the >>>>>> > > > >> offer. >>>>>> > > > >> >>>>>> > > > >> Thanks, >>>>>> > > > >> Paul >>>>>> > > > >> >>>>>> > > > >>>> -----Original Message----- >>>>>> > > > >>>> From: clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] On >>>>>> > > > Behalf >>>>>> > > > >> Of >>>>>> > > > >>>> Paul Kyzivat >>>>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>> > > > >>>> To: Stephen Botzko >>>>>> > > > >>>> Cc: clue@ietf.org >>>>>> > > > >>>> Subject: Re: [clue] legacy support in >>>>>> requirements >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko >>>>>>wrote: >>>>>> > > > >>>> >>>>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even >>>>>>wrote: >>>>>> > > > >>>> >>>>>> > > > >>>>> When the offer includes >>>>>>parameters >>>>>> that >>>>>> > the answerer >>>>>> > > > does >>>>>> > > > >> not >>>>>> > > > >>>>> understand >>>>>> > > > >>>>> there are two options, he can >>>>>> ignore the unknown >>>>>> > > > >> parameters >>>>>> > > > >>>> or >>>>>> > > > >>>>> reject >>>>>> > > > >>>>> the offer. >>>>>> > > > >>>>> Rejecting the offer in that case >>>>>>is >>>>>> not really kosher. >>>>>> > > > >>>>> You are required to ignore >>>>>>parameters >>>>>> you do not >>>>>> > > > understand. >>>>>> > > > >>>>> >>>>>> > > > >>>>> If you reject something because >>>>>>you >>>>>> don't like the >>>>>> > > > parameters >>>>>> > > > >> it >>>>>> > > > >>>>> contains, then that is an implicit >>>>>> statement that you >>>>>> > > > >> understand >>>>>> > > > >>>>> those parameters well enough to >>>>>> decide to reject them. >>>>>> > > > >>>>> >>>>>> > > > >>>>> As far as I know, you are always free >>>>>>to reject >>>>>> > offers, and it >>>>>> > > > >>>> doesn't >>>>>> > > > >>>>> really imply anything when you do that.. >>>>>> Whether it is wise >>>>>> > is >>>>>> > > > >>>> perhaps >>>>>> > > > >>>>> a different question. >>>>>> > > > >>>>> Stephen Botzko >>>>>> > > > >>>> >>>>>> > > > >>>> Certainly you are always free to reject >>>>>>an >>>>>> offer. >>>>>> > > > >>>> In general I don't know for certain the >>>>>>reason >>>>>> why, >>>>>> > and so if I >>>>>> > > > give >>>>>> > > > >>>> you >>>>>> > > > >>>> the benefit of the doubt I will assume >>>>>>you have >>>>>> a >>>>>> > valid reason >>>>>> > - >>>>>> > > > >>>> perhaps >>>>>> > > > >>>> just policy. >>>>>> > > > >>>> >>>>>> > > > >>>> But if the reason you reject the offer is >>>>>> based on your >>>>>> > > violating >>>>>> > > > a >>>>>> > > > >>>> spec, then you are non-conforming, >>>>>>whether I can >>>>>> > determine you >>>>>> > > are >>>>>> > > > >>>> non-conforming or not. Whether being >>>>>> non-conforming is just >>>>>> > > > un-wise, >>>>>> > > > >> or >>>>>> > > > >>>> something stronger, is a separate >>>>>>discussion. >>>>>> The >>>>>> > IETF does not >>>>>> > > > levy >>>>>> > > > >>>> any >>>>>> > > > >>>> penalties for violating its specs. But >>>>>> sometimes the market >>>>>> > > does. >>>>>> > > > >> (And >>>>>> > > > >>>> sometimes not.) But we don't need to >>>>>>endorse >>>>>> non-conforming >>>>>> > > > behavior >>>>>> > > > >> in >>>>>> > > > >>>> our documents. >>>>>> > > > >>>> >>>>>> > > > >>>> Thanks, >>>>>> > > > >>>> Paul >>>>>> > > > >>>> >>>>>>_______________________________________________ >>>>>> > > > >>>> clue mailing list >>>>>> > > > >>>> clue@ietf.org >>>>>> > > > >>>> >>>>>>https://www.ietf.org/mailman/listinfo/clue >>>>>> > > > >>> >>>>>> > > > >>> >>>>>> > > > > >>>>>> > > > > >>>>>> > > > _______________________________________________ >>>>>> > > > clue mailing list >>>>>> > > > clue@ietf.org >>>>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>>>> > > >>>>>> > > _______________________________________________ >>>>>> > > clue mailing list >>>>>> > > clue@ietf.org >>>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>>> > >>>>>> _______________________________________________ >>>>>> 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@cisco.com Fri May 27 13:23:29 2011 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 541C0E06A8 for ; Fri, 27 May 2011 13:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.35 X-Spam-Level: X-Spam-Status: No, score=-110.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 6K0qR-ZYqFnw for ; Fri, 27 May 2011 13:23:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 32B5BE0700 for ; Fri, 27 May 2011 13:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=23044; q=dns/txt; s=iport; t=1306527807; x=1307737407; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0wVIYRJ8b9+vx08fOgF3lKsPCgwdEWTGhCB5+a78zQI=; b=Rm4o7a4Dc+aOhyIXO2346wvU2KNqRdrzuyOQ9SWWMsB7Zz7oys9DHrkI q7X5HoRHzH+uvMdJYP9VTqIhne/H3XoYVRQE04GAxjsa8iOChpTGvIJ50 Wa2wZXrzoMN2W/lW5X5b66/DObhQEXAyiBbZ5oZLAGd3ux3Qc5VqoD8tt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAM0H4E2rRDoI/2dsb2JhbAA3Hpdwjk53iHChFJAljRyGHgSQQ4Q7hCeGTw X-IronPort-AV: E=Sophos;i="4.65,282,1304294400"; d="scan'208";a="365749081" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 20:23:23 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4RKNMai029832; Fri, 27 May 2011 20:23:22 GMT Message-ID: <4DE0083A.3040102@cisco.com> Date: Fri, 27 May 2011 16:23:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] legacy support in requirements 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, 27 May 2011 20:23:29 -0000 On 5/27/2011 4:07 PM, Stephan Wenger wrote: > Ok. > > How about: > > "Telepresence Extensions": The protocol extensions beyond non-telepresence > SIP specified by the CLUE WG. (The protocol and architecture docs may > wish to include something like "as defined herein") I like that! > "Solution": Telepresence Extensions specification(s) and their > implementation. I would still hate to see such a narrow definition of that word in any broad context. It would be way too confusing. I think it would be ok in a narrow context - say a paragraph, or a section of a document. Thanks, Paul > Stephan > > > On 5.27.2011 10:42 , "Paul Kyzivat" wrote: > >> Stephan, >> >> On 5/27/2011 1:31 PM, Stephan Wenger wrote: >>> Hi Paul, >>> The summation of the protocol work designed by CLUE is referred to as >>> "solution". A CLUE-less device is a device without the solution. >>> Therefore, I propose to replace "telepresence extensions" (which is >>> undefined, and could refer to telepresence extension not defined by >>> CLUE) >>> with "solution". Thereafter, 10bis reads: >>> >>> REQMT-10bis: The solution MUST make it possible for endpoints without >>> support for the solution to participate in a telepresence >>> session with those that do. >> >> I appreciate what you are trying to accomplish, but I'm not too fond of >> the result. I think it would be unwise to formally define the term >> "solution" to have this meaning - its too general a word to co-opt. >> >> I would be ok with something like telepresence-solution. But whatever it >> is, it should then be added to the definitions. >> >> Thanks, >> Paul >> >>> On 5.27.2011 06:02 , "Paul Kyzivat" wrote: >>> >>>> >>>> >>>> On 5/27/2011 8:28 AM, Elwell, John wrote: >>>>> I can live with Steve's proposal. I also don't mind separating the >>>>> requirements, but I don't think we should refer to CLUE in the >>>>> requirement - the RFC will live a long time after CLUE is finished and >>>>> closed down. So if we want to separate the requirements, I would >>>>> propose: >>>>> >>>>> REQMT-10: The solution MUST include a mechanism that makes it >>>>> possible >>>>> for endpoints with different capabilities to interoperate in a >>>>> telepresence conference. >>>>> REQMT-10bis: The solution MUST include a mechanism that makes it >>>>> possible for endpoints without support for telepresence extensions to >>>>> participate in a telepresence conference with those that do. >>>> >>>> How about the following variant of that: >>>> >>>> REQMT-10bis: The solution MUST make it possible for endpoints without >>>> support for telepresence extensions to participate in a telepresence >>>> session with those that do. >>>> >>>> I dropped "mechanism" because its unlikely to be a new mechanism that >>>> makes this possible. (That would require changes to the legacy >>>> systems.) >>>> Rather it will need to be the manner of using existing mechanisms. >>>> >>>> And I changed "telepresence conference" to "telepresence session" >>>> because this ought to work point-point as well as for conferences. >>>> (But we probably need more definition work here, since neither >>>> telepresence-conference nor telepresence-session is currently defined.) >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>>>> Sent: 27 May 2011 12:23 >>>>>> To: Stephen Botzko; Elwell, John >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] legacy support in requirements >>>>>> >>>>>> I think it would be clearer to formulate two different requirements >>>>>> >>>>>> >>>>>> >>>>>> 1) Two solution must provide a mechanism that make it >>>>>> possible for endpoints with different capabilities to >>>>>> interoperate, e.g. interoperability between a 2 >>>>>> camera/screens and 3 camera/screens endpoint. >>>>>> >>>>>> 2) Two solution must provide a mechanism that make it >>>>>> possible for endpoints that are CLUE aware to interoperate >>>>>> with CLUE-less endpoints. >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> >>>>>> -Espen >>>>>> >>>>>> >>>>>> >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Stephen Botzko >>>>>> Sent: 27. mai 2011 13:16 >>>>>> To: Elwell, John >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] legacy support in requirements >>>>>> >>>>>> >>>>>> >>>>>> I'm not sure that the language actually covers that (it seems >>>>>> ambiguous). >>>>>> >>>>>> What do you think about changing "endpoints with different >>>>>> capabilities" to "disparate devices"? >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> >>>>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>>>> wrote: >>>>>> >>>>>> I thought requirement 10 would cover both >>>>>> (signalling/protocol capabilities as well as user interface >>>>>> capabilities). >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>>>> >>>>>>> Sent: 27 May 2011 11:53 >>>>>>> To: Elwell, John >>>>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >>>>>>> (pkyzivat); clue@ietf.org >>>>>> >>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>> >>>>>>> Do you think that the language in requirement 10 means "SIP >>>>>>> capabilities"? Or something else? >>>>>>> >>>>>>> I am thinking that issue is really about the >>>>>>> signaling/protocol design itself, and isn't directly related >>>>>>> to how many screens and cameras a system might have. >>>>>>> >>>>>>> Stephen Botzko >>>>>>> >>>>>>> >>>>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Allyn, >>>>>>> >>>>>>> I already made a proposal: >>>>>>> >>>>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> > -----Original Message----- >>>>>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>>>>> >>>>>>> > Sent: 26 May 2011 20:08 >>>>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John >>>>>>> > Cc: clue@ietf.org >>>>>>> > Subject: RE: [clue] legacy support in requirements >>>>>>> > >>>>>>> > Roni, Paul, John- >>>>>>> > Would you care to suggest the wording you would like >>>>>>> to see as a >>>>>>> > requirement for legacy interoperability? That would >>>>>>> be helpful. >>>>>>> > >>>>>>> > Thanks, >>>>>>> > Allyn >>>>>>> > >>>>>>> > > -----Original Message----- >>>>>>> > > From: clue-bounces@ietf.org >>>>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>>>> > Of >>>>>>> > > Roni Even >>>>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>>>> > > To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) >>>>>>> > > Cc: clue@ietf.org >>>>>>> > > Subject: Re: [clue] legacy support in requirements >>>>>>> > > >>>>>>> > .... >>>>>>> > > >>>>>>> > > Anyhow we are discussing solution while my point >>>>>> is that we >>>>>>> > will need >>>>>>> > > as a >>>>>>> > > requirement to address the case of a call from a >>>>>>> CLUE aware endpoint >>>>>>> > to >>>>>>> > > a >>>>>>> > > non CLUE aware endpoint. Even if the consensus will >>>>>>> be to have the >>>>>>> > > preferred >>>>>>> > > video in the first video m-line. >>>>>>> > > >>>>>>> > > Regards >>>>>>> > > Roni >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > > -----Original Message----- >>>>>>> > > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] >>>>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>>>> > > > Cc: clue@ietf.org >>>>>>> > > > Subject: RE: [clue] legacy support in >>>>>>> requirements >>>>>>> > > > >>>>>>> > > > Paul, >>>>>>> > > > >>>>>>> > > > I would agree that if the offer-answer model >>>>>>> semantic is that here >>>>>>> > > are >>>>>>> > > > several options and any subset of options is >>>>>>> acceptable. >>>>>>> > > > >>>>>>> > > > However, if there is any grouping involved such >>>>>>> that you need to >>>>>>> > have >>>>>>> > > a >>>>>>> > > > video and audio feed integrated to make sense >>>>>>> then watch out. >>>>>>> > > > >>>>>>> > > > For example, I wouldn't want to end up with the >>>>>>> result of a man's >>>>>>> > > video >>>>>>> > > > paired with a woman's voice. That could be >>>>>>> rather comical. >>>>>>> > > > >>>>>>> > > > Mike >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > -----Original Message----- >>>>>>> > > > From: clue-bounces@ietf.org >>>>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>>>> > > Of >>>>>>> > > > Paul Kyzivat (pkyzivat) >>>>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>>>> > > > To: Roni Even >>>>>>> > > > Cc: clue@ietf.org >>>>>>> > > > Subject: Re: [clue] legacy support in >>>>>>> requirements >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>>> > > > > Paul, >>>>>>> > > > > I think we read it differently. >>>>>>> > > > > If the answerer does not support the group >>>>>>> attribute >>>>>>> > and the offer >>>>>>> > > > had >>>>>>> > > > the >>>>>>> > > > > fid semantics it may look to the answerer >>>>>>> as an >>>>>>> offer with >>>>>>> > multiple >>>>>>> > > > m-lines >>>>>>> > > > > of the same media tyoe. In this case an >>>>>>> implementation >>>>>>> > might also >>>>>>> > > > decide to >>>>>>> > > > > refuse the request (e.g., 488 Not Acceptable >>>>>>> Here, or 606 Not >>>>>>> > > > Acceptable), >>>>>>> > > > > because it contains several "m" lines of the >>>>>>> same media type. >>>>>>> > > > >>>>>>> > > > That is a slightly different story. >>>>>>> > > > >>>>>>> > > > Then the reason for rejection is not because it >>>>>>> saw an >>>>>>> > attribute it >>>>>>> > > > didn't understand - its because it didn't like >>>>>>> something it *did* >>>>>>> > > > understand. >>>>>>> > > > >>>>>>> > > > > This is very relevant to the multiple >>>>>>> streams >>>>>>> case and we should >>>>>>> > > look >>>>>>> > > > if we >>>>>>> > > > > state this behavior or we will look at >>>>>>> providing an >>>>>>> > approach that >>>>>>> > > > will >>>>>>> > > > allow >>>>>>> > > > > the answerer to choose one m-line that the >>>>>>> offerer >>>>>>> > prefers even of >>>>>>> > > it >>>>>>> > > > does >>>>>>> > > > > not understand CLUE. >>>>>>> > > > >>>>>>> > > > IMO (lets see if others differ), if a UA >>>>>>> receives >>>>>>> an offer with at >>>>>>> > > > least >>>>>>> > > > >>>>>>> > > > one m-line it is happy with, then it should not >>>>>>> reject the call >>>>>>> > > because >>>>>>> > > > there are others that it does not "understand". >>>>>>> > > > >>>>>>> > > > Here "understand" means something different - >>>>>>> presumably it does >>>>>>> > > > understand the direct meaning of the additional >>>>>>> m-line, it just >>>>>>> > > doesn't >>>>>>> > > > understand the *significance* or use of it. >>>>>>> > > > >>>>>>> > > > I see little difference to getting to audio >>>>>>> m-lines >>>>>>> and >>>>>>> > only wanting >>>>>>> > > > one, and getting one audio and one video and >>>>>>> only >>>>>>> > supporting audio. >>>>>>> > > In >>>>>>> > > > general you should not reject an audio/video >>>>>>> call >>>>>>> just because you >>>>>>> > > only >>>>>>> > > > support audio. >>>>>>> > > > >>>>>>> > > > I think it will behoove clue to strongly >>>>>>> recommend >>>>>>> that >>>>>>> > the m-lines >>>>>>> > > in >>>>>>> > > > an offer be arranged so the first ones are the >>>>>>> ones it most wants >>>>>>> > > used >>>>>>> > > > if not all are. >>>>>>> > > > >>>>>>> > > > Thanks, >>>>>>> > > > Paul >>>>>>> > > > >>>>>>> > > > > Roni >>>>>>> > > > > >>>>>>> > > > >> -----Original Message----- >>>>>>> > > > >> From: Paul Kyzivat >>>>>>> [mailto:pkyzivat@cisco.com] >>>>>>> > > > >> Sent: Wednesday, May 18, 2011 12:37 AM >>>>>>> > > > >> To: Roni Even >>>>>>> > > > >> Cc: 'Stephen Botzko'; clue@ietf.org >>>>>>> > > > >> Subject: Re: [clue] legacy support in >>>>>>> requirements >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>> > > > >> >>>>>>> > > > >> On 5/17/2011 5:20 PM, Roni Even wrote: >>>>>>> > > > >>> Paul, >>>>>>> > > > >>> Look at >>>>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>>> > > > example >>>>>>> > > > >>> Roni >>>>>>> > > > >> >>>>>>> > > > >> OK, I looked. It is consistent with what I >>>>>>> said. >>>>>>> > > > >> Either a=group: is understood, or not. If >>>>>>> not, >>>>>>> its ignored, and >>>>>>> > > not >>>>>>> > > > put >>>>>>> > > > >> in the answer. Same with a=mid: >>>>>>> > > > >> >>>>>>> > > > >> If a=group: *is* understood, but some >>>>>> parameter within >>>>>>> > it is not, >>>>>>> > > > there >>>>>>> > > > >> are explicit rules for what to do. >>>>>>> > > > >> >>>>>>> > > > >> AFAICT there are no examples in this >>>>>>> document >>>>>>> where failure to >>>>>>> > > > >> understand an a-line in total (or even in >>>>>>> part) results in >>>>>>> > > rejecting >>>>>>> > > > >> the >>>>>>> > > > >> offer. >>>>>>> > > > >> >>>>>>> > > > >> Thanks, >>>>>>> > > > >> Paul >>>>>>> > > > >> >>>>>>> > > > >>>> -----Original Message----- >>>>>>> > > > >>>> From: clue-bounces@ietf.org >>>>>>> [mailto:clue-bounces@ietf.org] On >>>>>>> > > > Behalf >>>>>>> > > > >> Of >>>>>>> > > > >>>> Paul Kyzivat >>>>>>> > > > >>>> Sent: Tuesday, May 17, 2011 6:11 PM >>>>>>> > > > >>>> To: Stephen Botzko >>>>>>> > > > >>>> Cc: clue@ietf.org >>>>>>> > > > >>>> Subject: Re: [clue] legacy support in >>>>>>> requirements >>>>>>> > > > >>>> >>>>>>> > > > >>>> >>>>>>> > > > >>>> >>>>>>> > > > >>>> On 5/17/2011 10:34 AM, Stephen Botzko >>>>>>> wrote: >>>>>>> > > > >>>> >>>>>>> > > > >>>>> On 5/17/2011 2:24 AM, Roni Even >>>>>>> wrote: >>>>>>> > > > >>>> >>>>>>> > > > >>>>> When the offer includes >>>>>>> parameters >>>>>>> that >>>>>>> > the answerer >>>>>>> > > > does >>>>>>> > > > >> not >>>>>>> > > > >>>>> understand >>>>>>> > > > >>>>> there are two options, he can >>>>>>> ignore the unknown >>>>>>> > > > >> parameters >>>>>>> > > > >>>> or >>>>>>> > > > >>>>> reject >>>>>>> > > > >>>>> the offer. >>>>>>> > > > >>>>> Rejecting the offer in that case >>>>>>> is >>>>>>> not really kosher. >>>>>>> > > > >>>>> You are required to ignore >>>>>>> parameters >>>>>>> you do not >>>>>>> > > > understand. >>>>>>> > > > >>>>> >>>>>>> > > > >>>>> If you reject something because >>>>>>> you >>>>>>> don't like the >>>>>>> > > > parameters >>>>>>> > > > >> it >>>>>>> > > > >>>>> contains, then that is an implicit >>>>>>> statement that you >>>>>>> > > > >> understand >>>>>>> > > > >>>>> those parameters well enough to >>>>>>> decide to reject them. >>>>>>> > > > >>>>> >>>>>>> > > > >>>>> As far as I know, you are always free >>>>>>> to reject >>>>>>> > offers, and it >>>>>>> > > > >>>> doesn't >>>>>>> > > > >>>>> really imply anything when you do that.. >>>>>>> Whether it is wise >>>>>>> > is >>>>>>> > > > >>>> perhaps >>>>>>> > > > >>>>> a different question. >>>>>>> > > > >>>>> Stephen Botzko >>>>>>> > > > >>>> >>>>>>> > > > >>>> Certainly you are always free to reject >>>>>>> an >>>>>>> offer. >>>>>>> > > > >>>> In general I don't know for certain the >>>>>>> reason >>>>>>> why, >>>>>>> > and so if I >>>>>>> > > > give >>>>>>> > > > >>>> you >>>>>>> > > > >>>> the benefit of the doubt I will assume >>>>>>> you have >>>>>>> a >>>>>>> > valid reason >>>>>>> > - >>>>>>> > > > >>>> perhaps >>>>>>> > > > >>>> just policy. >>>>>>> > > > >>>> >>>>>>> > > > >>>> But if the reason you reject the offer is >>>>>>> based on your >>>>>>> > > violating >>>>>>> > > > a >>>>>>> > > > >>>> spec, then you are non-conforming, >>>>>>> whether I can >>>>>>> > determine you >>>>>>> > > are >>>>>>> > > > >>>> non-conforming or not. Whether being >>>>>>> non-conforming is just >>>>>>> > > > un-wise, >>>>>>> > > > >> or >>>>>>> > > > >>>> something stronger, is a separate >>>>>>> discussion. >>>>>>> The >>>>>>> > IETF does not >>>>>>> > > > levy >>>>>>> > > > >>>> any >>>>>>> > > > >>>> penalties for violating its specs. But >>>>>>> sometimes the market >>>>>>> > > does. >>>>>>> > > > >> (And >>>>>>> > > > >>>> sometimes not.) But we don't need to >>>>>>> endorse >>>>>>> non-conforming >>>>>>> > > > behavior >>>>>>> > > > >> in >>>>>>> > > > >>>> our documents. >>>>>>> > > > >>>> >>>>>>> > > > >>>> Thanks, >>>>>>> > > > >>>> Paul >>>>>>> > > > >>>> >>>>>>> _______________________________________________ >>>>>>> > > > >>>> clue mailing list >>>>>>> > > > >>>> clue@ietf.org >>>>>>> > > > >>>> >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > clue mailing list >>>>>>> > > > clue@ietf.org >>>>>>> > > > https://www.ietf.org/mailman/listinfo/clue >>>>>>> > > >>>>>>> > > _______________________________________________ >>>>>>> > > clue mailing list >>>>>>> > > clue@ietf.org >>>>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>>>> > >>>>>>> _______________________________________________ >>>>>>> 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 Sun May 29 23:08:18 2011 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 7DB8CE071D for ; Sun, 29 May 2011 23:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, 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 fnUC0T+2ExzX for ; Sun, 29 May 2011 23:08:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 549D5E06E4 for ; Sun, 29 May 2011 23:08:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7d-4de3344e68ab Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 01.E9.09774.E4433ED4; Mon, 30 May 2011 08:08:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 30 May 2011 08:08:13 +0200 From: Christer Holmberg To: Paul Kyzivat , Stephan Wenger Date: Mon, 30 May 2011 08:08:12 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: Acwcq/NWfszCUakSRDCA3tNjz+2cpwB48Erw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> References: <4DE0083A.3040102@cisco.com> In-Reply-To: <4DE0083A.3040102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 30 May 2011 06:08:18 -0000 Hi, The text looks good, but could we replace "by the CLUE WG" with "by RFC XXX= X", and at some point we/IANA will replace XXXX with a number. Because, I assume the definition is going to live after the WG? Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 27. toukokuuta 2011 23:23 > To: Stephan Wenger > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/27/2011 4:07 PM, Stephan Wenger wrote: > > Ok. > > > > How about: > > > > "Telepresence Extensions": The protocol extensions beyond > > non-telepresence SIP specified by the CLUE WG. (The protocol and > > architecture docs may wish to include something like "as defined > > herein") > > I like that! > > > "Solution": Telepresence Extensions specification(s) and their > > implementation. > > I would still hate to see such a narrow definition of that > word in any broad context. It would be way too confusing. > > I think it would be ok in a narrow context - say a paragraph, > or a section of a document. > > Thanks, > Paul > > > Stephan > > > > > > On 5.27.2011 10:42 , "Paul Kyzivat" wrote: > > > >> Stephan, > >> > >> On 5/27/2011 1:31 PM, Stephan Wenger wrote: > >>> Hi Paul, > >>> The summation of the protocol work designed by CLUE is > referred to > >>> as "solution". A CLUE-less device is a device without > the solution. > >>> Therefore, I propose to replace "telepresence extensions" > (which is > >>> undefined, and could refer to telepresence extension not > defined by > >>> CLUE) > >>> with "solution". Thereafter, 10bis reads: > >>> > >>> REQMT-10bis: The solution MUST make it possible for endpoints > >>> without support for the solution to participate in a telepresence > >>> session with those that do. > >> > >> I appreciate what you are trying to accomplish, but I'm > not too fond > >> of the result. I think it would be unwise to formally > define the term > >> "solution" to have this meaning - its too general a word to co-opt. > >> > >> I would be ok with something like telepresence-solution. > But whatever > >> it is, it should then be added to the definitions. > >> > >> Thanks, > >> Paul > >> > >>> On 5.27.2011 06:02 , "Paul Kyzivat" wrote: > >>> > >>>> > >>>> > >>>> On 5/27/2011 8:28 AM, Elwell, John wrote: > >>>>> I can live with Steve's proposal. I also don't mind > separating the > >>>>> requirements, but I don't think we should refer to CLUE in the > >>>>> requirement - the RFC will live a long time after CLUE > is finished > >>>>> and closed down. So if we want to separate the requirements, I > >>>>> would > >>>>> propose: > >>>>> > >>>>> REQMT-10: The solution MUST include a mechanism that makes it > >>>>> possible for endpoints with different capabilities to > interoperate > >>>>> in a telepresence conference. > >>>>> REQMT-10bis: The solution MUST include a mechanism > that makes it > >>>>> possible for endpoints without support for telepresence > extensions > >>>>> to participate in a telepresence conference with those that do. > >>>> > >>>> How about the following variant of that: > >>>> > >>>> REQMT-10bis: The solution MUST make it possible for endpoints > >>>> without support for telepresence extensions to participate in a > >>>> telepresence session with those that do. > >>>> > >>>> I dropped "mechanism" because its unlikely to be a new mechanism > >>>> that makes this possible. (That would require changes to > the legacy > >>>> systems.) > >>>> Rather it will need to be the manner of using existing > mechanisms. > >>>> > >>>> And I changed "telepresence conference" to "telepresence session" > >>>> because this ought to work point-point as well as for > conferences. > >>>> (But we probably need more definition work here, since neither > >>>> telepresence-conference nor telepresence-session is currently > >>>> defined.) > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >>>>>> Sent: 27 May 2011 12:23 > >>>>>> To: Stephen Botzko; Elwell, John > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: RE: [clue] legacy support in requirements > >>>>>> > >>>>>> I think it would be clearer to formulate two different > >>>>>> requirements > >>>>>> > >>>>>> > >>>>>> > >>>>>> 1) Two solution must provide a mechanism that make it > >>>>>> possible for endpoints with different capabilities to > >>>>>> interoperate, e.g. interoperability between a 2 camera/screens > >>>>>> and 3 camera/screens endpoint. > >>>>>> > >>>>>> 2) Two solution must provide a mechanism that make it > >>>>>> possible for endpoints that are CLUE aware to > interoperate with > >>>>>> CLUE-less endpoints. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Cheers > >>>>>> > >>>>>> > >>>>>> > >>>>>> -Espen > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>>>> Behalf Of Stephen Botzko > >>>>>> Sent: 27. mai 2011 13:16 > >>>>>> To: Elwell, John > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>> > >>>>>> > >>>>>> > >>>>>> I'm not sure that the language actually covers that (it seems > >>>>>> ambiguous). > >>>>>> > >>>>>> What do you think about changing "endpoints with different > >>>>>> capabilities" to "disparate devices"? > >>>>>> > >>>>>> Stephen > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John > >>>>>> wrote: > >>>>>> > >>>>>> I thought requirement 10 would cover both (signalling/protocol > >>>>>> capabilities as well as user interface capabilities). > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > >>>>>> > >>>>>>> Sent: 27 May 2011 11:53 > >>>>>>> To: Elwell, John > >>>>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat > (pkyzivat); > >>>>>>> clue@ietf.org > >>>>>> > >>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>> > >>>>>>> Do you think that the language in requirement 10 means "SIP > >>>>>>> capabilities"? Or something else? > >>>>>>> > >>>>>>> I am thinking that issue is really about the > signaling/protocol > >>>>>>> design itself, and isn't directly related to how many screens > >>>>>>> and cameras a system might have. > >>>>>>> > >>>>>>> Stephen Botzko > >>>>>>> > >>>>>>> > >>>>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Allyn, > >>>>>>> > >>>>>>> I already made a proposal: > >>>>>>> > >>>>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -----Original Message----- > >>>>>>> > From: Allyn Romanow (allyn) > [mailto:allyn@cisco.com] > >>>>>>> > >>>>>>> > Sent: 26 May 2011 20:08 > >>>>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); > Elwell, John > >>>>>>> > Cc: clue@ietf.org > >>>>>>> > Subject: RE: [clue] legacy support in > requirements > >>>>>>> > > >>>>>>> > Roni, Paul, John- > >>>>>>> > Would you care to suggest the wording > you would like > >>>>>>> to see as a > >>>>>>> > requirement for legacy > interoperability? That would > >>>>>>> be helpful. > >>>>>>> > > >>>>>>> > Thanks, > >>>>>>> > Allyn > >>>>>>> > > >>>>>>> > > -----Original Message----- > >>>>>>> > > From: clue-bounces@ietf.org > >>>>>>> [mailto:clue-bounces@ietf.org] On Behalf > >>>>>>> > Of > >>>>>>> > > Roni Even > >>>>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM > >>>>>>> > > To: Mike Hammer (hmmr); Paul > Kyzivat (pkyzivat) > >>>>>>> > > Cc: clue@ietf.org > >>>>>>> > > Subject: Re: [clue] legacy support > in requirements > >>>>>>> > > > >>>>>>> > .... > >>>>>>> > > > >>>>>>> > > Anyhow we are discussing solution > while my point > >>>>>> is that we > >>>>>>> > will need > >>>>>>> > > as a > >>>>>>> > > requirement to address the case of > a call from a > >>>>>>> CLUE aware endpoint > >>>>>>> > to > >>>>>>> > > a > >>>>>>> > > non CLUE aware endpoint. Even if > the consensus will > >>>>>>> be to have the > >>>>>>> > > preferred > >>>>>>> > > video in the first video m-line. > >>>>>>> > > > >>>>>>> > > Regards > >>>>>>> > > Roni > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > -----Original Message----- > >>>>>>> > > > From: Mike Hammer (hmmr) > [mailto:hmmr@cisco.com] > >>>>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM > >>>>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even > >>>>>>> > > > Cc: clue@ietf.org > >>>>>>> > > > Subject: RE: [clue] legacy support in > >>>>>>> requirements > >>>>>>> > > > > >>>>>>> > > > Paul, > >>>>>>> > > > > >>>>>>> > > > I would agree that if the > offer-answer model > >>>>>>> semantic is that here > >>>>>>> > > are > >>>>>>> > > > several options and any > subset of options is > >>>>>>> acceptable. > >>>>>>> > > > > >>>>>>> > > > However, if there is any > grouping involved such > >>>>>>> that you need to > >>>>>>> > have > >>>>>>> > > a > >>>>>>> > > > video and audio feed > integrated to make sense > >>>>>>> then watch out. > >>>>>>> > > > > >>>>>>> > > > For example, I wouldn't want > to end up with the > >>>>>>> result of a man's > >>>>>>> > > video > >>>>>>> > > > paired with a woman's voice. > That could be > >>>>>>> rather comical. > >>>>>>> > > > > >>>>>>> > > > Mike > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > -----Original Message----- > >>>>>>> > > > From: clue-bounces@ietf.org > >>>>>>> > [mailto:clue-bounces@ietf.org] On Behalf > >>>>>>> > > Of > >>>>>>> > > > Paul Kyzivat (pkyzivat) > >>>>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM > >>>>>>> > > > To: Roni Even > >>>>>>> > > > Cc: clue@ietf.org > >>>>>>> > > > Subject: Re: [clue] legacy support in > >>>>>>> requirements > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: > >>>>>>> > > > > Paul, > >>>>>>> > > > > I think we read it differently. > >>>>>>> > > > > If the answerer does not > support the group > >>>>>>> attribute > >>>>>>> > and the offer > >>>>>>> > > > had > >>>>>>> > > > the > >>>>>>> > > > > fid semantics it may > look to the answerer > >>>>>>> as an > >>>>>>> offer with > >>>>>>> > multiple > >>>>>>> > > > m-lines > >>>>>>> > > > > of the same media tyoe. > In this case an > >>>>>>> implementation > >>>>>>> > might also > >>>>>>> > > > decide to > >>>>>>> > > > > refuse the request > (e.g., 488 Not Acceptable > >>>>>>> Here, or 606 Not > >>>>>>> > > > Acceptable), > >>>>>>> > > > > because it contains > several "m" lines of the > >>>>>>> same media type. > >>>>>>> > > > > >>>>>>> > > > That is a slightly different story. > >>>>>>> > > > > >>>>>>> > > > Then the reason for rejection > is not because it > >>>>>>> saw an > >>>>>>> > attribute it > >>>>>>> > > > didn't understand - its > because it didn't like > >>>>>>> something it *did* > >>>>>>> > > > understand. > >>>>>>> > > > > >>>>>>> > > > > This is very relevant to > the multiple > >>>>>>> streams > >>>>>>> case and we should > >>>>>>> > > look > >>>>>>> > > > if we > >>>>>>> > > > > state this behavior or > we will look at > >>>>>>> providing an > >>>>>>> > approach that > >>>>>>> > > > will > >>>>>>> > > > allow > >>>>>>> > > > > the answerer to choose > one m-line that the > >>>>>>> offerer > >>>>>>> > prefers even of > >>>>>>> > > it > >>>>>>> > > > does > >>>>>>> > > > > not understand CLUE. > >>>>>>> > > > > >>>>>>> > > > IMO (lets see if others > differ), if a UA > >>>>>>> receives > >>>>>>> an offer with at > >>>>>>> > > > least > >>>>>>> > > > > >>>>>>> > > > one m-line it is happy with, > then it should not > >>>>>>> reject the call > >>>>>>> > > because > >>>>>>> > > > there are others that it does > not "understand". > >>>>>>> > > > > >>>>>>> > > > Here "understand" means > something different - > >>>>>>> presumably it does > >>>>>>> > > > understand the direct meaning > of the additional > >>>>>>> m-line, it just > >>>>>>> > > doesn't > >>>>>>> > > > understand the *significance* > or use of it. > >>>>>>> > > > > >>>>>>> > > > I see little difference to > getting to audio > >>>>>>> m-lines > >>>>>>> and > >>>>>>> > only wanting > >>>>>>> > > > one, and getting one audio > and one video and > >>>>>>> only > >>>>>>> > supporting audio. > >>>>>>> > > In > >>>>>>> > > > general you should not reject > an audio/video > >>>>>>> call > >>>>>>> just because you > >>>>>>> > > only > >>>>>>> > > > support audio. > >>>>>>> > > > > >>>>>>> > > > I think it will behoove clue > to strongly > >>>>>>> recommend > >>>>>>> that > >>>>>>> > the m-lines > >>>>>>> > > in > >>>>>>> > > > an offer be arranged so the > first ones are the > >>>>>>> ones it most wants > >>>>>>> > > used > >>>>>>> > > > if not all are. > >>>>>>> > > > > >>>>>>> > > > Thanks, > >>>>>>> > > > Paul > >>>>>>> > > > > >>>>>>> > > > > Roni > >>>>>>> > > > > > >>>>>>> > > > >> -----Original Message----- > >>>>>>> > > > >> From: Paul Kyzivat > >>>>>>> [mailto:pkyzivat@cisco.com] > >>>>>>> > > > >> Sent: Wednesday, May > 18, 2011 12:37 AM > >>>>>>> > > > >> To: Roni Even > >>>>>>> > > > >> Cc: 'Stephen Botzko'; > clue@ietf.org > >>>>>>> > > > >> Subject: Re: [clue] > legacy support in > >>>>>>> requirements > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> On 5/17/2011 5:20 PM, > Roni Even wrote: > >>>>>>> > > > >>> Paul, > >>>>>>> > > > >>> Look at > >>>>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>>>>>> > > > example > >>>>>>> > > > >>> Roni > >>>>>>> > > > >> > >>>>>>> > > > >> OK, I looked. It is > consistent with what I > >>>>>>> said. > >>>>>>> > > > >> Either a=3Dgroup: is > understood, or not. If > >>>>>>> not, > >>>>>>> its ignored, and > >>>>>>> > > not > >>>>>>> > > > put > >>>>>>> > > > >> in the answer. Same with a=3Dmid: > >>>>>>> > > > >> > >>>>>>> > > > >> If a=3Dgroup: *is* > understood, but some > >>>>>> parameter within > >>>>>>> > it is not, > >>>>>>> > > > there > >>>>>>> > > > >> are explicit rules for > what to do. > >>>>>>> > > > >> > >>>>>>> > > > >> AFAICT there are no > examples in this > >>>>>>> document > >>>>>>> where failure to > >>>>>>> > > > >> understand an a-line in > total (or even in > >>>>>>> part) results in > >>>>>>> > > rejecting > >>>>>>> > > > >> the > >>>>>>> > > > >> offer. > >>>>>>> > > > >> > >>>>>>> > > > >> Thanks, > >>>>>>> > > > >> Paul > >>>>>>> > > > >> > >>>>>>> > > > >>>> -----Original Message----- > >>>>>>> > > > >>>> From: clue-bounces@ietf.org > >>>>>>> [mailto:clue-bounces@ietf.org] On > >>>>>>> > > > Behalf > >>>>>>> > > > >> Of > >>>>>>> > > > >>>> Paul Kyzivat > >>>>>>> > > > >>>> Sent: Tuesday, May > 17, 2011 6:11 PM > >>>>>>> > > > >>>> To: Stephen Botzko > >>>>>>> > > > >>>> Cc: clue@ietf.org > >>>>>>> > > > >>>> Subject: Re: [clue] > legacy support in > >>>>>>> requirements > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> On 5/17/2011 10:34 > AM, Stephen Botzko > >>>>>>> wrote: > >>>>>>> > > > >>>> > >>>>>>> > > > >>>>> On 5/17/2011 > 2:24 AM, Roni Even > >>>>>>> wrote: > >>>>>>> > > > >>>> > >>>>>>> > > > >>>>> When the > offer includes > >>>>>>> parameters > >>>>>>> that > >>>>>>> > the answerer > >>>>>>> > > > does > >>>>>>> > > > >> not > >>>>>>> > > > >>>>> understand > >>>>>>> > > > >>>>> there are > two options, he can > >>>>>>> ignore the unknown > >>>>>>> > > > >> parameters > >>>>>>> > > > >>>> or > >>>>>>> > > > >>>>> reject > >>>>>>> > > > >>>>> the offer. > >>>>>>> > > > >>>>> Rejecting the > offer in that case > >>>>>>> is > >>>>>>> not really kosher. > >>>>>>> > > > >>>>> You are > required to ignore > >>>>>>> parameters > >>>>>>> you do not > >>>>>>> > > > understand. > >>>>>>> > > > >>>>> > >>>>>>> > > > >>>>> If you reject > something because > >>>>>>> you > >>>>>>> don't like the > >>>>>>> > > > parameters > >>>>>>> > > > >> it > >>>>>>> > > > >>>>> contains, then > that is an implicit > >>>>>>> statement that you > >>>>>>> > > > >> understand > >>>>>>> > > > >>>>> those > parameters well enough to > >>>>>>> decide to reject them. > >>>>>>> > > > >>>>> > >>>>>>> > > > >>>>> As far as I know, > you are always free > >>>>>>> to reject > >>>>>>> > offers, and it > >>>>>>> > > > >>>> doesn't > >>>>>>> > > > >>>>> really imply > anything when you do that.. > >>>>>>> Whether it is wise > >>>>>>> > is > >>>>>>> > > > >>>> perhaps > >>>>>>> > > > >>>>> a different question. > >>>>>>> > > > >>>>> Stephen Botzko > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> Certainly you are > always free to reject > >>>>>>> an > >>>>>>> offer. > >>>>>>> > > > >>>> In general I don't > know for certain the > >>>>>>> reason > >>>>>>> why, > >>>>>>> > and so if I > >>>>>>> > > > give > >>>>>>> > > > >>>> you > >>>>>>> > > > >>>> the benefit of the > doubt I will assume > >>>>>>> you have > >>>>>>> a > >>>>>>> > valid reason > >>>>>>> > - > >>>>>>> > > > >>>> perhaps > >>>>>>> > > > >>>> just policy. > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> But if the reason you > reject the offer is > >>>>>>> based on your > >>>>>>> > > violating > >>>>>>> > > > a > >>>>>>> > > > >>>> spec, then you are > non-conforming, > >>>>>>> whether I can > >>>>>>> > determine you > >>>>>>> > > are > >>>>>>> > > > >>>> non-conforming or > not. Whether being > >>>>>>> non-conforming is just > >>>>>>> > > > un-wise, > >>>>>>> > > > >> or > >>>>>>> > > > >>>> something stronger, > is a separate > >>>>>>> discussion. > >>>>>>> The > >>>>>>> > IETF does not > >>>>>>> > > > levy > >>>>>>> > > > >>>> any > >>>>>>> > > > >>>> penalties for > violating its specs. But > >>>>>>> sometimes the market > >>>>>>> > > does. > >>>>>>> > > > >> (And > >>>>>>> > > > >>>> sometimes not.) But > we don't need to > >>>>>>> endorse > >>>>>>> non-conforming > >>>>>>> > > > behavior > >>>>>>> > > > >> in > >>>>>>> > > > >>>> our documents. > >>>>>>> > > > >>>> > >>>>>>> > > > >>>> Thanks, > >>>>>>> > > > >>>> Paul > >>>>>>> > > > >>>> > >>>>>>> _______________________________________________ > >>>>>>> > > > >>>> clue mailing list > >>>>>>> > > > >>>> clue@ietf.org > >>>>>>> > > > >>>> > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > > > >>> > >>>>>>> > > > >>> > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > _______________________________________________ > >>>>>>> > > > clue mailing list > >>>>>>> > > > clue@ietf.org > >>>>>>> > > > > https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > > > >>>>>>> > > > _______________________________________________ > >>>>>>> > > clue mailing list > >>>>>>> > > clue@ietf.org > >>>>>>> > > https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > > >>>>>>> _______________________________________________ > >>>>>>> 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 Mon May 30 03:06:37 2011 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 919A0E0786 for ; Mon, 30 May 2011 03:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, 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 GoIyDrFyelTT for ; Mon, 30 May 2011 03:06:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8C646E0785 for ; Mon, 30 May 2011 03:06:35 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-32-4de36c2a869b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.29.20773.A2C63ED4; Mon, 30 May 2011 12:06:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 30 May 2011 12:06:33 +0200 From: Christer Holmberg To: Paul Kyzivat , Stephan Wenger Date: Mon, 30 May 2011 12:06:31 +0200 Thread-Topic: [clue] legacy support in requirements Thread-Index: AcwclNQaL3B6HtEWSJWk2EIHsvIn5wB+zGSw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2A682D@ESESSCMS0356.eemea.ericsson.se> References: <4DDFE16C.1030106@cisco.com> In-Reply-To: <4DDFE16C.1030106@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 30 May 2011 10:06:37 -0000 Hi, I would like to keep the MUST. Because, otherwise it will be very easy to d= rop interoperability: we define a mechanism that works for CLUEful devices,= then note that it will take a couple of more messages to make it work with= legacy, and then simply decide to drop the legacy interoperability require= ment for that case. I do not think we need to mandate that the signalling always look identical= , but I still think that the requirement for interoperability shall be a MU= ST, and we shall aim for a solution that works as good as possible for all = cases. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 27. toukokuuta 2011 20:38 > To: Stephan Wenger > Cc: clue@ietf.org > Subject: Re: [clue] legacy support in requirements > > > > On 5/27/2011 1:33 PM, Stephan Wenger wrote: > > As for SHOULD/MUST: > > I'm in favor of SHOULD, and the criteria would "if it can be done > > without adding excessive call setup delay, i.e. more than > one round-trip time. > > Stephan > > I'm ok with that - at least the "excessive" part, but maybe > not the i.e. > (IMO it would not be unreasonable if it took two o/a cycles > in the same INVITE, maybe even three. If it took two separate > INVITEs then it seems pretty unreasonable.) > > Thanks, > Paul > > > > On 5.27.2011 10:24 , "Paul Kyzivat" wrote: > > > >> Allyn, > >> > >> It seems that what I suggested is the latest preference. > Here it is > >> again. I think it is a new requirement in addition to the existing > >> REQMT-10: > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> REQMT-XYZ: The solution SHOULD/MUST make it possible for > endpoints > >> without support for telepresence extensions to participate in a > >> telepresence session with those that do. > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> > >> I dropped "mechanism" from John's because its unlikely to be a new > >> mechanism that makes this possible. (That would require changes to > >> the legacy systems.) Rather it will need to be the manner of using > >> existing mechanisms. > >> > >> And I changed "telepresence conference" to "telepresence session" > >> because this ought to work point-point as well as for conferences. > >> (But we probably need more definition work here, since neither > >> telepresence-conference nor telepresence-session is currently > >> defined.) > >> > >> And I don't know if this ought to be SHOULD/MUST. I could > go either > >> way on that, but if its SHOULD, then we ought to add some words on > >> what the criteria are for not doing it. > >> > >> Thanks, > >> Paul > >> > >> On 5/27/2011 12:28 PM, Elwell, John wrote: > >>> I was quite happy with the refinements that Paul > suggested, which I > >>> hope help. Unfortunately I will not be available during the next > >>> couple of weeks, so I will have to leave it to others to > help arrive > >>> at appropriate words. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>>> Sent: 27 May 2011 16:39 > >>>> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat) > >>>> Cc: clue@ietf.org > >>>> Subject: RE: [clue] legacy support in requirements > >>>> > >>>> Hi John, > >>>> Your suggestion is > >>>> > >>>> The solution MUST include a mechanism that makes it > >>>> possible for endpoints with different > capabilities to > >>>> interoperate in a telepresence conference, > >>>> including audio/video endpoints that do not support any > telepresence extensions. > >>>> > >>>> I have redone the requirements so that the reqmt for > heterogeneous > >>>> devices as in the use case, which was reqmt 10, is now > more specific. > >>>> So, we would not piggy back legacy on the hetereogeneity > requirement. > >>>> > >>>> Assuming this now refers only to the interaction of CLUE and > >>>> non-CLUE, the problem is that they don't interoperate in a > >>>> telepresence > >>>> sense- the > >>>> purpose for the WG. > >>>> > >>>> Therefore, I would ask you to be more specific about the legacy > >>>> requirement. I should think that the general meaning > would be along > >>>> the lines of that CLUE would not break any existing > interworking - > >>>> however this is general, and it would be good to make it more > >>>> specific. > >>>> > >>>> I think it would be really helpful if you Paul and Roni, > and others > >>>> if they wish, could suggest some new text to more specifically > >>>> cover what you have in mind which has been discussed in > detail on the list. > >>>> > >>>> Thanks, > >>>> Allyn > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>> Sent: Thursday, May 26, 2011 11:22 PM > >>>> To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat) > >>>> Cc: clue@ietf.org > >>>> Subject: RE: [clue] legacy support in requirements > >>>> > >>>> Allyn, > >>>> > >>>> I already made a proposal: > >>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html > >>>> > >>>> John > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > >>>>> Sent: 26 May 2011 20:08 > >>>>> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John > >>>>> Cc: clue@ietf.org > >>>>> Subject: RE: [clue] legacy support in requirements > >>>>> > >>>>> Roni, Paul, John- > >>>>> Would you care to suggest the wording you would like to > see as a > >>>>> requirement for legacy interoperability? That would be helpful. > >>>>> > >>>>> Thanks, > >>>>> Allyn > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org > >>>> [mailto:clue-bounces@ietf.org] On Behalf > >>>>> Of > >>>>>> Roni Even > >>>>>> Sent: Wednesday, May 18, 2011 11:13 AM > >>>>>> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat) > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>> > >>>>> .... > >>>>>> > >>>>>> Anyhow we are discussing solution while my point is that we > >>>>> will need > >>>>>> as a > >>>>>> requirement to address the case of a call from a CLUE > >>>> aware endpoint > >>>>> to > >>>>>> a > >>>>>> non CLUE aware endpoint. Even if the consensus will be to have > >>>>>> the preferred video in the first video m-line. > >>>>>> > >>>>>> Regards > >>>>>> Roni > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > >>>>>>> Sent: Wednesday, May 18, 2011 4:41 PM > >>>>>>> To: Paul Kyzivat (pkyzivat); Roni Even > >>>>>>> Cc: clue@ietf.org > >>>>>>> Subject: RE: [clue] legacy support in requirements > >>>>>>> > >>>>>>> Paul, > >>>>>>> > >>>>>>> I would agree that if the offer-answer model semantic > >>>> is that here > >>>>>> are > >>>>>>> several options and any subset of options is acceptable. > >>>>>>> > >>>>>>> However, if there is any grouping involved such that > you need to > >>>>> have > >>>>>> a > >>>>>>> video and audio feed integrated to make sense then watch out. > >>>>>>> > >>>>>>> For example, I wouldn't want to end up with the result > >>>> of a man's > >>>>>> video > >>>>>>> paired with a woman's voice. That could be rather comical. > >>>>>>> > >>>>>>> Mike > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue-bounces@ietf.org > >>>>> [mailto:clue-bounces@ietf.org] On Behalf > >>>>>> Of > >>>>>>> Paul Kyzivat (pkyzivat) > >>>>>>> Sent: Tuesday, May 17, 2011 7:45 PM > >>>>>>> To: Roni Even > >>>>>>> Cc: clue@ietf.org > >>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 5/17/2011 6:05 PM, Roni Even wrote: > >>>>>>>> Paul, > >>>>>>>> I think we read it differently. > >>>>>>>> If the answerer does not support the group attribute > >>>>> and the offer > >>>>>>> had > >>>>>>> the > >>>>>>>> fid semantics it may look to the answerer as an offer with > >>>>> multiple > >>>>>>> m-lines > >>>>>>>> of the same media tyoe. In this case an implementation > >>>>> might also > >>>>>>> decide to > >>>>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not > >>>>>>> Acceptable), > >>>>>>>> because it contains several "m" lines of the same media type. > >>>>>>> > >>>>>>> That is a slightly different story. > >>>>>>> > >>>>>>> Then the reason for rejection is not because it saw an > >>>>> attribute it > >>>>>>> didn't understand - its because it didn't like > >>>> something it *did* > >>>>>>> understand. > >>>>>>> > >>>>>>>> This is very relevant to the multiple streams case > >>>> and we should > >>>>>> look > >>>>>>> if we > >>>>>>>> state this behavior or we will look at providing an > >>>>> approach that > >>>>>>> will > >>>>>>> allow > >>>>>>>> the answerer to choose one m-line that the offerer > >>>>> prefers even of > >>>>>> it > >>>>>>> does > >>>>>>>> not understand CLUE. > >>>>>>> > >>>>>>> IMO (lets see if others differ), if a UA receives an > >>>> offer with at > >>>>>>> least > >>>>>>> > >>>>>>> one m-line it is happy with, then it should not > reject the call > >>>>>> because > >>>>>>> there are others that it does not "understand". > >>>>>>> > >>>>>>> Here "understand" means something different - > presumably it does > >>>>>>> understand the direct meaning of the additional > m-line, it just > >>>>>> doesn't > >>>>>>> understand the *significance* or use of it. > >>>>>>> > >>>>>>> I see little difference to getting to audio m-lines and > >>>>> only wanting > >>>>>>> one, and getting one audio and one video and only > >>>>> supporting audio. > >>>>>> In > >>>>>>> general you should not reject an audio/video call just > >>>> because you > >>>>>> only > >>>>>>> support audio. > >>>>>>> > >>>>>>> I think it will behoove clue to strongly recommend that > >>>>> the m-lines > >>>>>> in > >>>>>>> an offer be arranged so the first ones are the ones it > >>>> most wants > >>>>>> used > >>>>>>> if not all are. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>>> Roni > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>>> Sent: Wednesday, May 18, 2011 12:37 AM > >>>>>>>>> To: Roni Even > >>>>>>>>> Cc: 'Stephen Botzko'; clue@ietf.org > >>>>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 5/17/2011 5:20 PM, Roni Even wrote: > >>>>>>>>>> Paul, > >>>>>>>>>> Look at > http://tools.ietf.org/html/rfc5888#section-9.4.2 for > >>>>>>> example > >>>>>>>>>> Roni > >>>>>>>>> > >>>>>>>>> OK, I looked. It is consistent with what I said. > >>>>>>>>> Either a=3Dgroup: is understood, or not. If not, its > >>>> ignored, and > >>>>>> not > >>>>>>> put > >>>>>>>>> in the answer. Same with a=3Dmid: > >>>>>>>>> > >>>>>>>>> If a=3Dgroup: *is* understood, but some parameter within > >>>>> it is not, > >>>>>>> there > >>>>>>>>> are explicit rules for what to do. > >>>>>>>>> > >>>>>>>>> AFAICT there are no examples in this document where > >>>> failure to > >>>>>>>>> understand an a-line in total (or even in part) results in > >>>>>> rejecting > >>>>>>>>> the > >>>>>>>>> offer. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: clue-bounces@ietf.org > >>>> [mailto:clue-bounces@ietf.org] On > >>>>>>> Behalf > >>>>>>>>> Of > >>>>>>>>>>> Paul Kyzivat > >>>>>>>>>>> Sent: Tuesday, May 17, 2011 6:11 PM > >>>>>>>>>>> To: Stephen Botzko > >>>>>>>>>>> Cc: clue@ietf.org > >>>>>>>>>>> Subject: Re: [clue] legacy support in requirements > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 5/17/2011 10:34 AM, Stephen Botzko wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 5/17/2011 2:24 AM, Roni Even wrote: > >>>>>>>>>>> > >>>>>>>>>>>> When the offer includes parameters that > >>>>> the answerer > >>>>>>> does > >>>>>>>>> not > >>>>>>>>>>>> understand > >>>>>>>>>>>> there are two options, he can ignore the > >>>>>>>>>>>> unknown > >>>>>>>>> parameters > >>>>>>>>>>> or > >>>>>>>>>>>> reject > >>>>>>>>>>>> the offer. > >>>>>>>>>>>> Rejecting the offer in that case is not > >>>> really kosher. > >>>>>>>>>>>> You are required to ignore parameters you do not > >>>>>>> understand. > >>>>>>>>>>>> > >>>>>>>>>>>> If you reject something because you > don't like the > >>>>>>> parameters > >>>>>>>>> it > >>>>>>>>>>>> contains, then that is an implicit > >>>> statement that you > >>>>>>>>> understand > >>>>>>>>>>>> those parameters well enough to decide to > >>>> reject them. > >>>>>>>>>>>> > >>>>>>>>>>>> As far as I know, you are always free to reject > >>>>> offers, and it > >>>>>>>>>>> doesn't > >>>>>>>>>>>> really imply anything when you do that.. Whether > >>>> it is wise > >>>>> is > >>>>>>>>>>> perhaps > >>>>>>>>>>>> a different question. > >>>>>>>>>>>> Stephen Botzko > >>>>>>>>>>> > >>>>>>>>>>> Certainly you are always free to reject an offer. > >>>>>>>>>>> In general I don't know for certain the reason why, > >>>>> and so if I > >>>>>>> give > >>>>>>>>>>> you > >>>>>>>>>>> the benefit of the doubt I will assume you have a > >>>>> valid reason > >>>>> - > >>>>>>>>>>> perhaps > >>>>>>>>>>> just policy. > >>>>>>>>>>> > >>>>>>>>>>> But if the reason you reject the offer is based on your > >>>>>> violating > >>>>>>> a > >>>>>>>>>>> spec, then you are non-conforming, whether I can > >>>>> determine you > >>>>>> are > >>>>>>>>>>> non-conforming or not. Whether being > non-conforming is just > >>>>>>> un-wise, > >>>>>>>>> or > >>>>>>>>>>> something stronger, is a separate discussion. The > >>>>> IETF does not > >>>>>>> levy > >>>>>>>>>>> any > >>>>>>>>>>> penalties for violating its specs. But sometimes > the market > >>>>>> does. > >>>>>>>>> (And > >>>>>>>>>>> sometimes not.) But we don't need to endorse > non-conforming > >>>>>>> behavior > >>>>>>>>> in > >>>>>>>>>>> our documents. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Paul > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> clue mailing list > >>>>>>>>>>> clue@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>> > >> _______________________________________________ > >> 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@cisco.com Tue May 31 06:06:12 2011 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 C568FE07C1 for ; Tue, 31 May 2011 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.356 X-Spam-Level: X-Spam-Status: No, score=-110.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 x6uUr-BCWkPW for ; Tue, 31 May 2011 06:06:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 686EEE07B9 for ; Tue, 31 May 2011 06:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=26410; q=dns/txt; s=iport; t=1306847168; x=1308056768; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uDycUJPvc8qEhsxpSd2bczKHon+Sl+Yq5XjFwTPj75k=; b=FGI0MHcX8kZ+cL2lNY4XlLwH5H3M4xTn3Faz76xAH87yTxiQHGlngH/7 ysHJdiu+2G4TbMn9mbZ+SN5IeYV8zi6Zoji7LrkS1VEegzG70Z/OD8sB1 7jDVvlv0PKE1u+EsTTJ9qc2uX5KuWtqeUlCzt7HgzYkUYlN/Mht3OHXfK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAFfn5E2rRDoI/2dsb2JhbAA1HpdLjlJ3iHGfQZAljSuGHgSQT4Q+hCiGUA X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="456968471" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 31 May 2011 13:06:07 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VD67em019716; Tue, 31 May 2011 13:06:07 GMT Message-ID: <4DE4E7BF.8070301@cisco.com> Date: Tue, 31 May 2011 09:06:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] legacy support in requirements 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, 31 May 2011 13:06:12 -0000 OK by me. Thanks, Paul On 5/30/2011 2:08 AM, Christer Holmberg wrote: > > Hi, > > The text looks good, but could we replace "by the CLUE WG" with "by RFC XXXX", and at some point we/IANA will replace XXXX with a number. > > Because, I assume the definition is going to live after the WG? > > Regards, > > Christer > > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 27. toukokuuta 2011 23:23 >> To: Stephan Wenger >> Cc: clue@ietf.org >> Subject: Re: [clue] legacy support in requirements >> >> >> >> On 5/27/2011 4:07 PM, Stephan Wenger wrote: >>> Ok. >>> >>> How about: >>> >>> "Telepresence Extensions": The protocol extensions beyond >>> non-telepresence SIP specified by the CLUE WG. (The protocol and >>> architecture docs may wish to include something like "as defined >>> herein") >> >> I like that! >> >>> "Solution": Telepresence Extensions specification(s) and their >>> implementation. >> >> I would still hate to see such a narrow definition of that >> word in any broad context. It would be way too confusing. >> >> I think it would be ok in a narrow context - say a paragraph, >> or a section of a document. >> >> Thanks, >> Paul >> >>> Stephan >>> >>> >>> On 5.27.2011 10:42 , "Paul Kyzivat" wrote: >>> >>>> Stephan, >>>> >>>> On 5/27/2011 1:31 PM, Stephan Wenger wrote: >>>>> Hi Paul, >>>>> The summation of the protocol work designed by CLUE is >> referred to >>>>> as "solution". A CLUE-less device is a device without >> the solution. >>>>> Therefore, I propose to replace "telepresence extensions" >> (which is >>>>> undefined, and could refer to telepresence extension not >> defined by >>>>> CLUE) >>>>> with "solution". Thereafter, 10bis reads: >>>>> >>>>> REQMT-10bis: The solution MUST make it possible for endpoints >>>>> without support for the solution to participate in a telepresence >>>>> session with those that do. >>>> >>>> I appreciate what you are trying to accomplish, but I'm >> not too fond >>>> of the result. I think it would be unwise to formally >> define the term >>>> "solution" to have this meaning - its too general a word to co-opt. >>>> >>>> I would be ok with something like telepresence-solution. >> But whatever >>>> it is, it should then be added to the definitions. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> On 5.27.2011 06:02 , "Paul Kyzivat" wrote: >>>>> >>>>>> >>>>>> >>>>>> On 5/27/2011 8:28 AM, Elwell, John wrote: >>>>>>> I can live with Steve's proposal. I also don't mind >> separating the >>>>>>> requirements, but I don't think we should refer to CLUE in the >>>>>>> requirement - the RFC will live a long time after CLUE >> is finished >>>>>>> and closed down. So if we want to separate the requirements, I >>>>>>> would >>>>>>> propose: >>>>>>> >>>>>>> REQMT-10: The solution MUST include a mechanism that makes it >>>>>>> possible for endpoints with different capabilities to >> interoperate >>>>>>> in a telepresence conference. >>>>>>> REQMT-10bis: The solution MUST include a mechanism >> that makes it >>>>>>> possible for endpoints without support for telepresence >> extensions >>>>>>> to participate in a telepresence conference with those that do. >>>>>> >>>>>> How about the following variant of that: >>>>>> >>>>>> REQMT-10bis: The solution MUST make it possible for endpoints >>>>>> without support for telepresence extensions to participate in a >>>>>> telepresence session with those that do. >>>>>> >>>>>> I dropped "mechanism" because its unlikely to be a new mechanism >>>>>> that makes this possible. (That would require changes to >> the legacy >>>>>> systems.) >>>>>> Rather it will need to be the manner of using existing >> mechanisms. >>>>>> >>>>>> And I changed "telepresence conference" to "telepresence session" >>>>>> because this ought to work point-point as well as for >> conferences. >>>>>> (But we probably need more definition work here, since neither >>>>>> telepresence-conference nor telepresence-session is currently >>>>>> defined.) >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>>>>>> Sent: 27 May 2011 12:23 >>>>>>>> To: Stephen Botzko; Elwell, John >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: RE: [clue] legacy support in requirements >>>>>>>> >>>>>>>> I think it would be clearer to formulate two different >>>>>>>> requirements >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1) Two solution must provide a mechanism that make it >>>>>>>> possible for endpoints with different capabilities to >>>>>>>> interoperate, e.g. interoperability between a 2 camera/screens >>>>>>>> and 3 camera/screens endpoint. >>>>>>>> >>>>>>>> 2) Two solution must provide a mechanism that make it >>>>>>>> possible for endpoints that are CLUE aware to >> interoperate with >>>>>>>> CLUE-less endpoints. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Espen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>>>> Behalf Of Stephen Botzko >>>>>>>> Sent: 27. mai 2011 13:16 >>>>>>>> To: Elwell, John >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'm not sure that the language actually covers that (it seems >>>>>>>> ambiguous). >>>>>>>> >>>>>>>> What do you think about changing "endpoints with different >>>>>>>> capabilities" to "disparate devices"? >>>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 27, 2011 at 7:03 AM, Elwell, John >>>>>>>> wrote: >>>>>>>> >>>>>>>> I thought requirement 10 would cover both (signalling/protocol >>>>>>>> capabilities as well as user interface capabilities). >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >>>>>>>> >>>>>>>>> Sent: 27 May 2011 11:53 >>>>>>>>> To: Elwell, John >>>>>>>>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat >> (pkyzivat); >>>>>>>>> clue@ietf.org >>>>>>>> >>>>>>>>> Subject: Re: [clue] legacy support in requirements >>>>>>>>> >>>>>>>>> Do you think that the language in requirement 10 means "SIP >>>>>>>>> capabilities"? Or something else? >>>>>>>>> >>>>>>>>> I am thinking that issue is really about the >> signaling/protocol >>>>>>>>> design itself, and isn't directly related to how many screens >>>>>>>>> and cameras a system might have. >>>>>>>>> >>>>>>>>> Stephen Botzko >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, May 27, 2011 at 2:21 AM, Elwell, John >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Allyn, >>>>>>>>> >>>>>>>>> I already made a proposal: >>>>>>>>> >>>>>>>> http://www.ietf.org/mail-archive/web/clue/current/msg00221.html >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > -----Original Message----- >>>>>>>>> > From: Allyn Romanow (allyn) >> [mailto:allyn@cisco.com] >>>>>>>>> >>>>>>>>> > Sent: 26 May 2011 20:08 >>>>>>>>> > To: Roni Even; Paul Kyzivat (pkyzivat); >> Elwell, John >>>>>>>>> > Cc: clue@ietf.org >>>>>>>>> > Subject: RE: [clue] legacy support in >> requirements >>>>>>>>> > >>>>>>>>> > Roni, Paul, John- >>>>>>>>> > Would you care to suggest the wording >> you would like >>>>>>>>> to see as a >>>>>>>>> > requirement for legacy >> interoperability? That would >>>>>>>>> be helpful. >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > Allyn >>>>>>>>> > >>>>>>>>> > > -----Original Message----- >>>>>>>>> > > From: clue-bounces@ietf.org >>>>>>>>> [mailto:clue-bounces@ietf.org] On Behalf >>>>>>>>> > Of >>>>>>>>> > > Roni Even >>>>>>>>> > > Sent: Wednesday, May 18, 2011 11:13 AM >>>>>>>>> > > To: Mike Hammer (hmmr); Paul >> Kyzivat (pkyzivat) >>>>>>>>> > > Cc: clue@ietf.org >>>>>>>>> > > Subject: Re: [clue] legacy support >> in requirements >>>>>>>>> > > >>>>>>>>> > .... >>>>>>>>> > > >>>>>>>>> > > Anyhow we are discussing solution >> while my point >>>>>>>> is that we >>>>>>>>> > will need >>>>>>>>> > > as a >>>>>>>>> > > requirement to address the case of >> a call from a >>>>>>>>> CLUE aware endpoint >>>>>>>>> > to >>>>>>>>> > > a >>>>>>>>> > > non CLUE aware endpoint. Even if >> the consensus will >>>>>>>>> be to have the >>>>>>>>> > > preferred >>>>>>>>> > > video in the first video m-line. >>>>>>>>> > > >>>>>>>>> > > Regards >>>>>>>>> > > Roni >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > > -----Original Message----- >>>>>>>>> > > > From: Mike Hammer (hmmr) >> [mailto:hmmr@cisco.com] >>>>>>>>> > > > Sent: Wednesday, May 18, 2011 4:41 PM >>>>>>>>> > > > To: Paul Kyzivat (pkyzivat); Roni Even >>>>>>>>> > > > Cc: clue@ietf.org >>>>>>>>> > > > Subject: RE: [clue] legacy support in >>>>>>>>> requirements >>>>>>>>> > > > >>>>>>>>> > > > Paul, >>>>>>>>> > > > >>>>>>>>> > > > I would agree that if the >> offer-answer model >>>>>>>>> semantic is that here >>>>>>>>> > > are >>>>>>>>> > > > several options and any >> subset of options is >>>>>>>>> acceptable. >>>>>>>>> > > > >>>>>>>>> > > > However, if there is any >> grouping involved such >>>>>>>>> that you need to >>>>>>>>> > have >>>>>>>>> > > a >>>>>>>>> > > > video and audio feed >> integrated to make sense >>>>>>>>> then watch out. >>>>>>>>> > > > >>>>>>>>> > > > For example, I wouldn't want >> to end up with the >>>>>>>>> result of a man's >>>>>>>>> > > video >>>>>>>>> > > > paired with a woman's voice. >> That could be >>>>>>>>> rather comical. >>>>>>>>> > > > >>>>>>>>> > > > Mike >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > -----Original Message----- >>>>>>>>> > > > From: clue-bounces@ietf.org >>>>>>>>> > [mailto:clue-bounces@ietf.org] On Behalf >>>>>>>>> > > Of >>>>>>>>> > > > Paul Kyzivat (pkyzivat) >>>>>>>>> > > > Sent: Tuesday, May 17, 2011 7:45 PM >>>>>>>>> > > > To: Roni Even >>>>>>>>> > > > Cc: clue@ietf.org >>>>>>>>> > > > Subject: Re: [clue] legacy support in >>>>>>>>> requirements >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > On 5/17/2011 6:05 PM, Roni Even wrote: >>>>>>>>> > > > > Paul, >>>>>>>>> > > > > I think we read it differently. >>>>>>>>> > > > > If the answerer does not >> support the group >>>>>>>>> attribute >>>>>>>>> > and the offer >>>>>>>>> > > > had >>>>>>>>> > > > the >>>>>>>>> > > > > fid semantics it may >> look to the answerer >>>>>>>>> as an >>>>>>>>> offer with >>>>>>>>> > multiple >>>>>>>>> > > > m-lines >>>>>>>>> > > > > of the same media tyoe. >> In this case an >>>>>>>>> implementation >>>>>>>>> > might also >>>>>>>>> > > > decide to >>>>>>>>> > > > > refuse the request >> (e.g., 488 Not Acceptable >>>>>>>>> Here, or 606 Not >>>>>>>>> > > > Acceptable), >>>>>>>>> > > > > because it contains >> several "m" lines of the >>>>>>>>> same media type. >>>>>>>>> > > > >>>>>>>>> > > > That is a slightly different story. >>>>>>>>> > > > >>>>>>>>> > > > Then the reason for rejection >> is not because it >>>>>>>>> saw an >>>>>>>>> > attribute it >>>>>>>>> > > > didn't understand - its >> because it didn't like >>>>>>>>> something it *did* >>>>>>>>> > > > understand. >>>>>>>>> > > > >>>>>>>>> > > > > This is very relevant to >> the multiple >>>>>>>>> streams >>>>>>>>> case and we should >>>>>>>>> > > look >>>>>>>>> > > > if we >>>>>>>>> > > > > state this behavior or >> we will look at >>>>>>>>> providing an >>>>>>>>> > approach that >>>>>>>>> > > > will >>>>>>>>> > > > allow >>>>>>>>> > > > > the answerer to choose >> one m-line that the >>>>>>>>> offerer >>>>>>>>> > prefers even of >>>>>>>>> > > it >>>>>>>>> > > > does >>>>>>>>> > > > > not understand CLUE. >>>>>>>>> > > > >>>>>>>>> > > > IMO (lets see if others >> differ), if a UA >>>>>>>>> receives >>>>>>>>> an offer with at >>>>>>>>> > > > least >>>>>>>>> > > > >>>>>>>>> > > > one m-line it is happy with, >> then it should not >>>>>>>>> reject the call >>>>>>>>> > > because >>>>>>>>> > > > there are others that it does >> not "understand". >>>>>>>>> > > > >>>>>>>>> > > > Here "understand" means >> something different - >>>>>>>>> presumably it does >>>>>>>>> > > > understand the direct meaning >> of the additional >>>>>>>>> m-line, it just >>>>>>>>> > > doesn't >>>>>>>>> > > > understand the *significance* >> or use of it. >>>>>>>>> > > > >>>>>>>>> > > > I see little difference to >> getting to audio >>>>>>>>> m-lines >>>>>>>>> and >>>>>>>>> > only wanting >>>>>>>>> > > > one, and getting one audio >> and one video and >>>>>>>>> only >>>>>>>>> > supporting audio. >>>>>>>>> > > In >>>>>>>>> > > > general you should not reject >> an audio/video >>>>>>>>> call >>>>>>>>> just because you >>>>>>>>> > > only >>>>>>>>> > > > support audio. >>>>>>>>> > > > >>>>>>>>> > > > I think it will behoove clue >> to strongly >>>>>>>>> recommend >>>>>>>>> that >>>>>>>>> > the m-lines >>>>>>>>> > > in >>>>>>>>> > > > an offer be arranged so the >> first ones are the >>>>>>>>> ones it most wants >>>>>>>>> > > used >>>>>>>>> > > > if not all are. >>>>>>>>> > > > >>>>>>>>> > > > Thanks, >>>>>>>>> > > > Paul >>>>>>>>> > > > >>>>>>>>> > > > > Roni >>>>>>>>> > > > > >>>>>>>>> > > > >> -----Original Message----- >>>>>>>>> > > > >> From: Paul Kyzivat >>>>>>>>> [mailto:pkyzivat@cisco.com] >>>>>>>>> > > > >> Sent: Wednesday, May >> 18, 2011 12:37 AM >>>>>>>>> > > > >> To: Roni Even >>>>>>>>> > > > >> Cc: 'Stephen Botzko'; >> clue@ietf.org >>>>>>>>> > > > >> Subject: Re: [clue] >> legacy support in >>>>>>>>> requirements >>>>>>>>> > > > >> >>>>>>>>> > > > >> >>>>>>>>> > > > >> >>>>>>>>> > > > >> On 5/17/2011 5:20 PM, >> Roni Even wrote: >>>>>>>>> > > > >>> Paul, >>>>>>>>> > > > >>> Look at >>>>>>>>> http://tools.ietf.org/html/rfc5888#section-9.4.2 for >>>>>>>>> > > > example >>>>>>>>> > > > >>> Roni >>>>>>>>> > > > >> >>>>>>>>> > > > >> OK, I looked. It is >> consistent with what I >>>>>>>>> said. >>>>>>>>> > > > >> Either a=group: is >> understood, or not. If >>>>>>>>> not, >>>>>>>>> its ignored, and >>>>>>>>> > > not >>>>>>>>> > > > put >>>>>>>>> > > > >> in the answer. Same with a=mid: >>>>>>>>> > > > >> >>>>>>>>> > > > >> If a=group: *is* >> understood, but some >>>>>>>> parameter within >>>>>>>>> > it is not, >>>>>>>>> > > > there >>>>>>>>> > > > >> are explicit rules for >> what to do. >>>>>>>>> > > > >> >>>>>>>>> > > > >> AFAICT there are no >> examples in this >>>>>>>>> document >>>>>>>>> where failure to >>>>>>>>> > > > >> understand an a-line in >> total (or even in >>>>>>>>> part) results in >>>>>>>>> > > rejecting >>>>>>>>> > > > >> the >>>>>>>>> > > > >> offer. >>>>>>>>> > > > >> >>>>>>>>> > > > >> Thanks, >>>>>>>>> > > > >> Paul >>>>>>>>> > > > >> >>>>>>>>> > > > >>>> -----Original Message----- >>>>>>>>> > > > >>>> From: clue-bounces@ietf.org >>>>>>>>> [mailto:clue-bounces@ietf.org] On >>>>>>>>> > > > Behalf >>>>>>>>> > > > >> Of >>>>>>>>> > > > >>>> Paul Kyzivat >>>>>>>>> > > > >>>> Sent: Tuesday, May >> 17, 2011 6:11 PM >>>>>>>>> > > > >>>> To: Stephen Botzko >>>>>>>>> > > > >>>> Cc: clue@ietf.org >>>>>>>>> > > > >>>> Subject: Re: [clue] >> legacy support in >>>>>>>>> requirements >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> On 5/17/2011 10:34 >> AM, Stephen Botzko >>>>>>>>> wrote: >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>>> On 5/17/2011 >> 2:24 AM, Roni Even >>>>>>>>> wrote: >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>>> When the >> offer includes >>>>>>>>> parameters >>>>>>>>> that >>>>>>>>> > the answerer >>>>>>>>> > > > does >>>>>>>>> > > > >> not >>>>>>>>> > > > >>>>> understand >>>>>>>>> > > > >>>>> there are >> two options, he can >>>>>>>>> ignore the unknown >>>>>>>>> > > > >> parameters >>>>>>>>> > > > >>>> or >>>>>>>>> > > > >>>>> reject >>>>>>>>> > > > >>>>> the offer. >>>>>>>>> > > > >>>>> Rejecting the >> offer in that case >>>>>>>>> is >>>>>>>>> not really kosher. >>>>>>>>> > > > >>>>> You are >> required to ignore >>>>>>>>> parameters >>>>>>>>> you do not >>>>>>>>> > > > understand. >>>>>>>>> > > > >>>>> >>>>>>>>> > > > >>>>> If you reject >> something because >>>>>>>>> you >>>>>>>>> don't like the >>>>>>>>> > > > parameters >>>>>>>>> > > > >> it >>>>>>>>> > > > >>>>> contains, then >> that is an implicit >>>>>>>>> statement that you >>>>>>>>> > > > >> understand >>>>>>>>> > > > >>>>> those >> parameters well enough to >>>>>>>>> decide to reject them. >>>>>>>>> > > > >>>>> >>>>>>>>> > > > >>>>> As far as I know, >> you are always free >>>>>>>>> to reject >>>>>>>>> > offers, and it >>>>>>>>> > > > >>>> doesn't >>>>>>>>> > > > >>>>> really imply >> anything when you do that.. >>>>>>>>> Whether it is wise >>>>>>>>> > is >>>>>>>>> > > > >>>> perhaps >>>>>>>>> > > > >>>>> a different question. >>>>>>>>> > > > >>>>> Stephen Botzko >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> Certainly you are >> always free to reject >>>>>>>>> an >>>>>>>>> offer. >>>>>>>>> > > > >>>> In general I don't >> know for certain the >>>>>>>>> reason >>>>>>>>> why, >>>>>>>>> > and so if I >>>>>>>>> > > > give >>>>>>>>> > > > >>>> you >>>>>>>>> > > > >>>> the benefit of the >> doubt I will assume >>>>>>>>> you have >>>>>>>>> a >>>>>>>>> > valid reason >>>>>>>>> > - >>>>>>>>> > > > >>>> perhaps >>>>>>>>> > > > >>>> just policy. >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> But if the reason you >> reject the offer is >>>>>>>>> based on your >>>>>>>>> > > violating >>>>>>>>> > > > a >>>>>>>>> > > > >>>> spec, then you are >> non-conforming, >>>>>>>>> whether I can >>>>>>>>> > determine you >>>>>>>>> > > are >>>>>>>>> > > > >>>> non-conforming or >> not. Whether being >>>>>>>>> non-conforming is just >>>>>>>>> > > > un-wise, >>>>>>>>> > > > >> or >>>>>>>>> > > > >>>> something stronger, >> is a separate >>>>>>>>> discussion. >>>>>>>>> The >>>>>>>>> > IETF does not >>>>>>>>> > > > levy >>>>>>>>> > > > >>>> any >>>>>>>>> > > > >>>> penalties for >> violating its specs. But >>>>>>>>> sometimes the market >>>>>>>>> > > does. >>>>>>>>> > > > >> (And >>>>>>>>> > > > >>>> sometimes not.) But >> we don't need to >>>>>>>>> endorse >>>>>>>>> non-conforming >>>>>>>>> > > > behavior >>>>>>>>> > > > >> in >>>>>>>>> > > > >>>> our documents. >>>>>>>>> > > > >>>> >>>>>>>>> > > > >>>> Thanks, >>>>>>>>> > > > >>>> Paul >>>>>>>>> > > > >>>> >>>>>>>>> _______________________________________________ >>>>>>>>> > > > >>>> clue mailing list >>>>>>>>> > > > >>>> clue@ietf.org >>>>>>>>> > > > >>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> > > > >>> >>>>>>>>> > > > >>> >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > >> _______________________________________________ >>>>>>>>> > > > clue mailing list >>>>>>>>> > > > clue@ietf.org >>>>>>>>> > > > >> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> > > >>>>>>>>> > > >> _______________________________________________ >>>>>>>>> > > clue mailing list >>>>>>>>> > > clue@ietf.org >>>>>>>>> > > https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> > >>>>>>>>> _______________________________________________ >>>>>>>>> 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 stewe@stewe.org Tue May 31 16:04:04 2011 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 E41CD13000E for ; Tue, 31 May 2011 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 RfIcrCcsTcVp for ; Tue, 31 May 2011 16:04:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id F22C6E073A for ; Tue, 31 May 2011 16:04:03 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1029-1743317 for ; Wed, 01 Jun 2011 01:04:03 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 31 May 2011 16:03:51 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Definitions: Participant Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389702641_42542598" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] Definitions: Participant 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, 31 May 2011 23:04:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389702641_42542598 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, I thought I would quickly rev the definitions doc, and found out that I cannot find agreements on a number of terms. This is the first of a set of eamils that will hopefully lead us to close the definitions on a few terms. So this email is about "Participant". We have the odd definition that RFC 4353 lists participant essentially as a piece of software and not as a human. To Song Haibin, Steve Botzko (and to me), Participants sounds like human, though. Several ways forward: 1. Use Participant in the 4353 sense only 2. Use Participant in the sense of a human participating in a telepresence session only. That would mean that there can be many participants at any endpoint, and endpoint can have no participant (empty room or webcam), and so forth. 3. Use Participant in the sense of 2) above, and add remark that if 4353 Participant is meant, this will be explicitely mentioned. My preference is 1. 2 and 3 have too much potential for confusion. Shame on 4353 for that. Opinions? Stephan --B_3389702641_42542598 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
I thought = I would quickly rev the definitions doc, and found out that I cannot find ag= reements on a number of terms.  This is the first of a set of eamils th= at will hopefully lead us to close the definitions on a few terms.
So this email is about "Participant".

We have the = odd definition that RFC 4353 lists participant essentially as a  piece = of software and not as a human.  To Song Haibin, Steve Botzko (and to m= e), Participants sounds like human, though.  

= Several ways forward:
  1. Use Participant in the 4353 sense only
  2. Use Participant in the sense of a human participating in a telepresenc= e session only.  That would mean that there can be many participants at= any endpoint, and endpoint can have no participant (empty room or webcam), = and so forth.
  3. Use Participant in the sense of 2) above, and add rema= rk that if 4353 Participant is meant, this will be explicitely mentioned. &n= bsp;
My preference is 1.  2 and 3 have too much potential= for confusion.  Shame on 4353 for that.

Opini= ons?

Stephan


--B_3389702641_42542598-- From stewe@stewe.org Tue May 31 16:16:09 2011 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 271FF13000E for ; Tue, 31 May 2011 16:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 tb56-7qoECE7 for ; Tue, 31 May 2011 16:16:08 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6364E13000D for ; Tue, 31 May 2011 16:16:08 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1033-1743317 for ; Wed, 01 Jun 2011 01:16:07 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 31 May 2011 16:16:01 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Definitions: left, right Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389703366_42585592" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] Definitions: left, right 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, 31 May 2011 23:16:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389703366_42585592 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be confusing,because some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender left" viewed from the viewpoint of a person in the sending endpoint room (house left), or from the viewpoint of the guy adjusting the camera (which could easily be stage left; at least that was the case in the TeleSuite rooms)? Also, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to be solution space only. I have no suggestion except perhaps to avoid defining the words, but rather remind CLUE authors that they can be confusing, and should only be used in conjunction with appropriate attributes such as "from sending endpoint camera's view". Speaking as individual, and not as editor, I'm against any definition that makes assumptions of "proper rendering". There is no such thing as proper rendering; rendering is an implementation issue and I can imagine many cases where a camera signal that, from a person located in the room where it is captured, and facing the screens, would be on the left, should not be rendered on the right in a Remote room. (This tries to describe the natural feel of telepresence with more than one camera/screen). Opinions? Stephan --B_3389703366_42585592 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

We did not come to a conclusion how to define "left" or "right".
=
-Stage/auditorium/house right left have been shown to be conf= using,because some of us are not theatre majors :-)

-sender/receiver left/right does not make sense either.  Is "sender le= ft" viewed from the viewpoint of a person in the sending endpoint room (hous= e left), or from the viewpoint of the guy adjusting the camera (which could = easily be stage left; at least that was the case in the TeleSuite rooms)? &n= bsp;Also, we have senders and receivers that are not endpoints, i.e. MCUs.
 
I like the idea of introducing a numbering co= nvention, but that seems to be solution space only.

I have no suggestion except perhaps to avoid defining the words, but = rather remind CLUE authors that they can be confusing, and should only be us= ed in conjunction with appropriate attributes such as "from sending endpoint= camera's view".

Speaking as individual, and not as= editor, I'm against any definition that makes assumptions of  "proper = rendering".  There is no such thing as proper rendering; rendering is a= n implementation issue and I can imagine many cases where a camera signal th= at, from a person located in the room where it is captured, and facing the s= creens, would be on the left, should not be rendered on the right in a Remot= e room.  (This tries to describe the natural feel of telepresence with = more than one camera/screen).

Opinions?
<= br>
Stephan

--B_3389703366_42585592-- From stewe@stewe.org Tue May 31 16:20:22 2011 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 4B001130011 for ; Tue, 31 May 2011 16:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 fOciYOmh7aqL for ; Tue, 31 May 2011 16:20:20 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD3813000D for ; Tue, 31 May 2011 16:20:19 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1035-1743317 for ; Wed, 01 Jun 2011 01:20:19 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 31 May 2011 16:20:12 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Definition of "Solution" Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389703618_42604378" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] Definition of "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: Tue, 31 May 2011 23:20:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389703618_42604378 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, A topic where we seemed to be converging: Use "solution" as a very informal word, to be interpreted widely and in context-sesitively. In other words, don't define it. To refer to the suite of documents defining a protocol, to be developed by CLUE, refer top them as Telepresence Extensions, and use the definition below: "Telepresence Extensions": The protocol extensions beyond non-telepresence SIP specified by RFC XXXX. (XXX to be replaced by the RFC editor with any documents developed by the CLUE WG that contain normative content, such as architecture, protocol specification, and whatnot.) Agreed? Stephan --B_3389703618_42604378 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

A topic where we seemed to be converging:

Use "sol= ution" as a very informal word, to be interpreted widely and in context-sesi= tively.  In other words, don't define it.

To r= efer to the suite of documents defining a protocol,  to be developed by= CLUE, refer top them as Telepresence Extensions, and use the definition bel= ow:

"Telepresence Extensions": The protocol ex= tensions beyond non-telepresence SIP specified by RFC XXXX.  (XXX = to be replaced by the RFC editor with any documents developed by the CLUE WG= that contain normative content, such as architecture, protocol specificatio= n, and whatnot.)

Agreed?

=
Stephan

--B_3389703618_42604378-- From mark.gorzynski@hp.com Tue May 31 16:40:45 2011 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 765E3E0679 for ; Tue, 31 May 2011 16:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qqiYzTqRiieV for ; Tue, 31 May 2011 16:40:44 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE257E067B for ; Tue, 31 May 2011 16:40:43 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 45F131436B; Tue, 31 May 2011 23:40:43 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 31 May 2011 23:39:06 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.240]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Tue, 31 May 2011 23:39:06 +0000 From: "Gorzynski, Mark E (The Right One)" To: Stephan Wenger , "clue@ietf.org" Date: Tue, 31 May 2011 23:39:05 +0000 Thread-Topic: Definitions: Participant Thread-Index: Acwf5wtYipakeOKkQEq186FjovU8ugABGaFQ Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B786EB20@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B786EB20GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions: Participant 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, 31 May 2011 23:40:45 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB20GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, My preference is to use 'participant' in the 4353 sense as well since that = is already established. Perhaps there are other terms like 'attendee' or '= user' that could be used for humans if needed? If I could go back in time, I would try to change 4353 :). Best Regards, Mark G. From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Tuesday, May 31, 2011 4:04 PM To: clue@ietf.org Subject: [clue] Definitions: Participant Hi all, I thought I would quickly rev the definitions doc, and found out that I can= not find agreements on a number of terms. This is the first of a set of ea= mils that will hopefully lead us to close the definitions on a few terms. So this email is about "Participant". We have the odd definition that RFC 4353 lists participant essentially as a= piece of software and not as a human. To Song Haibin, Steve Botzko (and = to me), Participants sounds like human, though. Several ways forward: 1. Use Participant in the 4353 sense only 2. Use Participant in the sense of a human participating in a telepresenc= e session only. That would mean that there can be many participants at any= endpoint, and endpoint can have no participant (empty room or webcam), and= so forth. 3. Use Participant in the sense of 2) above, and add remark that if 4353 = Participant is meant, this will be explicitely mentioned. My preference is 1. 2 and 3 have too much potential for confusion. Shame = on 4353 for that. Opinions? Stephan --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB20GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings= ,

 =

My preference is to use ‘participant&= #8217; in the 4353 sense as well since that is already established.  Perhaps there are other terms like ‘atten= dee’ or ‘user’  that could be used for humans if nee= ded?

 

If I could go back in time, I would= try to change 4353 J.

 

Best Re= gards,

Mark G.<= /span>

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ie= tf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, May 31,= 2011 4:04 PM
To: clue@ietf.org
Subject: [clue] Definit= ions: Participant

 

Hi all,<= /p>

I thought I would quickly rev the d= efinitions doc, and found out that I cannot find agreements on a number of = terms.  This is the first of a set of eamils that will hopefully lead = us to close the definitions on a few terms.

So this email is about "Participant".<= o:p>

 =

We have the odd definition = that RFC 4353 lists participant essentially as a  piece of software an= d not as a human.  To Song Haibin, Steve Botzko (and to me), Participa= nts sounds like human, though.  

 

Several ways forward:

  1. Use Participant in the 4353 se= nse only
  2. = Use Par= ticipant in the sense of a human participating in a telepresence session on= ly.  That would mean that there can be many participants at any endpoi= nt, and endpoint can have no participant (empty room or webcam), and so for= th.
  3. Use Particip= ant in the sense of 2) above, and add remark that if 4353 Participant is me= ant, this will be explicitely mentioned.  
=

My preference is 1.  2 and 3 have too m= uch potential for confusion.  Shame on 4353 for that.

 

Opinions?

<= p class=3DMsoNormal> 

Stephan

 

 

= --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB20GVW1096EXBame_-- From pkyzivat@cisco.com Tue May 31 16:50:03 2011 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 9E89AE0721 for ; Tue, 31 May 2011 16:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.361 X-Spam-Level: X-Spam-Status: No, score=-110.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 2iRTKKaJyZ1T for ; Tue, 31 May 2011 16:50:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A9CECE06DD for ; Tue, 31 May 2011 16:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1779; q=dns/txt; s=iport; t=1306885800; x=1308095400; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NSxzlFjoptZOsYHBTuF2Z4iQWXtSrvOEm+UcaMNkoI8=; b=mrKL7oH4LpQNij9AbhRjpXNEQzwW8/+xrssP384dGJe9A2tTOq3QbDwD jiZRnrCqrCKBmLupJP5KK+3lUI5A1y6cw0d6CZDxPzTv3xGwFnl4+Wgpn b7fZ5O8nC9OjTcoM+bkIWR9dxm+aAt6r9B72+SggQyYsQssA3f0GzmJvt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAGAJR95U2tJV2Y/2dsb2JhbABTmAyOEnenbZ1Nhh4EkE+EPop4 X-IronPort-AV: E=Sophos;i="4.65,300,1304294400"; d="scan'208";a="327357525" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 31 May 2011 23:50:00 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4VNnvXx032362 for ; Tue, 31 May 2011 23:49:57 GMT Message-ID: <4DE57EA5.6060406@cisco.com> Date: Tue, 31 May 2011 19:49:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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] Definitions: Participant 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, 31 May 2011 23:50:03 -0000 I support using Participant in the 4353 sense. (Its really the only definition that most of the software can use in a useful way. E.g. the conference roster is about these automata. This becomes especially obvious when you have the same "person" showing up multiple times in the roster.) If there is need to talk about the human(s) associated with a participant, then it would make sense to define another term for that. Thanks, Paul (as individual) On 5/31/2011 7:03 PM, Stephan Wenger wrote: > Hi all, > I thought I would quickly rev the definitions doc, and found out that I > cannot find agreements on a number of terms. This is the first of a set > of eamils that will hopefully lead us to close the definitions on a few > terms. > So this email is about "Participant". > > We have the odd definition that RFC 4353 lists participant essentially > as a piece of software and not as a human. To Song Haibin, Steve Botzko > (and to me), Participants sounds like human, though. > > Several ways forward: > > 1. Use Participant in the 4353 sense only > 2. Use Participant in the sense of a human participating in a > telepresence session only. That would mean that there can be many > participants at any endpoint, and endpoint can have no participant > (empty room or webcam), and so forth. > 3. Use Participant in the sense of 2) above, and add remark that if > 4353 Participant is meant, this will be explicitely mentioned. > > My preference is 1. 2 and 3 have too much potential for confusion. Shame > on 4353 for that. > > Opinions? > > Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Tue May 31 16:51:56 2011 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 B7EB0E0745 for ; Tue, 31 May 2011 16:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zw7iZwgJ-Wi3 for ; Tue, 31 May 2011 16:51:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 45754E0721 for ; Tue, 31 May 2011 16:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=873; q=dns/txt; s=iport; t=1306885914; x=1308095514; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=c43czMANEdpYyAr8Y90Wc8nhLYIjMv+7QkkK4N6A0C8=; b=exRCshF4zpPq7kJFbyUj35+LVbQ93f+aZ/9OSM7LuWDhq8sof1VRR7Z+ BXsTcn1WfqjpjUnEjErj3dNKXJaSkNtF19WJnQqHHeFcM4uLvV+wYw/8P rMsHgIlVhi348Plxot76EohRjUnlTiU6e5FFWT9qtwL2zSUXMUWqft1RQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAGAAt+5U2tJV2Y/2dsb2JhbABTmAyOEnencZ1Ohh4EkE+EPop4 X-IronPort-AV: E=Sophos;i="4.65,300,1304294400"; d="scan'208";a="706116916" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 31 May 2011 23:51:53 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4VNprje000814 for ; Tue, 31 May 2011 23:51:53 GMT Message-ID: <4DE57F19.90102@cisco.com> Date: Tue, 31 May 2011 19:51:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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] Definition of "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: Tue, 31 May 2011 23:51:56 -0000 wfm On 5/31/2011 7:20 PM, Stephan Wenger wrote: > Hi, > > A topic where we seemed to be converging: > > Use "solution" as a very informal word, to be interpreted widely and in > context-sesitively. In other words, don't define it. > > To refer to the suite of documents defining a protocol, to be developed > by CLUE, refer top them as Telepresence Extensions, and use the > definition below: > > "Telepresence Extensions": The protocol extensions beyond > non-telepresence SIP specified by RFC XXXX. (XXX to be replaced by the > RFC editor with any documents developed by the CLUE WG that contain > normative content, such as architecture, protocol specification, and > whatnot.) > > Agreed? > > Stephan > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mark.gorzynski@hp.com Tue May 31 17:03:45 2011 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 B0E03E0750 for ; Tue, 31 May 2011 17:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZEtRQiBscyrp for ; Tue, 31 May 2011 17:03:42 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5DE06DD for ; Tue, 31 May 2011 17:03:42 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 2093938A09; Wed, 1 Jun 2011 00:03:42 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 1 Jun 2011 00:03:13 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.240]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Wed, 1 Jun 2011 00:03:12 +0000 From: "Gorzynski, Mark E (The Right One)" To: Stephan Wenger , "clue@ietf.org" Date: Wed, 1 Jun 2011 00:03:11 +0000 Thread-Topic: Definitions: left, right Thread-Index: Acwf6LqQv2BMONG3Qc+myT0Jek1xvwABA+iQ Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B786EB3DGVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions: left, right 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 Jun 2011 00:03:45 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB3DGVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In television and cinematography, the terms 'camera left' and 'camera right= ' are differentiated carefully from 'stage / house left', 'stage / house ri= ght'. There are many references. For example http://www.safilm.com.au/library/SA= FC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of view.= Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's p= oint of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view acto= rs from the point of view of the local in-room audience. Thus 'stage left'= takes the sense of the actors while 'camera left' takes the sense of the l= ocal audience. We could use either for our use as long as we are clear. A point to notice= is that the receiver and sender will many times have an opposite sense. C= amera left for a receiver will often be stage left for a sender. Regards, Mark G. From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be confusing,because = some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender left" v= iewed from the viewpoint of a person in the sending endpoint room (house le= ft), or from the viewpoint of the guy adjusting the camera (which could eas= ily be stage left; at least that was the case in the TeleSuite rooms)? Als= o, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to be= solution space only. I have no suggestion except perhaps to avoid defining the words, but rather= remind CLUE authors that they can be confusing, and should only be used in= conjunction with appropriate attributes such as "from sending endpoint cam= era's view". Speaking as individual, and not as editor, I'm against any definition that = makes assumptions of "proper rendering". There is no such thing as proper= rendering; rendering is an implementation issue and I can imagine many cas= es where a camera signal that, from a person located in the room where it i= s captured, and facing the screens, would be on the left, should not be ren= dered on the right in a Remote room. (This tries to describe the natural f= eel of telepresence with more than one camera/screen). Opinions? Stephan --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB3DGVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In televi= sion and cinematography, the terms ‘camera left’ and ‘cam= era right’ are differentiated carefully from ‘stage / house lef= t’, ‘stage / house right’.

 

There are many references.  For example http://www.safilm.com.au/libra= ry/SAFC_FILMMAKERS_HANDBOOK.pdf

 

Camera Le= ft/Camera Right: Directions given from the camera's point of view. Opposite= of STAGE LEFT and STAGE RIGHT, which are given from the actor's point of v= iew. May also be called LEFT FRAME and RIGHT FRAME.

 

= This makes sense if you observe that cameras in studios typically vi= ew actors from the point of view of the local in-room audience.  Thus = ‘stage left’ takes the sense of the actors while ‘camera = left’ takes the sense of the local audience.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>We could use either for our use as long as we are clear.  A poin= t to notice is that the receiver and sender will many times have an opposit= e sense.  Camera left for a receiver will often be stage left for a se= nder.

 

Regards,

Mark G.

 

 

 

 

 

 =

&nb= sp;

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Weng= er
Sent: Tuesday, May 31, 2011 4:16 PM
To: clue@ietf.or= g
Subject: [clue] Definitions: left, right

<= /div>

 

Hi,

 

We did not com= e to a conclusion how to define "left" or "right".=

 

-Stage/auditorium/house right l= eft have been shown to be confusing,because some of us are not theatre majo= rs :-)

 = ;

-sender/receiver lef= t/right does not make sense either.  Is "sender left" viewed= from the viewpoint of a person in the sending endpoint room (house left), = or from the viewpoint of the guy adjusting the camera (which could easily b= e stage left; at least that was the case in the TeleSuite rooms)?  Als= o, we have senders and receivers that are not endpoints, i.e. MCUs.

 =

I like the idea of introducin= g a numbering convention, but that seems to be solution space only.

 <= /span>

I have no suggestion except = perhaps to avoid defining the words, but rather remind CLUE authors that th= ey can be confusing, and should only be used in conjunction with appropriat= e attributes such as "from sending endpoint camera's view".<= /o:p>

 

Speaking as individual, and not = as editor, I'm against any definition that makes assumptions of  "= ;proper rendering".  There is no such thing as proper rendering; = rendering is an implementation issue and I can imagine many cases where a c= amera signal that, from a person located in the room where it is captured, = and facing the screens, would be on the left, should not be rendered on the= right in a Remote room.  (This tries to describe the natural feel of = telepresence with more than one camera/screen).

=

 

Opinions?

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>Stephan

=  

= --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB3DGVW1096EXBame_-- From mark.gorzynski@hp.com Tue May 31 17:08:39 2011 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 D43D1E08EC for ; Tue, 31 May 2011 17:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 d6t07HNbk3Qn for ; Tue, 31 May 2011 17:08:37 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 478E1E08C9 for ; Tue, 31 May 2011 17:08:37 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 50DFE2834F; Wed, 1 Jun 2011 00:08:36 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 1 Jun 2011 00:06:43 +0000 Received: from GVW1096EXB.americas.hpqcorp.net ([16.234.97.240]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Wed, 1 Jun 2011 00:06:42 +0000 From: "Gorzynski, Mark E (The Right One)" To: Stephan Wenger , "clue@ietf.org" Date: Wed, 1 Jun 2011 00:06:41 +0000 Thread-Topic: Definitions: left, right Thread-Index: Acwf6LqQv2BMONG3Qc+myT0Jek1xvwABA+iQAACrsaA= Message-ID: <4168915E16BA9E47972F4A4B4EE3228276B786EB43@GVW1096EXB.americas.hpqcorp.net> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4168915E16BA9E47972F4A4B4EE3228276B786EB43GVW1096EXBame_" MIME-Version: 1.0 Subject: Re: [clue] Definitions: left, right 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 Jun 2011 00:08:39 -0000 --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB43GVW1096EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should be clear that 'camera left' in cinematography and television typ= ically place the cameras in front of the actors. Thus for telepresence the= 'actors' are the attendees (human participants) and the stage is where the= attendees sit. So again, the terms 'camera left' and 'stage left' are available but have t= o be carefully defined. Mark G. From: Gorzynski, Mark E (The Right One) Sent: Tuesday, May 31, 2011 5:03 PM To: 'Stephan Wenger'; clue@ietf.org Subject: RE: Definitions: left, right In television and cinematography, the terms 'camera left' and 'camera right= ' are differentiated carefully from 'stage / house left', 'stage / house ri= ght'. There are many references. For example http://www.safilm.com.au/library/SA= FC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of view.= Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's p= oint of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view acto= rs from the point of view of the local in-room audience. Thus 'stage left'= takes the sense of the actors while 'camera left' takes the sense of the l= ocal audience. We could use either for our use as long as we are clear. A point to notice= is that the receiver and sender will many times have an opposite sense. C= amera left for a receiver will often be stage left for a sender. Regards, Mark G. From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be confusing,because = some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender left" v= iewed from the viewpoint of a person in the sending endpoint room (house le= ft), or from the viewpoint of the guy adjusting the camera (which could eas= ily be stage left; at least that was the case in the TeleSuite rooms)? Als= o, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to be= solution space only. I have no suggestion except perhaps to avoid defining the words, but rather= remind CLUE authors that they can be confusing, and should only be used in= conjunction with appropriate attributes such as "from sending endpoint cam= era's view". Speaking as individual, and not as editor, I'm against any definition that = makes assumptions of "proper rendering". There is no such thing as proper= rendering; rendering is an implementation issue and I can imagine many cas= es where a camera signal that, from a person located in the room where it i= s captured, and facing the screens, would be on the left, should not be ren= dered on the right in a Remote room. (This tries to describe the natural f= eel of telepresence with more than one camera/screen). Opinions? Stephan --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB43GVW1096EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should= be clear that  ‘camera left’ in cinematography and televi= sion typically place the cameras in front of the actors.  Thus for tel= epresence the ‘actors’ are the attendees (human participants) a= nd the stage is where the attendees sit.

 

So a= gain, the terms ‘camera left’ and ‘stage left’ are = available but have to be carefully defined.

 

Mark G.

 

Fr= om: Gorzynski, Mark E (The Right One)
Sent: Tuesday, May 31, = 2011 5:03 PM
To: 'Stephan Wenger'; clue@ietf.org
Subject: RE: Definitions: left, right

 

In television= and cinematography, the terms ‘camera left’ and ‘camera = right’ are differentiated carefully from ‘stage / house left= 217;, ‘stage / house right’.

 

Ther= e are many references.  For example http://www.safilm.com.au/library/SA= FC_FILMMAKERS_HANDBOOK.pdf

 

Camera Left/Ca= mera Right: Directions given from the camera's point of view. Opposite of S= TAGE LEFT and STAGE RIGHT, which are given from the actor's point of view. = May also be called LEFT FRAME and RIGHT FRAME.

 

This makes sense if you observe that cameras in studios typically view ac= tors from the point of view of the local in-room audience.  Thus ̵= 6;stage left’ takes the sense of the actors while ‘camera left&= #8217; takes the sense of the local audience.

 

We could use either for our use as long as we are clear.  A point to = notice is that the receiver and sender will many times have an opposite sen= se.  Camera left for a receiver will often be stage left for a sender.=

 =

Regards,

Mark G.

 

 

 

 

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.o= rg] On Behalf Of Stephan Wenger
Sent: Tuesday, May 31, 201= 1 4:16 PM
To: clue@ietf.org
Subject: [clue] Definitions= : left, right

&n= bsp;

Hi,

 

We did not come to a conclusion how to define "l= eft" or "right".

 

= -Stage/auditorium/house right left have been shown to be confusing,bec= ause some of us are not theatre majors :-)

=

 

-sender/receiver left/right does not make sense either. &= nbsp;Is "sender left" viewed from the viewpoint of a person in th= e sending endpoint room (house left), or from the viewpoint of the guy adju= sting the camera (which could easily be stage left; at least that was the c= ase in the TeleSuite rooms)?  Also, we have senders and receivers that= are not endpoints, i.e. MCUs.

 

I like the idea of introducing a numbering convention, but that se= ems to be solution space only.

 

I have no suggestion except perhaps to avoid defining the words, = but rather remind CLUE authors that they can be confusing, and should only = be used in conjunction with appropriate attributes such as "from sendi= ng endpoint camera's view".

 

Speaking as individual, and not as editor, I'm against any definiti= on that makes assumptions of  "proper rendering".  Ther= e is no such thing as proper rendering; rendering is an implementation issu= e and I can imagine many cases where a camera signal that, from a person lo= cated in the room where it is captured, and facing the screens, would be on= the left, should not be rendered on the right in a Remote room.  (Thi= s tries to describe the natural feel of telepresence with more than one cam= era/screen).

 

Opinions?=

 

Stephan

 

= = --_000_4168915E16BA9E47972F4A4B4EE3228276B786EB43GVW1096EXBame_-- From stewe@stewe.org Tue May 31 17:18:19 2011 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 1FA9EE0772 for ; Tue, 31 May 2011 17:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 KKdsxX0Wr2PR for ; Tue, 31 May 2011 17:18:16 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id ADFDFE06DD for ; Tue, 31 May 2011 17:17:54 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1054-1743317 for multiple; Wed, 01 Jun 2011 02:17:53 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 31 May 2011 17:17:42 -0700 From: Stephan Wenger To: "Gorzynski, Mark E (The Right One)" , "clue@ietf.org" Message-ID: Thread-Topic: Definitions: left, right In-Reply-To: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389707072_42768487" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Definitions: left, right 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 Jun 2011 00:18:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389707072_42768487 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Camera Left seems to be one good choice. Should we go with this for now: "Camera Left, Camera Right: direction from a camera's viewpoint." "Left, Right": to be interpreted only in context, use Camera Left and Camer= a Right when possible". Stephan =20 From: "Gorzynski, Mark E (The Right One)" Date: Wed, 1 Jun 2011 00:03:11 +0000 To: Stephan Wenger , "clue@ietf.org" Subject: RE: Definitions: left, right In television and cinematography, the terms =8Ccamera left=B9 and =8Ccamera right= =B9 are differentiated carefully from =8Cstage / house left=B9, =8Cstage / house right=B9. =20 There are many references. For example http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf =20 Camera Left/Camera Right: Directions given from the camera's point of view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's point of view. May also be called LEFT FRAME and RIGHT FRAME. =20 This makes sense if you observe that cameras in studios typically view actors from the point of view of the local in-room audience. Thus =8Cstage left=B9 takes the sense of the actors while =8Ccamera left=B9 takes the sense of the local audience. =20 We could use either for our use as long as we are clear. A point to notice is that the receiver and sender will many times have an opposite sense. Camera left for a receiver will often be stage left for a sender. =20 Regards, Mark G.=20 =20 =20 =20 =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right =20 Hi, =20 We did not come to a conclusion how to define "left" or "right". =20 -Stage/auditorium/house right left have been shown to be confusing,because some of us are not theatre majors :-) =20 -sender/receiver left/right does not make sense either. Is "sender left" viewed from the viewpoint of a person in the sending endpoint room (house left), or from the viewpoint of the guy adjusting the camera (which could easily be stage left; at least that was the case in the TeleSuite rooms)? Also, we have senders and receivers that are not endpoints, i.e. MCUs. =20 I like the idea of introducing a numbering convention, but that seems to be solution space only. =20 I have no suggestion except perhaps to avoid defining the words, but rather remind CLUE authors that they can be confusing, and should only be used in conjunction with appropriate attributes such as "from sending endpoint camera's view". =20 Speaking as individual, and not as editor, I'm against any definition that makes assumptions of "proper rendering". There is no such thing as proper rendering; rendering is an implementation issue and I can imagine many case= s where a camera signal that, from a person located in the room where it is captured, and facing the screens, would be on the left, should not be rendered on the right in a Remote room. (This tries to describe the natura= l feel of telepresence with more than one camera/screen). =20 Opinions? =20 Stephan =20 --B_3389707072_42768487 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Camera Left seems to be one = good choice.  Should we go with this for now:

= "Camera Left, Camera Right: direction from a camera's viewpoint."
=
"Left, Right": to be interpreted only in context, use Camera = Left and Camera Right when possible".

Stephan
=
 

From: "G= orzynski, Mark E (The Right One)" <mark.gorzynski@hp.com>
Date: Wed, 1 Jun 2011 00:03:11 +0000
To: Stephan Wenger <stewe@stewe.org&= gt;, "clue@ietf.org" <clue@ietf.org>
Subje= ct: RE: Definitions: left, right

In televis= ion and cinematography, the terms ‘camera left’ and ‘camer= a right’ are differentiated carefully from ‘stage / house left&#= 8217;, ‘stage / house right’.

 

There are many references.  For example http://www.safilm.com.au= /library/SAFC_FILMMAKERS_HANDBOOK.pdf

 

Camera Left/Camera Right: Directions given from the camera's poin= t of view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the = actor's point of view. May also be called LEFT FRAME and RIGHT FRAME.

 <= /p>

This makes sense if you observe that = cameras in studios typically view actors from the point of view of the local= in-room audience.  Thus ‘stage left’ takes the sense of th= e actors while ‘camera left’ takes the sense of the local audien= ce.

 

We could use either for our= use as long as we are clear.  A point to notice is that the receiver a= nd sender will many times have an opposite sense.  Camera left for a re= ceiver will often be stage left for a sender.

 

Regards,

Mark G.

 

 

 

=

 

 

 

 

From: clue-bounces@ietf.org= [mailto:clue-bounces@ietf.org] <= b>On Behalf Of Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16= PM
To: clue@ietf.org
Sub= ject: [clue] Definitions: left, right

<= p class=3D"MsoNormal"> 

Hi,=

 

We did not come to a concl= usion how to define "left" or "right".

 

-Stage/auditorium/house right left have been shown to be confusi= ng,because some of us are not theatre majors :-)

=

 

-sender/receiver left/right does not make sense either= .  Is "sender left" viewed from the viewpoint of a person in the sendin= g endpoint room (house left), or from the viewpoint of the guy adjusting the= camera (which could easily be stage left; at least that was the case in the= TeleSuite rooms)?  Also, we have senders and receivers that are not en= dpoints, i.e. MCUs.

I = like the idea of introducing a numbering convention, but that seems to be so= lution space only.

 

I = have no suggestion except perhaps to avoid defining the words, but rather re= mind CLUE authors that they can be confusing, and should only be used in con= junction with appropriate attributes such as "from sending endpoint camera's= view".

&nbs= p;

Speaking as individ= ual, and not as editor, I'm against any definition that makes assumptions of=  "proper rendering".  There is no such thing as proper rendering;= rendering is an implementation issue and I can imagine many cases where a c= amera signal that, from a person located in the room where it is captured, a= nd facing the screens, would be on the left, should not be rendered on the r= ight in a Remote room.  (This tries to describe the natural feel of tel= epresence with more than one camera/screen).

 

Opinions?

 

Stephan

&nb= sp;

--B_3389707072_42768487-- From aravind.sethuraman@teliris.com Tue May 31 19:28:59 2011 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 01A01E07BF for ; Tue, 31 May 2011 19:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 sV5b2F6LXaRX for ; Tue, 31 May 2011 19:28:58 -0700 (PDT) Received: from imta-38.everyone.net (imta-38.everyone.net [216.200.145.38]) by ietfa.amsl.com (Postfix) with ESMTP id 70211E068F for ; Tue, 31 May 2011 19:28:58 -0700 (PDT) Received: from pps.filterd (m0004962 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p512Rcue026892; Tue, 31 May 2011 19:28:57 -0700 X-Eon-Dm: dm0227 Received: by dm0227.mta.everyone.net (EON-AUTHRELAY2 - 457f155b) id dm0227.4de07c4f.51bb8; Tue, 31 May 2011 19:28:57 -0700 X-Eon-Sig: AQLO6zJN5aPpIKXSWQIAAAAC,51e3bbbe0ec6cd4490644c67dd5e5bc9 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: aravind sethuraman In-Reply-To: <4DE57EA5.6060406@cisco.com> Date: Tue, 31 May 2011 22:28:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE57EA5.6060406@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1105310222 Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant ...Left/Right ETC... 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 Jun 2011 02:28:59 -0000 Folks, I apologize if i am repeating anything already discussed or have missed = any point. My 2 cents, 1.I agree with defining participant as per 4353. However, If we define = participant in 4353 sense (to represent an entity), we must also further = define the # of participants(humans in the call) to support possible = offer and answer negotiation between 2 end points. Consider, for = example, an end point (A) with 4 screens and 4 cameras in a telepresence = call and have 4 human participants(for now) with another endpoint B with = 4 camera 4 screen room that has 8 humans. if we do not consider the = number of participants, we will expect a symmetrical 4 pairs of media = sessions between the rooms. However, an optimal approach could be that, = only the 2 middle camera capture from Room A and get rendered on the = middle 2 screens of Room B whilst the capture from 4 cameras in Room B = will be rendered on Room A. And these could perhaps be as part of = re-negotiation or initial invite itself.=20 2. In case of multi-point calls (i have not seen anywhere which says we = do not support this ) say a 3 way, would we would have to consider 2 = separate SIP Invites as dialogs within a Telepresence Call transaction: = or a Single SIP Call transaction?=20 3. LEft Right and Center - does this mean there will be only ONE camera = /screen to handle the Left segment, Center and Right (?). Does this not = limit the end points to be 1,2 or 3 screen only? What about endpoints = that want to send only or receive only?Also how will it be effective in = end-points where # of cameras IS NOT EQUAL TO # of screens. I would propose a publishing of end point capability in terms of # of = screens and # of cameras and also define SEGMENTS (and # of capture = cards and human participants per segment) 4 Again, in case of multi-point calls, how will simple L and Right be = effective? 5. Asymmetrical end point interoperability - as in my previous = example....what if Room B is a 3 screen room with 8 participants. Does = the middle camera capture 4 and the cameras on the side capture 2 = humans?=20 Either we chose to be simple in interoperability and have CLUE worry = ONLY about how to signal and negotiate multiple media lines and leave = the rendering to the end point OR we enter Telepresence (not video = conferencing) and further define such granular elements. Comments/Criticisms are most welcome Regards Aravind Sethuraman On May 31, 2011, at 7:49 PM, Paul Kyzivat wrote: > I support using Participant in the 4353 sense. > (Its really the only definition that most of the software can use in a = useful way. E.g. the conference roster is about these automata. This = becomes especially obvious when you have the same "person" showing up = multiple times in the roster.) >=20 > If there is need to talk about the human(s) associated with a = participant, then it would make sense to define another term for that. >=20 > Thanks, > Paul (as individual) >=20 > On 5/31/2011 7:03 PM, Stephan Wenger wrote: >> Hi all, >> I thought I would quickly rev the definitions doc, and found out that = I >> cannot find agreements on a number of terms. This is the first of a = set >> of eamils that will hopefully lead us to close the definitions on a = few >> terms. >> So this email is about "Participant". >>=20 >> We have the odd definition that RFC 4353 lists participant = essentially >> as a piece of software and not as a human. To Song Haibin, Steve = Botzko >> (and to me), Participants sounds like human, though. >>=20 >> Several ways forward: >>=20 >> 1. Use Participant in the 4353 sense only >> 2. Use Participant in the sense of a human participating in a >> telepresence session only. That would mean that there can be = many >> participants at any endpoint, and endpoint can have no = participant >> (empty room or webcam), and so forth. >> 3. Use Participant in the sense of 2) above, and add remark that if >> 4353 Participant is meant, this will be explicitely mentioned. >>=20 >> My preference is 1. 2 and 3 have too much potential for confusion. = Shame >> on 4353 for that. >>=20 >> Opinions? >>=20 >> Stephan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue Aravind Sethuraman Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C = +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM = aravindsraman