From pkyzivat@alum.mit.edu Wed Jul 3 07:57:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD511E81C3 for ; Wed, 3 Jul 2013 07:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.461 X-Spam-Level: ** X-Spam-Status: No, score=2.461 tagged_above=-999 required=5 tests=[AWL=-2.524, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzI00xnM5kY8 for ; Wed, 3 Jul 2013 07:57:01 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBB11E81B4 for ; Wed, 3 Jul 2013 07:57:00 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id vpnL1l0030QuhwU5Cqx0ks; Wed, 03 Jul 2013 14:57:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id vqwz1l00w3ZTu2S3Nqwz5H; Wed, 03 Jul 2013 14:57:00 +0000 Message-ID: <51D43BBA.30600@alum.mit.edu> Date: Wed, 03 Jul 2013 10:56:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE References: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> In-Reply-To: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> X-Forwarded-Message-Id: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> Content-Type: multipart/mixed; boundary="------------080004020603010106030300" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372863420; bh=BeklrsUrN3PRTnyaz//PjQhLn1jQ7MPvneIlEebghEc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=StfFrjJ/zyUnZ2iNBRGSLR+I/By9br1tIMSqMlWTdKWr2puGbr6Id2PUn2xlGyRYQ +rIraTbnn16+yaFhCOyh2Z+iWi1pQkGeltcI33J+RoFS49YQufOUuelNUyOyVhkT5L gBhQC48cdLfP02Ts1BKcwOAM0uxr4KvP8wfk6YcNbdAtJDafV/RCriPAMRND2RpxSn PFqzLcDq4dlLhb9+2l7b1xpUAs+2GRvRny7wfAMaZIrIcGfrylEg5nV3Kq8qBgZEKH ZnRWc8r0ghz5px1geuMeVlN9FfY8j3jZGydMm/2vb1wdPvodli4LjVy6YU6qyFeLnj Nx8i84rS2F7BA== Subject: [clue] Signalling work on Telepresence in ITU-T X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 14:57:06 -0000 This is a multi-part message in MIME format. --------------080004020603010106030300 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit I think maybe ITU has gotten tired waiting for us! Another reason to start making progress on signaling. Thanks, Paul -------- Original Message -------- Subject: Signalling work on Telepresence in ITU-T Date: Wed, 3 Jul 2013 03:38:10 +0000 From: Xiaojing (Lennard) To: Paul Kyzivat CC: Yangweiwei (Tommy) , Liuyan (Scarlett) Hi Paul, In the last ITU-T SG16 WP1 rapporteur meeting, a proposal to start the work on TP signalling was agreed. The original proposal can be found in the attachment. The agreement and support of this proposal was made during the meeting. The conclusion from the sumary report was: Contributions on signalling topics are solicited. Experts noted that some useful topics might be proposals for a signalling framework, RTP usage, protocol usage, potential signalling channels, and analysis of approaches to integration the CLUE advertisement/configure methodology with H.323 capability exchange and negotiation. Experts felt that the 28 October – 08 November 2013 in Geneva, Switzerland meeting would be a suitable time to launch new work items in this area. Thank you. Best regards, Lennard ------------------------------------------------------------------------ 肖晶Lennard Xiao 华为技术有限公司Huawei Technologies Co., Ltd. Company_logo Phone: 0755-36830241 Fax: 0755-36830194 Mobile: 13607111771 Email: lennard.xiao@huawei.com 地址：南山区科技园南区粤兴三道6号南京大学深圳产学研基地3楼邮编：518057 3rd Floor, Nanjing University Research Center Shenzhen Branch, NO.6 Yuexing 3rd Road, High Tech Park South, Nanshan http://www.huawei.com ------------------------------------------------------------------------ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或 群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发） 本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --------------080004020603010106030300 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="AVD-4458.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AVD-4458.docx" UEsDBBQAAgAIABwg0UKW4EeIpQEAAK4IAAATABEAW0NvbnRlbnRfVHlwZXNdLnhtbFVUDQAH 7om+Ue6JvlHuib5RtZbLTsMwEEX3SPxD5C1q3LJACDVlwWMJSIDE1rUnrYVfsqdA/55JUgKC 0hTabCJFyZx75+VkfP5mTfYCMWnvCjbKhywDJ73Sblawx4frwSnLEgqnhPEOCraExM4nhwfj h2WAlFG0SwWbI4YzzpOcgxUp9wEcPSl9tALpNs54EPJZzIAfD4cnXHqH4HCAFYNNxrdkIGoF 2Z2IeCMs6fBXHxUvvUfnEVJOOJZdNHGVdMFECEZLgWScvzj1TXTgy1JLUF4uLIXkFS5ELyEl Ss2avEUfVWi+3oRcJPT2yRquEexd9CGNdrbSQiseRNSfHi6hFAuD2dUbwZuWRDDpb3KrUucU Wb+T5jpsUticz4bq1C1q09p7h9onVmh31OXDLewUIkXu30iL7jSRcGn6GNaG2ykPTvW0LR/k TRYout4QTlo7O4BqPhWoQfixJL9XHxDJbh/1X5G3Sr/Z7z0dE3/JvzrSII76OSshduojnf7Q XHc3UWO2SJnoYmqgj6RX6E4TrzC97230vsA7jcxBqF4GoAFvN/0+/qMZH9+sKnrNyPP6b2Py DlBLAwQUAAIACAAcINFCmVV+BfgAAADhAgAACwARAF9yZWxzLy5yZWxzVVQNAAfuib5R7om+ Ue6JvlGtkk1LAzEQhu+C/yHMvTvbKiLS3V5E6E1k/QFDMvuBmw+Sqbb/3iiKLtS1hx4zeefJ M0PWm70d1SvHNHhXwbIoQbHT3gyuq+C5eVjcgkpCztDoHVdw4ASb+vJi/cQjSW5K/RCSyhSX KuhFwh1i0j1bSoUP7PJN66MlycfYYSD9Qh3jqixvMP5mQD1hqq2pIG7NFajmEPgUtm/bQfO9 1zvLTo48gbwXdobNIsTcH2XI06iGYsdSgfH6MZcTUghFRgMeN1qdbvT3tGhZyJAQah953ucj MSe0POeKpokfmzcfDZqv8pzN9Tlt9C6Jt/+s5zPzrYSTj1m/A1BLAwQUAAIACAAcINFCLc// hUQBAABOBgAAHAARAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNVVA0AB+6JvlHuib5R 7om+Ua2VS0/DMBCE70j8h8h34rRAeahJLwipVwgSVyfePERsR/YG6L9n1UKa0srqwcedyDOf xitnufpWXfQJ1rVGp2wWJywCXRrZ6jplb/nz1T2LHAotRWc0pGwDjq2yy4vlC3QC6ZBr2t5F 5KJdyhrE/pFzVzaghItND5q+VMYqgTTamvei/BA18HmSLLiderDswDNay5TZtaT8fNPDOd6m qtoSnkw5KNB4IoI3ICRYchS2BiTP7TyLyYjx0/nXIfMdbjoqcMzfzb74u5DxoKU2OAX4U3wI 85AIelAFWNquPcMo+SBmISHKwaFR75Q2QsTxXuUtgvIuxSIkTWUM/ruWUfJWErQTpLOwJ9iO O9HbxG1Ihi8oXgGRVmHSxUT0tpGEvRONuSg6mN7Jr+SjuAn6Whx14c4o4iH0bk4fzN08bgQ/ +AtkP1BLAwQUAAIACAAcINFC1i34l5oRAAAoggAAEQARAHdvcmQvZG9jdW1lbnQueG1sVVQN AAfuib5R7om+Ue6JvlHtXVmT4sgRfneE/4OCJzuiD3QgYMKDg6tn256eZhvaG7bDsSFEAfII lVwluod52r+xf8+/xFmlkhCgo4SA3lnvPEyDjqrMrDy+zDr405+/rFzlBRHqYO99Tb2p1xTk 2XjmeIv3tefJ3XWrptDA8maWiz30vrZBtPbnzu9/96fXdzNsr1fICxRowqPvXuDuMgj8d7e3 1F6ilUVvsI88uDnHZGUF8JUsblcW+bz2r2288q3AmTquE2xutXrdrIlm8PvamnjvRBPXK8cm mOJ5wF55h+dzx0biT/QGkek3fGUgSOY93hLkAg3Yo0vHp1Frq2Nbg5vLqJGXPCZeVm703Ksv 09uMWK8wHis37OgVk5lPsI0ohauD8GbcolqXECBrIn5DhoTdPiNKVpbjxc14h+Mf930DfQuh 8aa2jIAsOqBLUzzbsL/B1BV/RkR8+EF5ZTS225peg4/BxoeOZl+s2q144KO1wesgvjV3vqBZ fLOPXPfB4m25aB6EbTWaKS0RZ7HMvn+73xrrGOPP8NyL5b6v1eHf9rmY+A/EmbGPC/jbx27Y vGqqzbDPnct6Xa+nXNbUtKuqYaRd1k3N3JIR9R4QuAsmPntihJrDRq9v1KJLI8IudlXjrmdG Fyf8WrOr1s1GLWwhZMm2vGDsg9GKPsTlwA7/j76JMTO1dpqkGcVj3/Ii2Rnh5Zeu6yziizYY FiIRL6JlvyQfTwM0t9ZucPj4aI9BP+yA+pYNCg4PTRHoP1AtpCwYnfIvdGW5bt/yafjta0Sz 2q6JK326e+1WtHAb9zQF5WHOcBxYhKmdM2N9wQfPWjFh0QX7YmP3ziEUGFDF149W+I13BCaJ 50NCYhlTHzSUNynITpWONENavYgh6LjzZPk+JgFaEz5W4c1s8obe7HLEMe/ERxV69wmiiLyg Wkd5QChg44znyvdrRHkUUPaoJ5egRL1StKuDni8xavqV0ngLjhUAE4qmvgXLt6q50y2zRuFf crwY96mHXuzM7mrYbrS76o67Epdk3NW/7YgwHtZSfNi0vy9Doy7vqdStp/rxA+5Z9uewi+hZ sPH4yTRbb9T1pjGsSVMF0dvifCJwf13qWO9rX5fX/U/7I9z92+A6R6nJHfYCpiBLxwMpR40J 2k9CgWE0WtlKxmNmuqBEL+eJ1ezqd0ggnJArU61JBXGj1ZAJ4rqwigdEFihWPnCtcSwK7B4A Pkg1Qv6DAK+i5zzHjU0nfuiScb9ACWNQtWcakl6rqEGmLZPhx2H/8eHh+dN9vzu5f/x0nIMs 7mpKwtHojCfdT4Pu0+D+H7w/ZTzsTx6fUnT3cvLPd+9HyD+riZD/58HfldHw6f5xoGj1HLeR 14qqlx2ovNautbp6JCHHhLZG3TQlbFv75RvwKQNeWVPLUFpdS9e4D0+PzyMlD4rEUeJSwUBv NM4XDIp0h1UUXMRapV8BL2j8U4ga6yLpwcCWtQ7wNxgkLmyI34wwjzFYrXXqMNzaN9FHoMbx LPedMgRBOnT5i7LSppyV8gJTWgXrDS2l4qglxyjK2P9A//jumHyO1dnOJJ3WwBwM7rKkI52K yKUajePy2YbWNGV9+CWVhpWDfyCWH5dUi1PZZLqvGRnOIU3oW8k+WO5i7SkfcLB07MMigmZk jMhnfP3XpwPvQV1cFg6emab0IsyVIpMln0lKavObkJFy/ZZCKl8hexshvaGI/rL20LchpPys 7txy0r9FDJMx37cfpRqXjlLbcLQt+Z4b8Dx1R6PHp8nw+Ul5GA4n958+KIPH/vPD8NPkN3j6 i4OnY7wmNjoGmbb0uik7X3oRee3JwOgBdrwLVaLzj8lQ6WPiY8IXUfymiJWmm605+BKWsEc1 qapaOHEC91tRwkHDGAzNHVn1WoamdUvKqmR6xflA3vXzuFacbI0I9jHNght7JJ+LCDRTAqzw OZU8SkQWekZKJMHghcUTLFE5sZyOc0heP78t9xmE7XnmC4pkr9+0aWRtO438+HH448f7T3/V dyeSk0/rh09Hs8vn1KoJchFny7ORQjc0QKv8rEPvq23jTEKlzsKz3Jxk4hgOnQvw0/EWGQqx nQLXshYRRLWobxZU/Dpq9meEK6M1IEl6dsDy6x6HffvMscjjUZMUTtpzUWmmexuv9s2T16Fo DvM4eW5T1zO0errZukut5u/cGaUT4Y+DjRuveBEByVuvwruO++LuFbTh3v1s59pt4oXAmlLx Ny40uMgijAoQ7Ptasx1p8vYJtrQ5fqBhxp5KtOVwR8oeAjPQuV4vQWZ8jb+ha0erTlqQNrZB +t6DqBV8xAuc5deN48J3gQqO1yvoZlO8kmV3tqZgHicBlY5Vv3SJNQ5hTSMbBJmHT5upS+z6 XU3tDWtHi/bf1vVfRgdYaOlQxYZmiDNds7Rf8bm9o2JEUtAyzccg5+CmfEW7QrOQt+UB8aFh NNsV+Es1hJlD7TWlfMVtatJ4GtYUS/HQK0+BFAfQMeQcZ+D1XJg9QdFbw/h8IZ0U2Z+X60Ow L8fbSez17GbleMr95Pl6ciZr+p7N698UJkuNrKBqbpOl08a7akhHNc8PdfZQbdC5h0iFZ2s7 o0K9Jx+jZzTVbpp8mu2GZu6uxheXTjjy/TUhyAvcTa5Ka5qh3rVPrNKp+pzR67niZocrvrK0 qBIsCULbgEIlKNv1YkeQW45bCHEE/WftEMR2gF5dfsQsYi9BNnawJqjiwAE8uDT5WZSsZw6+ fXFmCFfkybcIYGRIji8+MLnK2q+rg3azVip7yKntzpWSQOeQ45NhmqvqDuB16dhLxSJI8fCr MkU2XrEyxwrDlZXFNP0mj7k99x3NWfKLx3qC4td7bO8xyD5wXBec1wt8xCtGr8OTo6kL/iu3 i/aw2TWHeV14CM0qUgnpx5RR5r7INVVWiGuyKA5dxZyCzHhBrTq37IQBFxxARYKCJZKlpZSq g+deeo5tuYrD6GRBxAJVqca2OKmBzAqno4oZV2Aovj9YYZpDUuemGGDtwiihXHsXE6hrVxf3 UdfxVZhotaaHFAey4yk7PqBg7lBCYFKbn9P2Zu+3D8qxdepHbqk+jua9osudqav1fl4DtuVb 4SEeqd4/058tcODwZSMlKOik4JQ83pjpYviP7AyysgLlcsDkvigBsTwqO+gdtsW9TPcQnHl3 aOZYYJgEWSsqYSLttt7SWpI5yElqkuXjdJdylD5FyINIHUBE4bEOvTh4TYFjvrdeVrKler5S 8MEpA6fKu8N0Q3g9zqClzJCPvBnY4YYVtdh4Rk+xz/fDyZ3S//g8VH74kItM2r1ms9U6VcHj E369Yv0DKoqHYbUG5ATOYQGPUUbfljYgfM7AMKP8SlSeXIarWFnwaTICqOL7Tn7F5sjxymBg Rqx5QC8msBvlBwRSch0E4CxYWgEklf/96WdIMx0AanNMFNDalPrsaXqPirAXEy/TTBsT+O5j jx3klBxzfojPDJA05ZpMOfvf3eiarkwtCpacklAwdTqPbHjZQTmDIrBaQuV0ZL8K9/9ZUzvn pHJS2oPQTqQKdXtCF2dKdButQT9tJDRDu2trcpFzWm2SfFqiUqBJrMxKZTGD3GwHqObnMLre GjRq52Cxf3oWO1vImcCR5zPUPMFOwNXGHjVCfDmYOElP/a7ebYoVSDuI2PHKolwXLSx7k9uZ agwHRm4qkAgCZfrnxTo2JTwHPJKIGRw/uYB6ZxtAUXPHC1Hidzea0bhRJjHVCuArH4OayYaB DEJWmKaVH3LeYBRiD1Xt18qIjpkZ0woRi2Mv1jm1CcA3gGUYQIm0vmSkVezAPtdlUNVlxoHC LnhRNe6Q0xsOWpiUKGFpaIaAFGcK74RHCYnLPEdiqc8VbyGVUS5JD9qzkYeqsSAjgV1/sWNG yAvI5sQUhC3zsyJBOKDoNvKDm/y0tXGnan1VvpvTOywX/PITS10Imo2sBerBUH++LShjirQm T4B6V9dMUXrvTNJllYIgw2zFyp+qSLadVdbHgBCm7qaMh6IA+4nlCjsQmXi4JkLcSZoDVaqR OCdsQSEvZJcgckHw2gf14qVjbkfysYMpvYNoGZEw3xDuJQATj2IPN/3glWWTp9SAyL/TinYJ ecpD/7kElzcVR3KMlSV+ZUKKfCNXmlhcZcYX9J+iglrXsF/vaiJGbwtr0kMBKsCTOYkZoVxr WeK1yzRBXglEhgv6w+QDHhKeYn4nXTdyCyVm3ew36mdznILsI5AeL6dI7qTImt5nxZgkLOJL skIzjIoERe43iUc627S+GmEJCOt4trvmNYM9JJsEqGGhAD6M70c3FeGT0qXKrv6EBUUBQvIn 1ocDvdnWyxcHwrLD+INqRuoOfIutjGhb5RN4XhT4JAnJ4vOqotpDbJ5bdlCRimpEMGk4Xngu NFMEthDUipB9keqK5vfmfu4MfWAKfY6rlMmEYVvHZKbjWmSBANzymqc1wz7XlU1Ys+U1PfY+ 01++EPG7m8lofN39WzW2r5QpgCMRC9aUawj8Hy8xoGyCIZz/5aCbz1dvJ/gIm8deQRgMDxu/ UcZYqTaM6eXLg9WeIZrYWZrJH1zCE26Rf9da9cjPcHYrKp5D6RrRin4qnMQpXVJIBtbS01hZ JHZSPSJPovOaaBqNYSs/MyhexbFDh0SNcs/0knsqdu6Ur4zJV+cGfbVh6r/q6pxgsXR1Tnur 6tzDpViMp1zLTYJItZ0MSKfnp1NmkjijiYOZ44vVJ8cOSwLYHF9u8lXX+oYWpRGUhbgZiytl 0oZwmltiy28zZRNvzp7fVsrjRuH6iahoJct1uR3M26XWzaw12K0UEos7dDzpoJzewBQHS6Ua 02EZWBobFKwdlRAyJBEifpZOVq/Ywjvb8gT4IkiAs8Qaj4qrvyJFKpPrQzYVYBu78kKME6Ay FifdugDRZdpmeLtivgKwNFx8c5g5CdyiiJWTDDPnBsCmbvSauZ0FuAx3UYVCqdarSAhy0V4y vcFkYXnOV1SRVwbvuV7OUziosJIxSWt6C2lxJG9mRMoIiznOC/DCftZElCxyAUDbVJsF0Duz oiJVPqEVbUZiLUZFZyuzqHPHefy2AuKMe+X7x/1URbIJzAp2B4smYsugVZLDYUsbNJu729+3 SnxiWdyX2pya2sR/f/r52N/+qLALg0ZboLdnM+X7WR0Ea5beAtLZ32SbHvPOvUNHZjXbsRym +O9LsFRZ7/KjxrnJ31l/klulM7VGz8iauNtxCZrZ6Oq1rNnc6pXswhiUpOCY2b36oD5s5BYT +dKdcDYZ8UI2KliC0uibmiE466ysTbXuxUwLqlgRlSy658khOb7SRUe7eBGWVGV2YBjN7klm LFgmmsj7kqBxm8XFdVpeGUdfHMrmD6KEjSqUraK2aLi9m61V0hrKbbhmqeJwM+q2UxnVhmyF KLUWiIbLqErPuXTvmt1u7q4OZgsguhd53ergdQAOECxJ2oTYvFtFT2KzUeQLLpgdzLHrYvZb qLLBCVLjos3FOzy+q4KFUyrticZTsbA110qiYW3vOKGDLU/jglNW7nSzHoWItEXj32R8PlgV YZd2VEnBpJMpN4M07MGgdy+xlzo5PZW2cq8Uyx30xWYnRqEqFiC8ZJls8DcLOJ0FrC6tlx02 JXAGS1OYKnrI/WXYmWITdBz4keBUYrtgy9B7g4MJb9MYpO6o3X18lLh08mP1ej0NYLwkEeLh TEfQZ/uZ+CkuY8TWXQSYbPe8HrsB+JhDjLd0Zrz+z2GBs02cIHjmUxdzaO/8S+I0nKF+p6Xu p9F7qr63E7XeatS7ZtEPJRx44x/3/6WSRWHoRySbtjHc53Q1DVXg8CWyZog8oWhXQnw8aMhF TSF8no7cz8RU3RzjIO2FOfv57cTj4ie+/cX4qzjvVW3XeZFsyaqRrejXYv3Fg8V3aWOf/Vp7 eCYs/wUj9orOj0kMjx/d3g5PaIzuhiy8rzU1DhtDAuOvi3XAv4ruePoSH1fajM4DDdgp8KMF /zzDNvtBeNYPIPWRE9hL9iOFUQE1FDL/OMWzDf8Ar6zZ0QSd/wFQSwMEFAACAAgAHCDRQhqO Hp+6BQAAGicAABAAEQB3b3JkL2Zvb3RlcjEueG1sVVQNAAfuib5R7om+Ue6JvlHtWltv2zYU fh+w/0DotbVlOfElRuMuc5KuQDsEjYtue6MkKuZCkQJJ23F+/Q6pi2+yLTtOtnYxgtgiz/nO lYc8kt69f4gZmhCpqODnjldvOIjwQISU3507X4fXta6DlMY8xExwcu7MiHLe93/+6d20F2mJ gJur3gQmRlonPddVwYjEWNVFQjhMRkLGWMOlvHNjLO/HSS0QcYI19SmjeuY2G422k8GIc2cs eS+DqMU0kEKJSBuWnogiGpDsK+eQVeSmLJciGMeEayvRlYSBDoKrEU1UjhYfigaToxxkss2I ScxyumlSRVoo8RRCEbNU0FTIMJEiIErB6GU6WSB6jQoONBAFRxUVlmXmmsSY8gKGr8e/kF0H 2ZnTLNTcEPBFH9JI+yz7upHZj29oanQ7O2ueOPBTzxIQED5gxzUEfwcwNsHs3AkgAkSmo8D2 Cc/EWBcMEX0gYTE5IIx9xlYCI5FOJbQ6JfiS3o02z7uraEawEPe5Tg34zOkKkz5IGpqfd/A9 ECyF99peJ5W5NHzSOj0pGT7ttE/myDkgLEJQWdHwi5F92fW8i66TD91IM3jSOfVa1/ngcHEs RUi1DDDXtwmsytRl8jeSOcLa1Wycbna/O0fRQfo/v/q2YOq6r3XwK2QClB97IZIc2qQaI4ZB PQJz0/5KcAC8DfM7EEyAHXisRS5/juTO5Sc7ndO4bLc67WLwkkR4zPQ6+Y0Zumh3up2O9VqS Csis9q01/kDZb/VYeK2ZqWfp3ILNh4wx9fBWY2lcTENIdyOK49j4JxBc40CnTioj9hor1BAL L/PMNZUKLMgvP+H0Kk3uUuv3tgQ8bBZ/HpNEEkXkhDj9Qap4D9kopAyp4VlctuSIzfvvLEe8 0/bgrFqO7M6KRWp5DZ5UwDGiHEQRCOKFoplLVqGgpmF+B2M52bnzOKoNfl8JWf8TNWTf4N9S eBbSYpcPKtgD2SPdp0HvZfyigX8Nr35Qy27qX+poAFz4gJVlt47vvvpmi+2glXV4yDcUuiFh K0Vuef1uAcR+WRIdoFn/zaZkP3r6ddu1Zqu2r7htiK1mt+OdtTvHw7SLc2PArvHD/y9gxsnH DFoXPscPWP8K2gnWO0JwRlDgJKP8Hkl7TJIfQ3sMGlGlhZyZY9B65Z6Xldzpt3rGSC4RR9nR 6Tl25ClQ1ZnZlr3m1p1r6aCxOV2ervnOyod+edTEtHX1gK/uRYX/V3Ym2yC8tis/Urvieesd SIUGpBSquQ7V3APriodFD7Vhwmu89j8v0/884ZSWSCGiKykLH6iEMGYzpWL0tu1df1AsZuut T7lQyJyKIo9cXI+5W/95tWVLfY7tbE+bXqYle+6m+rXnfO05f7Ce87g17U23jV64EPWbrZfq tF6gjr+2yq+t8taApf0zep4GulmxgT6sN93mwhmpP5Qf2v793rhfrQs+TNUnlpvy1rukKdrY R3lZsV1u15c784rtunkIevWw7Sms1+hufwxbRrDyHNZdllR6j+CwWwEbnkKbR7O3CeY55Mk+ x5vTHaebwjsH8fpCaxEfyi0Xb6Psx+yu2h8c64l7UAS57JhXIS8Xj3nLMzcrCZud3oyZ1J40 fBIJaS12S5eo1610/lsQseNWwzKgWdcX2twSoYL3tu8o6zK2oG6oJEMo9Qj+uNAIo2TsMxrY d2VQjEOC8AS2GuxDIdUC6RHJKN4if6zRvtpV9wAsNGrWLMcMfRx+rQ1R/grO83vECOYhCZHg bIYgGdBYEeTPrPmfSewTiW411kQhERnt3prJVMtbEsC+mVEphKHCXiglAmrI39prQKESgbgE aOmEmPetoshOwfoCXwuJAQOCwjNagEb2DSbQaSrkfR191EiNMGM2aj5ZD1UqCvQOQTdzMUMC wCSCnUoJDppLZFJMU7BiSvXIvEljwyspTE0lNSkICnEFZJmdtWF9577jFm/4/OeXbKF+BIr/ A1BLAwQUAAIACAAcINFClxMtVkUCAAARBwAAEAARAHdvcmQvaGVhZGVyMS54bWxVVA0AB+6J vlHuib5R7om+Ua1Vy47aMBTdV+o/RF5WCnkQXtGEUQbCrKZFlHbVjSdxiNXEtmwDQ7++dl4F QZho1BXEJ+fhcy/i4fGtyI0D4gJTEgBnYAMDkZgmmOwC8GO7MqfAEBKSBOaUoACckACP88+f Ho5+lnBDsYnwDwrIpGS+ZYk4QwUUA8oQUWBKeQGleuQ7q4D8956ZMS0YlPgV51ieLNe2x6CW oQHYc+LXEmaBY04FTaWm+DRNcYzqj4bB+/hWlCWN9wUisnS0OMpVBkpEhplo1IqPqikwa0QO 9y5xKPLmvSPr45ZweFSjKPLK6Eh5wjiNkRDqdFmBraJj9yhQS7SMPhEuPZskBcSklSHX82+9 B8q7Lq2U+ncR1cVcrREzjr5av2QTANseTjxntALN0ZrfOFyiFO5zeY2sz45K5TUvP77LU47U OweYBwBOgKVPeQXmkOwaiEnzaaNRq4atVoPfTKQRqUvwBYOxKoFxJBA/IDA3Dc2WldaFguav pvZwGJb8NE8WGdRo/W17YkrpFe1UwVYHf2Y77tgt+ZgIybforSOHsQ6fI8P49cV4iTbP0erb 5iXcltla4oczCsQghxJ1xnQ9dzWrYtZ1E7rmlKZnHeuS3J5d3RHpiIhIcjPd1Rj7rEPnsA3z 4gJ6ba42ezJ2IzvqvdnjaPS08C4225kOw9Hk/c3W8XB5DZhKpHxcz35n59UTgkKGAsMA/MnM xdeOn8GZCl9RIoViZpioyA2/cqot7ojqvsKfS/Pe6KPZaBY64P+aet5oemNcVvmHNv8LUEsD BBQAAgAIABwg0UJY6Kqb1wAAAPMBAAAbABEAd29yZC9fcmVscy9mb290ZXIxLnhtbC5yZWxz VVQNAAfuib5R7om+Ue6JvlHN0bFOAzEMBuAdiXeIvJNcOyBUNVcGQOrAgsoDWInvLmpin5KA 7nh6siBRqQMjo2X78y95f1hSVJ+USxC2sNEdKGInPvBo4f30cvcAqlRkj1GYLKxU4NDf3uzf KGJtS2UKc1FN4WJhqnXeGVPcRAmLlpm4dQbJCWsr82hmdGccyWy77t7k3wb0F6Y6egv56Leg TutMf7FlGIKjJ3EfibheOWGmJuUY+NxQzCNVCwlDrLJbSS8BZUUeH78qaSdJO/4ZexXfEjwv lTJjBHM96uZ/RjUXr+q/AVBLAwQUAAIACAAcINFC2UpEQFsBAAC5AwAAEgARAHdvcmQvZm9v dG5vdGVzLnhtbFVUDQAH7om+Ue6JvlHuib5RpZJNboMwEIX3lXoH5D2BVEqbokA2UQ/QnwO4 xgSreMayDTS370CApm0UoXQzlmc833see7P91FXQSOsUQsqWi5gFEgTmCvYpe3t9CtcscJ5D zisEmbKDdGyb3d5s2qRA9IBeuoAY4JKGyqX3JokiJ0qpuVugkUDFAq3mnrZ2H2luP2oTCtSG e/WuKuUP0V0c37MBgymrLSQDItRKWHRY+K4lwaJQQg7L2GHn6B5bdihqLcH3ipGVFXlAcKUy bqTpa2lULEdIc+kSja7Gc62Zo5Zb3tKD6Ooo1KLNjUUhnaPs7liciMt4xgA7xNQxx8JPzdGJ 5gomDPx9/0l7QdrD0HrU90VoFtnJZwraxB8MkZw03HKPllFK5SkLl/1BQ1v6rflzyuJ4tXp4 XK3ZmNrJgteVP6l0HbYLEy7KNlGfo2j6OEqftSEQvIK6/yYvvy3F/3F0lnzJ3cnGZV9QSwME FAACAAgAHCDRQurxyJ5bAQAAswMAABEAEQB3b3JkL2VuZG5vdGVzLnhtbFVUDQAH7om+Ue6J vlHuib5RpZJLboMwEIb3lXoH5D2BVEqbokA2UQ/QxwFcY4JVPGPZBprbdyBA+ogilG4MnvF8 /+/xbLafugoaaZ1CSNlyEbNAgsBcwT5lb69P4ZoFznPIeYUgU3aQjm2z25tNm0jIAb10ASHA JQ1lS+9NEkVOlFJzt0AjgZIFWs09be0+0tx+1CYUqA336l1Vyh+iuzi+ZwMGU1ZbSAZEqJWw 6LDwXUmCRaGEHD5jhZ2jeyzZoai1BN8rRlZW5AHBlcq4kaavpVGyHCHNpUs0uhrPtWaOWm55 S++hq6NQizY3FoV0jqK7Y3IiLuMZDewQU8UcCz81RyeaK5gw8Pf9J+0FaQ9N61Gni1AvstMs BW3iD4ZAThpuuUfLKKTylIXL/pyhLc1q/pyyOF6tHh5XazaGdrLgdeW/ZboK2y0TLso2UR+j 1fTroHzOhEDwCup+Rl5+G4r/4+cs+YK307/LvgBQSwMEFAACAAgAHCDRQpa1reK6BQAAUBsA ABUAEQB3b3JkL3RoZW1lL3RoZW1lMS54bWxVVA0AB+6JvlHuib5R7om+Ue1ZTY/TRhi+V+p/ GPkOjhM7ZFdk0SablBYWVruBiuPEnthDxh5rZrJLbhUcK1WqSqseitRbD1VbJJB6ob9mW6qW SvyFvv5IMt5MIAuLSgU5JJ7x835/+B3n4qU7MUOHREjKk7blnK9ZiCQ+D2gStq0bg/65loWk wkmAGU9I25oSaV3a+vCDi3hTRSQmCOgTuYnbVqRUumnb0odtLM/zlCRwb8RFjBUsRWgHAh8B 35jZ9VqtaceYJhZKcAxsr49G1CdokLG0tmbMewy+EiWzDZ+JAz+XqFPk2GDsZD9yKrtMoEPM 2hbICfjRgNxRFmJYKrjRtmr5x7K3LtpzIqZW0Gp0/fxT0pUEwbie04lwOCd0+u7GhZ05/3rB fxnX6/W6PWfOLwdg3wdLnSWs2285nRlPDVRcLvPu1ryaW8Vr/BtL+I1Op+NtVPCNBd5dwrdq TXe7XsG7C7y3rH9nu9ttVvDeAt9cwvcvbDTdKj4HRYwm4yV0Fs95ZOaQEWeXjfAWwFuzBFig bC27CvpErcq1GN/mog+APLhY0QSpaUpG2AdcF8dDQXEmAG8SrN0ptny5tJXJQtIXNFVt65MU Q0UsIM+f/PT8ySN0fPfx8d1fj+/dO777i4HqMk5CnerZD1/+8+Az9Pej75/d/9qMlzr+j58/ //23r8xApQOffvPwz8cPn377xV8/3jfAtwUe6vABjYlE18gR2ucxGGYQQIbidBSDCFOdYjsJ JU5wRmNA91RUQV+bYoYNuA6pevCmgBZgAn40uV1R+CASE0UNwCtRXAHucs46XBhtupLJ0r0w SUKzcDHRcfsYH5pkd0/EtzdJIZepiWU3IhU19xiEHIckIQpl9/iYEAPZLUorft2lvuCSjxS6 RVEHU6NLBnSozESXaQxxmWJzvCu+2b2JOpyZ2O+QwyoSqgIzE0vCKm78CE8Ujo0a45jpyKtY RSYlD6bCrzhcKoh0SBhHvYBIaaK5LqYVda9g6EXGsO+yaVxFCkXHJuRVzLmO3OHjboTj1Kgz TSId+7EcQ4pitMeVUQlerZBsDXHAycpw36REna62b9AwMidIdmciyr5d6cAxTV7UjhmFfnzW 7Rga4NPvHvyPGvE2PJPYGu13Fe5k0+1yEdC3v+fu4EmyRyDN37fc9y33XWy5q+p53Ua76K22 PhTn/OKVE/KIMnagpoxclXlXlqB00IfNfJETzQfyNILLUlwFFwqcXyPB1adURQcRTkGMk0sI Zck6lCjlEo4B1kre+VmSgvH5njc7AAIaq10eFNsN/WA4Z5OvQqkLamQM1hXWuPB6wpwCuKY0 xzNL814ozda8CdWAcHbsd5r1QjRkDGYkyPxeMJiF5cxDJCMckDJGjtEQp7Gm21ov95ombaPx etLWCZIuzl0hzjuDKNWWomQvlyNLqit0BFp5dc9CPk7b1giGKLiMU+AnswaEWZi0LV+Vpry0 mE8abE5Lp7bS4IqIVEi1g2VUUOW3Zu9NkoX+dc/N/HA2BtivqkWj5fyHWtgnQ0tGI+KrFTuL ZXmPTxQRB1FwhIZsIvYx6O0W2RVQCc+M+mwhoELdMvGqlV9Wwcn3M2V1YJZGuOxJLS32BTy/ nuuQrzT17BW6v6IpjTM0xXt3TckyF8bWRpCfpWAMEBhlOdq2uFARhy6URtTvCxgcclmgF4Ky yFRCLHvbnOlKDhd9q+BRNLkwUvs0RIJCp1ORIGRPlXa+hJlT15+vM0Zln5mrK9Pid0gOCRtk 1dvM7LdQNOsmpSNy3Mmg2abqGob9t3jycWuvMh4sBLmnmUVcrelrj4KN11PhlI/autniurf2 ozaFwwfKvqBxU+GzxXw74PsQfTSfKBEk4rlWWX7zzSHo3NKMy1i92TFqEYJW7c0Pn5qzGyuc Xau9GWd7Bl97L3a1vVyitnaQyVdL/zrx4W2QvQMHpQlTsniRdAeOmt3Z/wXAx16Qbv0LUEsD BBQAAgAIABwg0ULFlCbQFA0AANo5AAARABEAd29yZC9zZXR0aW5ncy54bWxVVA0AB+6JvlHu ib5R7om+UaVbWW8jxxF+D5D/sOBzZPV9CJaNPm0ntmNYdgzkbUSOVoRJDjEcrSz/+tTwWO3a XydOsi8r9jddU11XV1VPf/r5L9vNm3f9eFgPu9sF/4Qt3vS75bBa797eLn78oV65xZvD1O1W 3WbY9beLl/6w+PyzP//p0+ebQz9N9NjhDZHYHW6G28XTuLs5LB/7bXe42q6X43AYHqar5bC9 GR4e1sv+/N/iPGO8XTxO0/7m+vo86ZNh3+8IexjGbTfRz/Ht9WlKHpZP2343XQvGzPXYb7qJ GD48rveHC7Xt/0qNwMcLkXf/bhHvtpvLc8+c/YHlPg/j6v2MP8LePGE/Dsv+cCDJbjcXBte7 C5nD5o/QOUFfr+/Hbnz5gMhnpLZfh2H75vlm349LEgHpnLHF9Qyshm+HKa8P+0338l33to/D E6l9XPeHI7wf17upjt1ylny3SY/d/Hc//rReTY/HJ/rtfb+6ezlM/bYOu+k07Z6WROaVZ+J3 T+M4E/2y72isCddhmM7w/LZ3/U/jera0u+ll0xPr3X7/bbclY/zm7qejhJ9vNt1sr6v+Kpf5 57t+txrGr/Ltws8/V5vNPy4mrrmYh0hAy5+PBG8X5/X/d+/aT1fx+4/fxX//Lvnbd/HFWZjD 8HA3ddP8jsO+32yODrfc9N1unvJ27LbbbryMHOccZgrfdbu+HjVd1xuS0sxARzYhKzuTXvUP 3dNm+qG7v5uG/QXXxp7gx5f9Y787us8/yaMvuBL6Ayv48vxQn7r9SY2rsXsmFr8Y16svh3H9 K+m329ztuyUNXmhwcbGkkxG9PphfZxcKNi+XGR8/T3Kb1sv//PTRVh7JhGZB5G7qjsO74bun 3XJ6Oi7tb/24IxJHYHmx1DO7iVgah82F6pFcGrb7kbzuLKPVSPT3fT6J8vDZp8PNYR44y/bw 5t1N/wv5Tr9aTxQf9+vVtvvldmG1tW4mcY1oPN88kGHvyLa/Gz/8RYysV7eLq7P+fjPMzvQ+ nks297sfv6Hz8eiFzEcTKVTtu2n+6+nQ1/J19zI8TafnXiGy5dXh8sf3xMV7dTBrRGHl9LoZ fUXon9QMIyIpgRFtfWOOdUxBhKuSG4jhRUNEWhUdRJQUEc9RqhYOEU2uUzFiPPMQMcIZ/B5j WRMxAVOznMuAEcGqbiBBYc1ZKXID0ZYCGkKc0jFjRLNgGkhwGAmaVbyexGzA2k48FWxVmZWG frIwGq8nG68SRCoLFku0ciGhhdAGW5jGCHcS8sa5ZlJgxAQD9UPht3rINZeqSCg3rkzVmGty RlsbSFB4PUYmBz2L1hm0hYhnEvs2ISabBpJ5A5FV4PV4aznmOgjRQCKL2N54FMJiWSdx3gR+ h2RmIpZoFjlgrotkTmLEkNthxLrGnGoDtlFBNiIERmTMjTlkVdASBWce26gQilePER04njMH pIwRI5LDiGVYc0KJ6vFKlcwav0epqCJENHMmYIQkWhuISbGJYBlYVi3mjfYYvAcLrwL2LBGY xb5NSBR4PYEbpxsI2TxGRMwMI9KlBgcyVCydoALH2qaYjKOYSOTBmFrSOWCuC1MN2ym8SokR WQp8j6Qoj6UjiW8NLVEK43AUk1IEnB9IaTKO8YSUCKOlVFxXaFVSC4+tV2ptQsKIMQy/x2iT 8RzLSmognFdMzQrvHUbmBUHEUX6A5ziRLMOIERXP8driDFIGliXWTxCONeaQvmFMlJGVhu1E Lg1vIDFhO4hGFizRJCXHlpgowuL1ZBET5iDTigJGlFFYP+RXjZVWWTmUjmKm4H1OMauwLyiu EuZA0aYVYBxVUrqsMaKsNg0kSuhZSumMs06lKB3Fc7SRHnNNRU5MGDHEAkQsMQdlrTwFEYcR W3BWQ3tMwBZPQVQZzEEwLGMOorI8NBCPKxYVtcC7Gela4V1GZUYxtoEYnPurrEXA1Cj66xZS BaSm5/I5YMRwnAlRSlGcxQj5ArRELVhS+D1C6gy9XkvjLUYU7ekKI7I2qCkTNPRgTfauMDWq PjTUjzZcY28kxDvMgaG9tjQQVxvUVEsLxlgB7Xquj3HVpqmqZtgOnFIMz/Es4D1Ye+M5ayAp YLlR/cUw18EEHEN0NLqh7TSHUowIXTlGjFCYa/LGimWddZKYt8JjxBxUHgu0eEM1Mu5TGNrt rcWISbiTZZgN2OLJRJNuIJZySIgI5WLBiC6RY8ToIDFiaQ9sIFzZBiJDC7G4LjFSFJwNGilr gl5vNFHD0jGaN95jrDN4PZb7hhascAXL2kmH+xRU4tSCte0VuSNGyOswEgSl2BhRseL1ROGE ayAe51Um6oIzO5PIUTRGhOeYt0QRASNFN3JLU2jPwpZYaW+EVmUla+xZVs0tHozo4jhGrC2Q g3aX2holpGsgzsF6zto5wcUIVxWv1FphoS9YzxX2YNr/BNaCDbrg3pOl2hDvCzbYiH3ORknR qoFYbL02WobrOXLsyLDcCmWx0BttVRL3+Ww13kDEMbKdghGbsWc5KihFxIjRHnqWk6wyixHu cEfGSdnYt50SGufxTnOLc3+naQpeqeEJd/OckcljuRmlfWOOVsk2EIuzaGdMqBhxLAeNEVUC XqmnDAFz7WnfxFwHJhzWXOAGdzRdUAJXHy4Yg095XGRZYy1EaRyWQRKmYSHkJbimdZlyWEwt S5nwSrPJGc8p8yEHRCo3GXLgKUfCuxkhKUL/8VwL3Dn1VJfgzNtzG3Cd5QWPuGai8jTiSO6p 4C54PRR2PIyw3rDiMdeWaleGEZNxXeKdkji39M5YHBO9Zwln3t4LYRpzZCM/8N5G3DX0QTkc 4z1JGscQH63FOZJPunrMW2bZYS1kkR2WaDYc73O+tOpTX2zjDMxX2fBtXzXD/RBCqoRxJzDe 6L8FqkwKlGjgc38DI1Y23iOswloIkhdcFQSpAj5FCMpUnOEHTaUmayA8NuaYhLVNyUbAlV6g bB1XU8GKRh92buHjs1BCIj7pCkE2vhgIkVwY6yeRGjDXVLniGiMkXQTczUKWBvduQ1YZnzwE qgAL1mm1AXMdGeWJFiPa4lPfyJnFeQghFe+akcuA7S1yysoxIljj1IrCUdH4PZRXGbweCuQN rqVt7PVRMYkzB0Is3heiog0Iy00ZjqNY1CLgrDNqG3F2Gw33OCpHSjoltJBouYsCI4a35lgn sAycjNhLyK0EPu2LjtID6KeRIi+OsJGMx2WMkImIBlI5Xk9iCXdoY259v0OIxd/IRIrwFXKQ GM8eridxkXBXN3FllMeIZnjfTkIlHJUpTWRY1knYijvbSSobMQdKWPwlTDLatBAKsdBCkmVG Yq6tjdgOUiBv9A1E4/OFFGTj7DDNfX/MW9QG9wJSlg2fS5mKUIkRq3FESoWzBgeFfAFLtMqA tZ0Zl7iLk5lS+Gwqz5+SQbllLiuOO5lsFPffslAa90czAbhuzFpl3GHKRjucBZBAM47XmUpx 3KXOlMg3Vuq1sFBzOfCI4wGVoA57SY4qJhirMrkw7gkRYhscJN7IbnMSDtdmOTOLq8OcqZxq INrgKpQQSh0gUlgjR8rFNr6EydU0so3CBMenvmU+J5UY0QF/X0WOxfGpYuG8cTJUuMr4hLAI GXDPoUjl8MldkdbgXbMoZX3BiC4OZg5l/thRNJCMv2ksWhQOtV0MOT7mzQiNzz4KeSPWdrEs 4N5TsbLgU55iTcLRvzgqszDimcFfTRSqaXG9Xbz2+Pu34m3B9UKJtGFgiSaj8BdrFKwb1UfJ VElg6y2y2IgRnXEnqxRK+hpzLMNfGJfaqhtLlcmkBlJxN68yy7F0KtcF95GqYAp/eVUFJb7Q rqsi22EYUQ5/HVg1lcgGI4rh6FJJoLg2q4419tPquMWyrmS9sTFH1NB4j5HYt+vcGMPU5iYX lqjXEdfblXJlHKsI0TiHrbSbYf+pSSeNZZC5a2guq4BP2GuxBfcta6XqXTSQ8znT9fu7BNub +c7VfAfh9Nd8W+jN9jQjddv7cd29+Wa+lXU9P3E//hzXuwt+3z8MY/8hcvd0fwGvrk7AYdtt NvNdpQswPDyckPmqSe4fjn9vvunGt6+U2emJEY6u+oe/vqc2X5zqxy/G4Wl/Qp/Hbv/VbtW/ LoMrdZ653k1fr7eX8cPT/d1l1q4bXz6Annarv78bj5J6FdDzzfTYb/tZQl93r1dt+t3Vj3fz RaG+O0zhsO5uF78+XqVvTxpYbsa7+QZY/023358u6Ny/5beLzfrt43S8pTTRr1U3/nz8cf9W nLHj1ahJnLDjj245L5aePv/xOiYuYx88Jy9j8nVMXcbU65i+jOnXMXMZM/PY48u+Hzfr3c+3 i/d/zuMPw2YzPPerL1/x3w19cE3oq91y87TqyURWw/Lw1W6+cnW60HT4vy74nB/fHG/MfPTw jM1P7z8mseqm7nz76/qjyUe/OPz2ptCqX67Jhu9etvevN5U+OS1ssz5Md/2+G7tpeH//6y9n D7tcyvzsX1BLAwQUAAIACAAcINFCHMR1XlgRAAAbtQAADwARAHdvcmQvc3R5bGVzLnhtbFVU DQAH7om+Ue6JvlHuib5R7V3Lj9y2Gb8X6P8gzKE3ZyTqMRo362CfsQF7s/au2+NCo+HsKNZI iqTx2jkXDYoeA6QFWhRNe+mhLQr00iJo/prYRf+LUhL1JiVqKM3M2vbFO+JD/B6/7yM/fhQ/ /uTVyhZeQj+wXOdgJH0kjgTomO7ccm4ORs+vzu7pIyEIDWdu2K4DD0avYTD65MGPf/Tx7f0g fG3DQEAdOMF9/2C0DEPv/ngcmEu4MoKPXA86qGzh+isjRD/9m7G7WFgmPHHN9Qo64RiIojb2 oW2E6OXB0vKCEe7tlqW3W9efe75rwiBAo13ZSX8rw3JGD9Dw5q55AhfG2g6D6Kd/4eOf+Ff8 35nrhIFwe98ITMs6GF1ZK0TRObwVnrkrwxmhEmgE4WFgGVdoHIj+leW4/il+FpUvD52A3NIM 6o/H0Vttw7lB5S8N+2AEnXvPL4vvORh9ubx3fB49mllz1LPh37s8jBqO8bDHVWK87FdSq0I5 4i/i9mUiLVQKF49d8wWcX4ao4GAkjpKHzx9d+JbrW+Hr/NklXFkPrfkcOoV6ztKaw58vofM8 gPP8+dOzWDb4gemuHfQ30CaxMOxgfvrKhF4kaVTqGBEvz6MGdlT7i7SthDlEqr6ERqSWgtS5 BejcQu7cQuncQu3cQuvcYtK5hd65xZS5hWnEv6P6QUGzYoGuK2rFLuUrK7Qhc+3L9Szs1ODh aw/6tuW8iEdp5SCZTpteE/quc8P8ktOVtzQCK2BucGEbJly69hz6whV8FZJ5yjrac1e49AzT SkZcbMYuhsfWzTIULpexUlS70cTWlo+tIKw1a3/hp741rzUDDc2ewLm1XqUDFWqM0mT2xqDW WGlvHBFKeK3K2LL+Tq29ZcQlwjsnjC3r79QZW8q1lk16eGL4L4iKMGnSn2PXdv3F2qYp30Ri aUx8LWBpSVLBicwKFeHQNJF/JkiHDTP09mzgobfvgiJ6L13gRO+FGVf0LpoA9gy+tAKqa2I1 o/EILgzfuPENb1ltKrNPEZ6u3RBW2wN2R/vIQVO+AArEfmSRuZ+S3aFzltkA0btgtkT0LphN Er0LJttEbd7JSNF7YbZW9C6YzRa9i872C3DaL8Bpv0Av9gv0Yr8Av/0Cm08Q6F10BirgByrg ByrgAyroBaiAH6iAH6iAH6gyJ1BlTqDKvQBV7gWoMj9QZX6gyvxAlfmBKvMDVeYDqtwLUGV+ oMr8QJX5gapwAlXhBKrSC1CVXoCq8ANV4Qeqwg9UhR+oCj9QFT6gKr0AVeEHqsIPVIUfqCon UFVOoKq9AFXtBagqP1BVfqCq/EBV+YGq8gNV5QOq2gtQVX6gqvxAVfmBqnECVeMEqtYLULVe gKrxA1XjB6rGD1SNH6gaP1A1PqBqvQBV4weqxg9UrRNQow05GwrFHbDSBlT3qCetKyB12iVE g3oGF9CHjlmPoUqdR0Xvi317+sh1XwjZfmepE/Yd6yNrZltuHKJ+3RrvlifkzdmG7djPjoWH MNuIae59yrj1Oy6nMTxI009QxfC1h97qFaPu8yT7AfcUV3yE+jXiVIRolGn2Bc5AiInBL4z/ 9gOkzbiOKGpHQAfYIHhJ4khozAL8f1rPhot4/8hzA6TxU2xMaRUkaSq11FB1vaXGVFcxc9Lx uC+hv7Dd24u1Y4YZBUk3xjp0o11eeHJKLTmvlsw/Xwfhs8iRPXLmlcIg2TKOMlXgwvWRFCSA i0L4Kjy0rRsnSvRJm82MANqWA/GYMStxKk7wZVoNKMQ0mU+PymkySeZMOS8mFnWLcmTqINXU Ic8wiQcQjXf+mZOWGslTB5FWedRJdV5A6J2jPsbpj8eIJUHS9XqV1EF/PMp6kSaYyqy4zng5 nci46zBi8eOXdklYNXbPOBgHqIwDRMZJVMZFaRWZ2I+Xhr8BPzOuWHZOtNTOMqBQWSYVWdaV OzKVO3JH7vCzAbSzQaJrDuBhg0Jlg0JkgzwgG+QqGwjm27QhUj92+y0CqWp7awyUeRioUhmo EhmoDMhApcrAOq0KD60alVZt67SqnZUl1YWmKtjdN6qLysPCCZWFEyILtQFZqLWri8ZDq06l Vd86rZN2Wic8tE6ptE63TqveTqvORquJfL1hhtBvmq6LNdJxWnOeYyNECdzJwPN1RcWz5iuQ pF5ptTFuGiWCarLSoo1QoqwohKu4JWVcaQ5R28DKIgtnNrZHMzuZi9/iXOtksPNXWM6o/Bja 9hMjqe169KqRS0tKJVEnlM/cMHRX9PZ+HOGidjAuD2acEUFnOVKtGfTx2pHGdkBge5K/x8lx RnCaaE3kruKlaHVshw5C3rmbpBhXRxkXXqOx/sRYeT8Vkkrdlho8y4v65E/R8eTvczPzW2jB Bn3qmqG0UNPZll8lsDfxzvOQxOtc87zr6DmRUWIbW9hPelBOcozZl0sdCPUphPobEtqD5noe dOYWXXlxOYv+llDQVZV74K8fEhXJD++IIjHLzA/xbIBIbFrWs4nZlR3pwJVzl8gQ9PjumFvT 8IKhLa4f+hSg7NAQ+SHFAqFh7d5nZnGj/dD1y/P6JBQ9/KgxhrlJfLs9QEJe8jZVIYW4K1Vw jJseiVHT7T56qF1uC+ZMxJZgPABaSzAe6HLLQGVFBC01pummIa2GospaCzskUW5lmFiJRdS1 nBw1rjq/Y3ftW9CPnFzB8RWfjnMQOO6F77qLKiDEfgFxbNh2DRDxw10ajSzKasUrt0geGYZq XLb6ZcjS8AjuMHp8t/xhokUcXrELx8geKGba++KCSpOIfPFd399AywLHDaHgZzvcTROHyhq8 dcL9EvrJVmJaK1h70A9M3/LCfuUOnfXKhi8lAoG4gMel1sWoU2xCZEkN5yb+BEPFRvRGJKAR Sd7CK3OgldYiRfE8oEiSPJ0MQpJMI0luIglsQhKet/RHwukX6/grGDUSsoJBZ3MDztWwYcom MHqWIpDXicOIWZWpJk9L85P+2WzDG2S0qMy+xuV3dAZdZqekS0rrdI9kimJxFoFbyDfpSR5n 1s3ar7tZ/HjXLjaa5y6Q8hbyWpocbl/soChnUtiHajYwYu/WfY1aC4oyAmJLXpHU8zQxEQgt XIrFNXywv2ct5skQYmDW0TM6p65R4a6XI5tyCy9L+mNYvIMYKw2BZXFhshDZNdP2S8FoDMM6 1sixEse5mUfNlcS8wmvfvp3HrRUu3XXYaJNwneu7YpK6pkwY9dyzheviTt+LkOhUVbpOstmD gFkEhhzQk7S+3awfhGeJ/OoKnZcRZav0JVwiS8tVCCwtpWNXk7CrqdeEhGuao2rKso56pMqt YpWwBKupwn1JLhbM04u62OKCa1TyngByKk5a8KhP9OlwkK2FAAFXCFAl2tcBY4CIfgsfMikm uQ03tz+PvptUTzIK4SAhwI0dnUYXRGQbiIPNqWCWAtG1tx2BAWp1AVcMLkSlxdhCXruv6VBy tKduevITP9WklWgrlU0fZzwWMxcfOWf3XZuntNsrxgXDcHDH59VmNXngguvZoGss6n7hwGsm TJ1FJdvaE7ItDpRJ9TRiZIjgq86nvBjNZefTVLTxgWHGR9zRADrXWRWZRoO8RRpUTevXhSS5 3PFKlbyeTipcxzWGWU1TT/p1TLHPfU797IRn3EAhybveUcbXhUHM2Ise70OKQh6u2Fb+XhfG kRL4Ys5RM/i2tYWib2XTJKKVDM+YC51gWUP84DtLYK8yZ59Bc24QVj7o+XVcsDM+7vOsNhdd smCnzWA2WYGzSu7pGgbRCpkovrSQLsNU8JyS7EUDCZ4g0r8dOwJxJ4BMJUfgSSZUCmMSTvZ3 +KKTBAlbMIkM92GPb69ceC5hAs8KMqYxLmX3TgRNmntEcu4w9ShZnnffQzQomzWIXpFElKkV TU5YtDVhlbzM8OpFntZFCrZ3s7rsAyx7MY9L5URmYCZ+Ohcz5lNVINOP4Y7xRaaBYmC4j/HN ep43L+J4e32oi2tqIN7YIPN08PTgiBIK6hbdUJfyZHtnCvuUp0dZB3l3Yg7tEefQ3v5NFT3K VNHb0xmPR57xeJ09aaphw4+YBmdvI/OPWTD4sAMK/oId4o/dbwVkvxW8Y8fPEUVEQxPsn6EJ KIYm2FNDE/gUDepuaILtGJqAZmiCDQ1NsAVDcxm933XqR75wwbXUd7Tibm3Pa+nHOHcwCcMi AFTZgPdbNt1OgVpDyIZg/VPhfNi3a2cf2WKmHNy7GEeZp/u1c3Xprn2TwMvk8bBMJKT1lff4 xL3ilAdNy7ApGdW4VBgoqXqfv9xBjNfO3HA5bDY166oiPp6y8OEXlNNAcRF3TCy6ud12fUIy eZ/nmqI0RwoZcdGQnmOHTr6idgrnh210VeLGjyLpW0CYqgLur+cgpnN/X0fTNbYv8LQdlt5w ajEbOAsghhDl/HACr7t9sv0DgO40gNKjj20ntQeBBe2gdoKLzc5p585soC3F/Thbi/lHPYjc Ka2jfsyWN2tc1fbt3DYpeJewqkNmRP+M2sEnLRIiSHuj+Aw77+7oB2/0wRvxTedKa/Xt+6YI 4PX4c/yYckSlGNR4J8KcdzFE0JbYTckXrYQM+nc/kd4AijqRA+ZYA7e/yxW/WKaMVaaPFWyg +rSoTc+cVyjUKHRqCBcfSTtJYgpds36MCz0URNYZiyS9ExaI8XN0vdylJklEljduO/Z+bntv P5ug0W27HZ+UPhjN3f4/opDtrBVT77Qk7BN3l0zWiol4Gt9JfkBWA8p9etJmesD42T9VLpOG 56Ubnw0lk0a276AbaZ0vpSMbOMqNdMOORSWPhXK5mzjoWDTyWLRdjGVCHstkF2PRyWPRhx1L du1Ufmp3Sl4+x9cuk10F0RVPRen46GjU+T6pI9dHxjbI75NKPsSMzAMe6JfRnXxCYmLSQEO8 kZRvIWW3TW3UNruJaqPW6T1VGzW2HMRD+JCv+c82az6usf8uX+5F+QyKQf2ieFt0qHh/bH59 bFnn5YkiqWctjrB11d/zZm482CrVb/7x/dt//uXtN1+9/f1fhZwcynZukXbDaKMcUzTQncoN lJ64Jv62QO0yv6yEOf6nTsVDUJYly+HbXlIqcn2tfybmyLBt13WEq476StyZP5mqYCJvpLC1 7GBj6a6MYlJw9sAMsl/ED/hFT46Drh/166L/dd/69lf/jgDw7S83wsCsjZnbYVKfIGNlJyDa k7d//Op/f/qtALrxkfhBfEnSDrVTQrbI9q9tN8waoYaDvEX85fbOHkNqo/YOpIYO9JXJjT4y mYErl/iltbpcOyPivT81dekbGYmMKYbmm6/e/O03Ha2MyQiPFkZgsvmtQo6LeRMu2L7LSLiC tpXQgkiluk3Mbknv624e1/eT/NhLGLUJXf8I3lj1izPyikJWU0iqMk83jo6AqAH6Dqt3NPfb FicSKEzxJfIUP+3nPTQyla/hkAJvkqIUI2/xT+rOdQ/26s3ff/3Df74u3lxm9Wu7OHT9lJDY RdT00y5JXgQ9z1SSttz/oNcf9JptvlZPuTKj+9Wa7zQibO613I9eUWlJPNMPWxdRtSR9ytpx dhzUk6OVM106OokDI0u4gsdY/81IahL5C8WVBQPfTWz1HKOHqLofTVfaLkKvLJJ0STqsbJQW CRXRvzO87F5XzAGPZixEUlBgHSv4E8PrMo8nrlpOVfHk7PDdX0nX9/ujBfS3f/7vd1+//cMv 3vzu+45z3IXYxs27t5SmqaDUNGsO1rPPkWslc84kWCqTrJ0yEXWaqp9JnU7MkPxkJR1m2pZE 1prJ1uYkKyksBXdJLTmvlpRcKPWqlOyzwKBpLRrJBTEcsvnBq8hUH4xWloNmU/hZ0Semlr6u eb3DVqasS3/413dR3IaK2ULcogxbqU3NiD5tQ0ppgKobo8dWEAoXWfUGq153WGl2F93TyzI4 1FT6F3NS3TGRIiD1WRv2ZaJgxD3t9K/gwf8BUEsDBBQAAgAIABwg0UJ6W9OM2gAAAFUBAAAY ABEAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sVVQNAAfuib5R7om+Ue6JvlGdkMFqwzAQRO+F /IPYuyI3doUcLIdEbiHX0kKviizbAksyklxaSv+9Cj01x56WmWXnDdscPuyM3nWIxjsO99sC kHbK98aNHF5fnjADFJN0vZy90xych0O7uWv6uO9lkjH5oM9JW5QNk+e54/B1El1XPjCBxZEy XAkqcF0fS8xquispo9VjJb4BZbTLMZHDlNKyJySqSVsZt37RLi8HH6xMWYaR+GEwSnderVa7 RHZFQYlaM96+2Rnaa5/f62c9xL/yWm0N5r+Ui7nMxo9BLtMnkLYhNyhy+4r2B1BLAwQUAAIA CAAcINFCh5n0TaQFAADbQwAAEgARAHdvcmQvbnVtYmVyaW5nLnhtbFVUDQAH7om+Ue6JvlHu ib5R7ZzNbuM2EIDvBfoOgQAfeohNUhRFBussbEcCWmyLosk+gGIzsVD9QZKdzbUv1cfqK5SS Lf8kFiPRTKq22otszgx/vhmSQ5nZT5+/hcHFmqeZH0djAw6BccGjebzwo8ex8fXOvaTGRZZ7 0cIL4oiPjWeeGZ+vv//u09NVtArveSoUL0QdUXa1FuJlnidXo1E2X/LQy4ZxwiMhfIjT0MvF 1/RxFHrp76vkch6HiZf7937g588jBAAxttXEY2OVRlfbKi5Df57GWfyQFyZX8cODP+fbR2WR Nml3Y3ITz1chj/KyxVHKA9GHOMqWfpJVtYWqtQnhsqpkLRvEOgwqvaekSWuL1HsSnMNg09BT nC6SNJ7zLBOlNxvhrkYIGgAsqthZNOnCcZtVT0LPj3bVRK/9v2t7KNreQiur2g9EsLgWweTd Z3nqzfNfVuHF0bcfF2MDlCpR5i+EbO0FY8Mt/9kzY1RIwlWQ+1/4mgd3zwmvdIqOBrws3qjl YRJUwtnNbDYDLthIgnUh8MWjakzEfJpXynCjJQLeDXeFCz73Qy/YVXDHv+1kAzjclf80r0oD /pBvipNf07JDYpzbZ6Uj2jDE5yTORLOYoUJ/tNf0owJBUdFWLL4tveixnK4mAVv1sv5R2Xz5 POD5JmxYB/tGHTazMUQz2mnYCDAZ7EKsHzaqg+0owyY2RBPCOg2bISJhXUj1ozbrULvKqE0T idAGnV5ECDYlqAupftS4BjUFyqgBgnTiWGdE9f0qCHh+kvRff/z5zy/XT1fp9uHGUZ4VVLO5 74+N2+fwPg5K04lgelTgR3kRRA+eILqtLD3DcVad46D6HMGmMzGnoMuOO2/p74LjSJ3jkLLj mD2ZgCIv767jztpGuuA2u85tprLbpg6mtjPDHXbbWVtSF9xG69xGld0GsYkA7XYqsffEKb8V Uv2pBKtDzZRRWwTObqasywvbWaS7MENg3ZHdncr8VpYGp93mTIg4sSPnvWaIBreJOSxxWyE9 dNteu8ZtbzrlGAPUs1AMkAYSli3bmQvpIYm9th4SSBeJ4cDUAMNGstlcSA9h7LX1wDA1whgO sAYelGAJj0J6yGOvrYcH1stjOLB0HEEAoLIjSCE+hHKgr4eKpZ3KcEB0gIGW9FBdiI/A7PX1 gCHvAWY4sLWcWxmRnlvZ8TJ7oK+Hjf1ObIYDquV9DAbS9zH4eOE90NeDh74fnuGA6SBkUdlK XIqPCO31VQm1zSNf/xqBoA3RDZYetZbP96m/+FmSTSJgY2zbJ7NJ8TFPgrn4iAEDAOpJrH5o 4jCFA9XLJHDX+5mJHBtNm0ZhED/x9AvPc56eHgEath3ByzwP0UabFveyfJL5XpNE76WvpmUJ j3Iv94sfpGGb0f8Wh150evDmqcGn/uOyfvSwOM4fTR/awIHmyyEBV3FI0nDErZ2JLKQQj/iV h9g5HpLFp9V6SCbCCkOyPizoSPugMxlRCDryMUFnt/YQJlTBQ/bHBR1tvyhioDAk+mFBx9oH HYGoUdC13fzRic2fMjQlZ27+FnGRC0//RL7D7FqWwxglH/f6VeUdXyAUqgp5dPn1tsl7og+b He1TBghUJnyfB/R5QJ8H9HlAnwf8J/OA11e3LORYhLiz8/IATJ0ZRBQ3eAkgJkIX84B+h+93 +H6H73f4fofvd/h/8w7/+sYwcQE0J1NH9boIchhgU0o0XRdJbvPngL/Q7++QnGCD+oslMjxm f9vkDUK4v4LyNiSrv5fSFBXpL6u0oGX3N1jaAaP9tZbWzNj/9K5LVCa/0eEf2h5lwjuelcei E3ZI0c5UtMOKdpaiHam3YxIzu97MlpjRejMiMWP1ZpbEbHsv/qQdltlJgoXK7CTBYsrsJMGC ZHayYJHZSYJFFitQEixQ2lFJuECpJyQBA6VImWKLSBIz8Ajq6OA/5bj+G1BLAwQUAAIACAAc INFCdD85erwAAAAoAQAAHgARAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1VUDQAH 7om+Ue6JvlHuib5Rjc+xisMwDAbg/eDewWhvnNxQyhGnSyl0O0oOuhpHSUxjy1hqad++5qYr dOgoif/7Ubu9hUVdMbOnaKCpalAYHQ0+TgZ++/1qA4rFxsEuFNHAHRm23edHe8TFSgnx7BOr okQ2MIukb63ZzRgsV5QwlstIOVgpY550su5sJ9Rfdb3W+b8B3ZOpDoOBfBgaUP094Ts2jaN3 uCN3CRjlRYV2FxYKp7D8ZCqNqrd5QjHgBcPfqqmKCbpr9dN/3QNQSwMEFAACAAgAHCDRQqnI XKqGAAAA2gAAABMAEQBjdXN0b21YbWwvaXRlbTEueG1sVVQNAAfuib5R7om+Ue6JvlGzSbIK zi8tSk4tVghOzUlNLklNCS6pzEm1VYpxDHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2Shkl JQVW+vrFyRmpuYnFevkFqXlAubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMykn Mz+9KLEgoxJqGFWMsrPRh3vGjpcLAFBLAwQUAAIACAAcINFChHoq7icCAABYBAAAEAARAGRv Y1Byb3BzL2FwcC54bWxVVA0AB+6JvlHuib5R7om+UZ1UXW/aMBR9n7T/YOVpewAH2ChCxtVE VbXSuqIR2mfPuQFrju3ZBpX++l0nkIV1T8tDdO6nj+89Cbt+qTU5gA/KmkU2GuYZASNtqcx2 kW2K28EsIyEKUwptDSyyI4Tsmr9/x1beOvBRQSDYwoRFtovRzSkNcge1CEMMG4xU1tcioum3 1FaVknBj5b4GE+k4z6cUXiKYEsqB6xpmbcf5If5v09LKxC88FUeH/TgroHZaRODfUqUeljbW jHZeVtgodKFq4KOr2QQjnc1WYguBjxltAXu2vgz8c46eFrLlTnghIw6Rj2fTK0Z7DvbFOa2k iDhf/qCkt8FWkTw2pElqwGg/heFF1iD3XsUjzxntm+yrMokK8msRcvNi64XbBT5NBDuLraXQ sMQZ8EroAIz+cbA7EGm/K6ESwUOcH0BG60lQr7jhcUZ+iABpcovsILwSJmZtWms0WLsQPS9U 1Ni7sxvYT+tj9YmPmgQEl4m044D4kl1zQnis8G7xH2RHfbINh6xH73ZYrNaD7/ArzMnelbjp QKIl0poKPMocEozealLtjUzzD28uc6b1F5EHYVAOnt8Xm0HB6NlkS1s7YY783uD6TbNToUkB GqSt67057ZlsTHp/wPKPqJdTUVrwz7Bxhb1Jqjxt7tLZU9uziru1ExKVMJlMJ33d9UJsjV4o UUidFDoHu8PBeZ0OwFqzhfKc8zaQlPzU/ij4aDzM8Wmke/ah/rovmP8GUEsDBBQAAgAIABwg 0UKONs2AtgEAAGsDAAARABEAZG9jUHJvcHMvY29yZS54bWxVVA0AB+6JvlHuib5R7om+UX2T TW/cIBCG75X6HxB3L9hutqnldaSmzamRUsVVq9woTHbp2oBgEsf/vuBdO9kmquQDzLzzzBeu L576jjyCD9qaDc1XnBIw0iptthv6o73KzikJKIwSnTWwoSMEetG8f1dLV0nr4cZbBx41BBJJ JlTSbegO0VWMBbmDXoRVVJjovLe+FxivfsuckHuxBVZwvmY9oFACBUvAzC1EekQquSDdg+8m gJIMOujBYGD5KmfPWgTfhzcDJs8LZa9xdPCmdHYu6qegF+EwDKuhnKSx/pz9uv52O7WaaZNm JYE2tZIVauygSROyARRBmybpkeAOyGD9nlhD2tiF8xDi0IGEMSD0JOitEV3cQM0WSuKFh99/ QGIzmZdLPEsPAq1v7tqv5NJ6Z73AuM9JN/vSwvYwxrwqNN/PWL6u2UtT4igI0muXYg9JTgxR 3YmA1/Fx3GtQn8fX+V5LUpSHR53eV1OcTZLlPiNvvDYIqil4XmTx42WbFxVfV5zfLdBZVB9X fOgszjWupjoscvb8LC+/tFd04RUfWv6xKo+8f+Kfgf2x7P8Ty4yvM/6p5XlVnJ8SZ0AzFX36 ezR/AVBLAwQUAAIACAAcINFCxolazmYCAAB7CgAAEgARAHdvcmQvZm9udFRhYmxlLnhtbFVU DQAH7om+Ue6JvlHuib5RtZVPcpswFMb3nekdGO0bBCY29sTOxEnoqlnU7gFkEEYzSGIkYeIz dNl79Aa9TXuPPP64sWucGNdGwwBPQjz9+N6nm9tnnlorqjSTYoycK4wsKkIZMbEco2/z4JOP LG2IiEgqBR2jNdXodvLxw00xiqUw2oL3hR6pMUqMyUa2rcOEcqKvZEYF9MVScWLgUS1tGccs pA8yzDkVxnYx7tuKpsTAt3XCMo2a2YpjZiukijIlQ6o1JMvTej5OmECTJjurGAnCIevZmi9k WsUzIqSmDnStSDpG+Bqag104B7gP12s8QHY5MEyI0tT8HejW4Zhwlq43USU5EXVHxkyYbOIr ohhZpLTu0mwJHbleYJinOVAdcQD6bsTdG9PbjYTVPP5uxNkaA9+0awB7IOaMU2090cL6WmXe RsSF1sc9IOHB6cKd104En4cI/Dfs3vmDVyL+ISL+W0SqRycIuhH58/P7718/KhAkNU8Q22Q8 Y3yWb5ayx8gBRhjYOJvWysjvtzEiuZGniKb3igj7+LENkYPfQeSVg7ohupe5YlSVsjkgmAGA GFbCKQXjdRIMlxFVDWYhzVzldL7O6D6emD3T6Cg2JxVUE+jIZk4SEPwBLFPQiNdUkleC6YBF F0zrTiLpO2erI6d7HTXV0lJH/3pOa0G1HKeZzpsSimhM8tQc48r/JaKOrvyFpMtcWJ+lSViI 2mzEOY9Ehrjy2mBrmcOHweA+mO75iPvOMv0TfITwBWR2oFjKzaYulXLzcS+86dxVJB63SHhV /t70lB8+DLqSSBmgOEAiqFzUrZj0Lm4b7STA0y9DornRkxdQSwMEFAACAAgAHCDRQnxxAt7P AQAA/hAAABQAEQB3b3JkL3dlYlNldHRpbmdzLnhtbFVUDQAH7om+Ue6JvlHuib5R7VhNc5sw EL13Jv+B0T1BCBCyJzgzbia9pB/Tpr3LIBvNCC0jKabOr68wdoqbHOJDhxzgotVb9rF6+zjA 9c3vWgVbYawEnaPoCqNA6AJKqTc5+vlwd8lQYB3XJVegRY52wqKbxcWH63beitUP4Zy/0wae Rdu5yVHlXDMPQ1tUoub2ChqhfW4NpubOb80mhPVaFuIWisdaaBcSjGlohOLOd2Ar2Vh0YGvf wtaCKRsDhbDWN1Krnq/mUqOF77GUW3tYg3YuyxzFaRJFNKF4n19Bubvd57Zc+fOjsENrbu7F 2h1R/Ix+l5vqFfgBmpfgEpyD+h/c97EsTRe5vzXaK4v8xj5193VBwwtxiAtQ4HXljw56CjXo 7LzK1UlH59Wa4cnPKQ2Hh+7G8bGSqjydSZSRJCXRDDM0yT+C/HGMScpoOpvkH0P+WZIRGqWT +GOIn2QzytIkw5P8I8ifkJgxlk3mH8f8NE4Jo/6a5B9Dfm/+WZzSZFL//6nfh8f1OIb3hJ5Y AhMaU8ai+O2fJxHOXvfKMDFwyxA+9ctzZnLMi7nQhKQ0Iniayzt5kztaaJys5ZO4A7M00Fph +qcJtfuqf32+3++4UtB++/KpZxv8tVj8AVBLAwQUAAIACAAcINFC3z85WQ8CAACABQAAEwAR AGRvY1Byb3BzL2N1c3RvbS54bWxVVA0AB+6JvlHuib5R7om+UbXUyW7aQBgH8HueYuRDlAjR 8YINJoCEFwihLAHjOL4gYw/YxJ6xPGOzVJX6Dn3DPklJQhoOqIeqzGk2/b+fvpGmMc5IijIW IQq2SYxpkwsZS+sQUj9EiUe/HI7x4WRJssRjh2W2gmS5jHxkED9PEGZQ5HkF+jllJCmnf+K4 97x6wf41MiD+q47a1i495LWuwGE0jhV2YJmwKGhy3wxZNwyZl8uiqeplgRe0siqp1TJf43lR E/WO2ja/cyB9vSxyAHsJanKHSjhPjplvuQWrx+mGsqyljwZAUMCvHz+BDrbbt4nZgJ8X3iHw Q/I/YNIJLPAYOi8b+YwsUAZEXhAuDKqcgEgWe3h1nmTiVRzREBAc78Aoi1YR9uI6OG5fGCmf IBdxjtIIv5xnOlBQLoxRTp8QUXYWAuAlSldPSns5C0l2vgvXMbvrDafmxALT0WyimzfT2+sV u7twZ2ofvHlC52nPmFdFWapI5403wu1gZqGNsgm6W5Pgp2fZf7GetK8Gle7xRAq12QjBNu5O 9bW9qLjSSpXGsOe4VKxk3XXqFMI+DUkSIsvtd7WSv8tfKqobBnQheLa8h8/qMg4E+2EpbIp9 uxqVasFkKJfYWtq53kMh73puIEO7Rzujx77FDwe262iLfO84RTV6rO49lY1jf2L1c00uGdn9 eGLFIevwSoT0QYcYw8Ff29mAn19u6+o3UEsBAhcLFAACAAgAHCDRQpbgR4ilAQAArggAABMA CQAAAAAAAAAAAACAAAAAAFtDb250ZW50X1R5cGVzXS54bWxVVAUAB+6JvlFQSwECFwsUAAIA CAAcINFCmVV+BfgAAADhAgAACwAJAAAAAAAAAAAAAIDnAQAAX3JlbHMvLnJlbHNVVAUAB+6J vlFQSwECFwsUAAIACAAcINFCLc//hUQBAABOBgAAHAAJAAAAAAAAAAAAAIAZAwAAd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVsc1VUBQAH7om+UVBLAQIXCxQAAgAIABwg0ULWLfiXmhEA ACiCAAARAAkAAAAAAAAAAAAAgKgEAAB3b3JkL2RvY3VtZW50LnhtbFVUBQAH7om+UVBLAQIX CxQAAgAIABwg0UIajh6fugUAABonAAAQAAkAAAAAAAAAAAAAgIIWAAB3b3JkL2Zvb3RlcjEu eG1sVVQFAAfuib5RUEsBAhcLFAACAAgAHCDRQpcTLVZFAgAAEQcAABAACQAAAAAAAAAAAACA exwAAHdvcmQvaGVhZGVyMS54bWxVVAUAB+6JvlFQSwECFwsUAAIACAAcINFCWOiqm9cAAADz AQAAGwAJAAAAAAAAAAAAAID/HgAAd29yZC9fcmVscy9mb290ZXIxLnhtbC5yZWxzVVQFAAfu ib5RUEsBAhcLFAACAAgAHCDRQtlKREBbAQAAuQMAABIACQAAAAAAAAAAAACAICAAAHdvcmQv Zm9vdG5vdGVzLnhtbFVUBQAH7om+UVBLAQIXCxQAAgAIABwg0ULq8cieWwEAALMDAAARAAkA AAAAAAAAAAAAgLwhAAB3b3JkL2VuZG5vdGVzLnhtbFVUBQAH7om+UVBLAQIXCxQAAgAIABwg 0UKWta3iugUAAFAbAAAVAAkAAAAAAAAAAAAAgFcjAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxV VAUAB+6JvlFQSwECFwsUAAIACAAcINFCxZQm0BQNAADaOQAAEQAJAAAAAAAAAAAAAIBVKQAA d29yZC9zZXR0aW5ncy54bWxVVAUAB+6JvlFQSwECFwsUAAIACAAcINFCHMR1XlgRAAAbtQAA DwAJAAAAAAAAAAAAAICpNgAAd29yZC9zdHlsZXMueG1sVVQFAAfuib5RUEsBAhcLFAACAAgA HCDRQnpb04zaAAAAVQEAABgACQAAAAAAAAAAAACAP0gAAGN1c3RvbVhtbC9pdGVtUHJvcHMx LnhtbFVUBQAH7om+UVBLAQIXCxQAAgAIABwg0UKHmfRNpAUAANtDAAASAAkAAAAAAAAAAAAA gGBJAAB3b3JkL251bWJlcmluZy54bWxVVAUAB+6JvlFQSwECFwsUAAIACAAcINFCdD85erwA AAAoAQAAHgAJAAAAAAAAAAAAAIBFTwAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxz VVQFAAfuib5RUEsBAhcLFAACAAgAHCDRQqnIXKqGAAAA2gAAABMACQAAAAAAAAAAAACATlAA AGN1c3RvbVhtbC9pdGVtMS54bWxVVAUAB+6JvlFQSwECFwsUAAIACAAcINFChHoq7icCAABY BAAAEAAJAAAAAAAAAAAAAIAWUQAAZG9jUHJvcHMvYXBwLnhtbFVUBQAH7om+UVBLAQIXCxQA AgAIABwg0UKONs2AtgEAAGsDAAARAAkAAAAAAAAAAAAAgHxTAABkb2NQcm9wcy9jb3JlLnht bFVUBQAH7om+UVBLAQIXCxQAAgAIABwg0ULGiVrOZgIAAHsKAAASAAkAAAAAAAAAAAAAgHJV AAB3b3JkL2ZvbnRUYWJsZS54bWxVVAUAB+6JvlFQSwECFwsUAAIACAAcINFCfHEC3s8BAAD+ EAAAFAAJAAAAAAAAAAAAAIAZWAAAd29yZC93ZWJTZXR0aW5ncy54bWxVVAUAB+6JvlFQSwEC FwsUAAIACAAcINFC3z85WQ8CAACABQAAEwAJAAAAAAAAAAAAAIArWgAAZG9jUHJvcHMvY3Vz dG9tLnhtbFVUBQAH7om+UVBLBQYAAAAAFQAVABYGAAB8XAAAAAA= --------------080004020603010106030300-- From ron.even.tlv@gmail.com Wed Jul 3 08:10:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2E11E81AA for ; Wed, 3 Jul 2013 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.567 X-Spam-Level: X-Spam-Status: No, score=0.567 tagged_above=-999 required=5 tests=[AWL=-2.256, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkwPPCltpcM0 for ; Wed, 3 Jul 2013 08:10:53 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4C11E817E for ; Wed, 3 Jul 2013 08:10:52 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so224204wes.39 for ; Wed, 03 Jul 2013 08:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=vhCIrYfkBSRDl+9i/oQXSsdW1m5PquS7kHeFc9G3ZS4=; b=PjGJ4pI84PKA7C09p1xA4Fq1zwNS7nNO3WqXQ1b/t/sRkLfbzjZHDp7+OIZeBP6Yry aZi2KIjiS8mrJ1mM2c0oZF+uh/zVeOT0H+7a4wsK/A965ppZtDcVaTvPAkoplWTuR24b a1WgZcigw+UmjNNu/t9h54+EfQUpSNw+1cchoHVAMSQ/z6sUNRcy1dRaAnvoS5En8IOf DqX64fNJCTaAKt3iDiwUccJWjL/hGkhROZquuEjGws8MkI2+UxgnCKXSfRoXr4P9XSr6 9iWvjlAkYMnyVLqLMT6JKA5Z57S4TsRrAaxO0ZQLY6MJ3BU4NWGZC6a+Z546zQf4vWX9 tgxA== X-Received: by 10.180.198.146 with SMTP id jc18mr18639336wic.61.1372864251863; Wed, 03 Jul 2013 08:10:51 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fb9sm29418661wid.2.2013.07.03.08.10.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jul 2013 08:10:51 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> <51D43BBA.30600@alum.mit.edu> In-Reply-To: <51D43BBA.30600@alum.mit.edu> Date: Wed, 3 Jul 2013 18:09:15 +0300 Message-ID: <010b01ce77ff$4aa7f490$dff7ddb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEaOMV6CzsZaNVUYuyCsUmEPCXHJwIdWgIrmqqiB7A= Content-Language: en-us Subject: Re: [clue] Signalling work on Telepresence in ITU-T X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 15:10:53 -0000 Hi Paul, I do not know what is the outcome but this comes from ZTE, they do not participate in the IETF work Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Paul Kyzivat > Sent: 03 July, 2013 5:57 PM > To: CLUE > Subject: [clue] Signalling work on Telepresence in ITU-T >=20 > I think maybe ITU has gotten tired waiting for us! > Another reason to start making progress on signaling. >=20 > Thanks, > Paul >=20 >=20 > -------- Original Message -------- > Subject: Signalling work on Telepresence in ITU-T > Date: Wed, 3 Jul 2013 03:38:10 +0000 > From: Xiaojing (Lennard) > To: Paul Kyzivat > CC: Yangweiwei (Tommy) , Liuyan (Scarlett) > >=20 >=20 >=20 > Hi Paul, >=20 >=20 >=20 > In the last ITU-T SG16 WP1 rapporteur meeting, a proposal to start the work > on TP signalling was agreed. >=20 > The original proposal can be found in the attachment. >=20 > The agreement and support of this proposal was made during the = meeting. >=20 > The conclusion from the sumary report was: >=20 > Contributions on signalling topics are solicited. Experts noted that = some > useful topics might be proposals for a signalling framework, RTP = usage, > protocol usage, potential signalling channels, and analysis of = approaches to > integration the CLUE advertisement/configure methodology with H.323 > capability exchange and negotiation. >=20 > Experts felt that the 28 October =A8C 08 November 2013 in Geneva, Switzerland > meeting would be a suitable time to launch new work items in this = area. >=20 > Thank you. >=20 >=20 >=20 > Best regards, >=20 > Lennard >=20 > = ------------------------------------------------------------------------ >=20 > =D0=A4=BE=A7Lennard Xiao > =BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BEHuawei Technologies = Co., Ltd. > Company_logo >=20 > Phone: 0755-36830241 > Fax: 0755-36830194 > Mobile: 13607111771 > Email: lennard.xiao@huawei.com > = =B5=D8=D6=B7=A3=BA=C4=CF=C9=BD=C7=F8=BF=C6=BC=BC=D4=B0=C4=CF=C7=F8=D4=C1=D0= =CB=C8=FD=B5=C06=BA=C5=C4=CF=BE=A9=B4=F3=D1=A7=C9=EE=DB=DA=B2=FA=D1=A7=D1= =D0=BB=F9=B5=D83=C2=A5 > =D3=CA=B1=E0=A3=BA518057 > 3rd Floor, Nanjing University Research Center Shenzhen Branch, > NO.6 Yuexing 3rd Road, High Tech Park South, Nanshan > http://www.huawei.com >=20 > = ------------------------------------------------------------------------ >=20 > = =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7 > =D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2 > =C8=BA=D7=E9=A1=A3=BD=FB > = =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2 > =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9 > =B1=BE=D3=CA=BC=FE=D6=D0 > = =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2 > =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address = is > listed above. > Any use of the > information contained herein in any way (including, but not limited = to, total > or partial disclosure, reproduction, or dissemination) by persons = other than > the intended > recipient(s) is prohibited. If you receive this e-mail in error, = please notify the > sender by phone or email immediately and delete it! >=20 >=20 >=20 >=20 From pkyzivat@alum.mit.edu Wed Jul 3 09:17:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BC711E81DB for ; Wed, 3 Jul 2013 09:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.61 X-Spam-Level: ** X-Spam-Status: No, score=2.61 tagged_above=-999 required=5 tests=[AWL=-2.375, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTp9DkxzdTPn for ; Wed, 3 Jul 2013 09:17:49 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id DE94711E81D2 for ; Wed, 3 Jul 2013 09:17:48 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id vnpm1l0011wpRvQ54sHoGR; Wed, 03 Jul 2013 16:17:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id vsHo1l00J3ZTu2S3esHo5q; Wed, 03 Jul 2013 16:17:48 +0000 Message-ID: <51D44EAB.3010209@alum.mit.edu> Date: Wed, 03 Jul 2013 12:17:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> <51D43BBA.30600@alum.mit.edu> <010b01ce77ff$4aa7f490$dff7ddb0$@gmail.com> In-Reply-To: <010b01ce77ff$4aa7f490$dff7ddb0$@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372868268; bh=DqHzGcOxbydrWZieRFrpBJwR3XK3v0gpcn+nAI8rVYo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s44Jfd/Ae3e1fFHVYxeaekhPK5MrcLcXfIer0IdZVjSmat1/2e0snZ8XAqBQOTrnM DL2ka7aAbfc+LRcqzIhDFkzQrG6+qPaFG92JRBPQXwx+EDnbTc3hvQVPgVT5di+yNh iUSSuWyzlTwIk/u6LQVltXYxq3xEMPStqNgTnfiIpRrkwDd9lt4sCvHBEfHAjjvvFs Y+yAfREcKcB9JLTItmmzghIEGFo+z9M8Ul831mFoAcjb15JipUXTMzplP61VMuDPlC nuNcPTiEUxf+C2kcY2T8iJwXdShzv3M1obqjd9f6Wce5AdyE2vuZFakOPIMBqqqzs+ J2yPvVVCVnC4w== Cc: 'CLUE' Subject: Re: [clue] Signalling work on Telepresence in ITU-T X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 16:17:53 -0000 I know nothing more. It may mean nothing. Thanks, Paul On 7/3/13 11:09 AM, Roni Even wrote: > Hi Paul, > I do not know what is the outcome but this comes from ZTE, they do not > participate in the IETF work > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 03 July, 2013 5:57 PM >> To: CLUE >> Subject: [clue] Signalling work on Telepresence in ITU-T >> >> I think maybe ITU has gotten tired waiting for us! >> Another reason to start making progress on signaling. >> >> Thanks, >> Paul >> >> >> -------- Original Message -------- >> Subject: Signalling work on Telepresence in ITU-T >> Date: Wed, 3 Jul 2013 03:38:10 +0000 >> From: Xiaojing (Lennard) >> To: Paul Kyzivat >> CC: Yangweiwei (Tommy) , Liuyan (Scarlett) >> >> >> >> >> Hi Paul, >> >> >> >> In the last ITU-T SG16 WP1 rapporteur meeting, a proposal to start the > work >> on TP signalling was agreed. >> >> The original proposal can be found in the attachment. >> >> The agreement and support of this proposal was made during the meeting. >> >> The conclusion from the sumary report was: >> >> Contributions on signalling topics are solicited. Experts noted that some >> useful topics might be proposals for a signalling framework, RTP usage, >> protocol usage, potential signalling channels, and analysis of approaches > to >> integration the CLUE advertisement/configure methodology with H.323 >> capability exchange and negotiation. >> >> Experts felt that the 28 October – 08 November 2013 in Geneva, > Switzerland >> meeting would be a suitable time to launch new work items in this area. >> >> Thank you. >> >> >> >> Best regards, >> >> Lennard >> >> ------------------------------------------------------------------------ >> >> 肖晶Lennard Xiao >> 华为技术有限公司Huawei Technologies Co., Ltd. >> Company_logo >> >> Phone: 0755-36830241 >> Fax: 0755-36830194 >> Mobile: 13607111771 >> Email: lennard.xiao@huawei.com >> 地址：南山区科技园南区粤兴三道6号南京大学深圳产学研基地3楼 >> 邮编：518057 >> 3rd Floor, Nanjing University Research Center Shenzhen Branch, >> NO.6 Yuexing 3rd Road, High Tech Park South, Nanshan >> http://www.huawei.com >> >> ------------------------------------------------------------------------ >> >> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址 >> 中列出的个人或 >> 群组。禁 >> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、 >> 复制、或散发） >> 本邮件中 >> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并 >> 删除本邮件！ >> This e-mail and its attachments contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address is >> listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, > total >> or partial disclosure, reproduction, or dissemination) by persons other > than >> the intended >> recipient(s) is prohibited. If you receive this e-mail in error, please > notify the >> sender by phone or email immediately and delete it! >> >> >> >> > > > From coverdale@sympatico.ca Wed Jul 3 16:42:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A272211E80EC for ; Wed, 3 Jul 2013 16:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.245 X-Spam-Level: **** X-Spam-Status: No, score=4.245 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK1nu0HH3M-A for ; Wed, 3 Jul 2013 16:42:29 -0700 (PDT) Received: from blu0-omc1-s2.blu0.hotmail.com (blu0-omc1-s2.blu0.hotmail.com [65.55.116.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93721F9B7F for ; Wed, 3 Jul 2013 16:42:29 -0700 (PDT) Received: from BLU0-SMTP101 ([65.55.116.9]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 16:42:29 -0700 X-EIP: [+ANq2uray4XfRcn50piw2a8z6iDhPd6K] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([59.37.12.1]) by BLU0-SMTP101.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 16:42:26 -0700 From: Paul Coverdale To: "'Paul Kyzivat'" , "'Roni Even'" References: <8A527E21B95EF842BC0E952D6E8229774CE8F302@szxeml513-mbs.china.huawei.com> <51D43BBA.30600@alum.mit.edu> <010b01ce77ff$4aa7f490$dff7ddb0$@gmail.com> <51D44EAB.3010209@alum.mit.edu> In-Reply-To: <51D44EAB.3010209@alum.mit.edu> Date: Thu, 4 Jul 2013 07:42:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac54CONeZV6z9B4CS3a61yvw/3C7eQAPU+WA Content-Language: en-us X-OriginalArrivalTime: 03 Jul 2013 23:42:27.0034 (UTC) FILETIME=[F99023A0:01CE7846] Cc: 'CLUE' Subject: Re: [clue] Signalling work on Telepresence in ITU-T X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 23:42:35 -0000 It means what it says. There was general agreement and support for going ahead with Telepresence signalling work in ITU-T SG16, but no formal = work items have been initiated yet. It will depend on contributions at the = next (October) SG16 meeting. Hopefully, by then, there will be some progress = from CLUE. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Thursday, July 04, 2013 12:18 AM >To: Roni Even >Cc: 'CLUE' >Subject: Re: [clue] Signalling work on Telepresence in ITU-T > >I know nothing more. It may mean nothing. > > Thanks, > Paul > >On 7/3/13 11:09 AM, Roni Even wrote: >> Hi Paul, >> I do not know what is the outcome but this comes from ZTE, they do = not >> participate in the IETF work Roni >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 03 July, 2013 5:57 PM >>> To: CLUE >>> Subject: [clue] Signalling work on Telepresence in ITU-T >>> >>> I think maybe ITU has gotten tired waiting for us! >>> Another reason to start making progress on signaling. >>> >>> Thanks, >>> Paul >>> >>> >>> -------- Original Message -------- >>> Subject: Signalling work on Telepresence in ITU-T >>> Date: Wed, 3 Jul 2013 03:38:10 +0000 >>> From: Xiaojing (Lennard) >>> To: Paul Kyzivat >>> CC: Yangweiwei (Tommy) , Liuyan (Scarlett) >>> >>> >>> >>> >>> Hi Paul, >>> >>> >>> >>> In the last ITU-T SG16 WP1 rapporteur meeting, a proposal to start >>> the >> work >>> on TP signalling was agreed. >>> >>> The original proposal can be found in the attachment. >>> >>> The agreement and support of this proposal was made during the >meeting. >>> >>> The conclusion from the sumary report was: >>> >>> Contributions on signalling topics are solicited. Experts noted = that >>> some useful topics might be proposals for a signalling framework, = RTP >>> usage, protocol usage, potential signalling channels, and analysis = of >>> approaches >> to >>> integration the CLUE advertisement/configure methodology with H.323 >>> capability exchange and negotiation. >>> >>> Experts felt that the 28 October =A8C 08 November 2013 in Geneva, >> Switzerland >>> meeting would be a suitable time to launch new work items in this >area. >>> >>> Thank you. >>> >>> >>> >>> Best regards, >>> >>> Lennard >>> >>> = --------------------------------------------------------------------- >>> --- >>> >>> =D0=A4=BE=A7Lennard Xiao >>> =BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BEHuawei Technologies = Co., Ltd. >>> Company_logo >>> >>> Phone: 0755-36830241 >>> Fax: 0755-36830194 >>> Mobile: 13607111771 >>> Email: lennard.xiao@huawei.com >>> = =B5=D8=D6=B7=A3=BA=C4=CF=C9=BD=C7=F8=BF=C6=BC=BC=D4=B0=C4=CF=C7=F8=D4=C1=D0= =CB=C8=FD=B5=C06=BA=C5=C4=CF=BE=A9=B4=F3=D1=A7=C9=EE=DB=DA=B2=FA=D1=A7=D1= =D0=BB=F9=B5=D83=C2=A5 >>> =D3=CA=B1=E0=A3=BA518057 >>> 3rd Floor, Nanjing University Research Center Shenzhen Branch, >>> NO.6 Yuexing 3rd Road, High Tech Park South, Nanshan >>> http://www.huawei.com >>> >>> = --------------------------------------------------------------------- >>> --- >>> >>> = =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7 >>> =D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2 >>> =C8=BA=D7=E9=A1=A3=BD=FB >>> = =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2 >>> =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9 >>> =B1=BE=D3=CA=BC=FE=D6=D0 >>> = =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2 >>> =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 >>> This e-mail and its attachments contain confidential information = from >>> HUAWEI, which is intended only for the person or entity whose = address >>> is listed above. >>> Any use of the >>> information contained herein in any way (including, but not limited >>> to, >> total >>> or partial disclosure, reproduction, or dissemination) by persons >>> other >> than >>> the intended >>> recipient(s) is prohibited. If you receive this e-mail in error, >>> please >> notify the >>> sender by phone or email immediately and delete it! >>> >>> >>> >>> >> >> >> From roni.even@mail01.huawei.com Mon Jul 8 02:19:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7537621F99D3 for ; Mon, 8 Jul 2013 02:19:03 -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.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgHUhmH7RLCt for ; Mon, 8 Jul 2013 02:18:58 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id C1E1E21F8925 for ; Mon, 8 Jul 2013 02:18:23 -0700 (PDT) Received: from 172.24.1.79 (EHLO szxpml201-edg.exmail.huawei.com) ([172.24.1.79]) by szxrg12-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id BQN14825; Mon, 08 Jul 2013 17:18:07 +0800 (CST) From: Roni Even To: "wang.liang12@zte.com.cn" , "jonathan@vidyo.com" Thread-Topic: hi there, question about the static mapping in draft'http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5' Thread-Index: AQHOe7seKTc2nJ2qNEqRJzummXEePJlagEMq Date: Mon, 8 Jul 2013 09:18:04 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C2299A8E84@szxpml504-mbx.exmail.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: multipart/alternative; boundary="_000_760B7D45D1EFF74988DBF5C2122830C2299A8E84szxpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "clue@ietf.org" Subject: Re: [clue] hi there, question about the static mapping in draft'http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5' X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 09:19:11 -0000 --_000_760B7D45D1EFF74988DBF5C2122830C2299A8E84szxpml504mbxexm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The question is what is mapped, is it mapping of a specific SSRC and m-line= to the advertisement ,it will need to be mapped to captureID. Roni ________________________________ From: wang.liang12@zte.com.cn [wang.liang12@zte.com.cn] Sent: Monday, July 08, 2013 12:10 PM To: jonathan@vidyo.com; Roni Even Subject: hi there, question about the static mapping in draft'http://tools.= ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5' Hi there, I noticed that in the clue-rtp-mapping draft. you described a static mappin= g method and also gave the example quoted below: m=3Dvideo 49200 RTP/AVP 99 a=3Dextmap:1 urn:ietf:params:rtp-hdrex:clue-capture-id / for support of dynamic mapping a=3Drtpmap:99 H264/90000 a=3Dmax-send-ssrc:{*:6} a=3Dmax-recv-ssrc:{*:4} a=3Dssrc:11111 CaptureID:1 a=3Dssrc:22222 CaptureID:2 a=3Dssrc:33333 CaptureID:3 a=3Dssrc:44444 CaptureID:4 a=3Dssrc:55555 CaptureID:5 a=3Dssrc:66666 CaptureID:6 we can see the static mapping here is between the ssrc and CaptureID but no= t related whit the capture-encoding-ID. when the consumer wants to select one CaptureID but use different indivisu= al encoding it can't distinguish the streams from this kind of mapping. for example, the provider supports two different indivisual encodings(ENC0,= ENC1) with different bitrate, picture size and processed pixels rate in en= coding group0(EG0). The provide associate the media capture VC0 with EG0. The consumer wants th= e VC0 using both ENC0 and ENC1 simultaneously. in this case can we use the static mapping like this? Do we have other meat= hod to support this case? m=3Dvideo 49200 RTP/AVP 99 a=3Drtpmap:99 H264/90000 ... a=3Dssrc:11111 CaptureID:1 EncodingID:ENC0 a=3Dssrc:22222 CaptureID:1 EncodingID:ENC1 Thank you and Best regards, Liang -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --_000_760B7D45D1EFF74988DBF5C2122830C2299A8E84szxpml504mbxexm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

The question is what is mapped, is it mapping of a specific SSRC and m-l= ine to the advertisement ,it will need to be mapped to captureID.

Roni

From: wang.liang12@zte.com.cn [wang.liang1= 2@zte.com.cn]
Sent: Monday, July 08, 2013 12:10 PM
To: jonathan@vidyo.com; Roni Even
Subject: hi there, question about the static mapping in draft'http:/= /tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5'


Hi there,

I noticed that in the clue-rtp-mapping dr= aft. you described a static mapping method and also gave the example quoted= below:

      m=3Dvideo 49200 RTP/= AVP 99
      a=3Dextmap:1 urn:iet= f:params:rtp-hdrex:clue-capture-id / for support
      of dynamic mapping
      a=3Drtpmap:99 H264/9= 0000
      a=3Dmax-send-ssrc:{*= :6}
      a=3Dmax-recv-ssrc:{*= :4}
      a=3Dssrc:11111 Captu= reID:1
      a=3Dssrc:22222 Captu= reID:2
      a=3Dssrc:33333 Captu= reID:3
      a=3Dssrc:44444 Captu= reID:4
      a=3Dssrc:55555 Captu= reID:5
      a=3Dssrc:66666 Captu= reID:6

we can see the static mapping here is bet= ween the ssrc and CaptureID but not related whit the capture-encoding-ID.
when the consumer wants to select one Cap= tureID  but use different indivisual encoding it can't distinguish the= streams from this kind of mapping.
for example, the provider supports two di= fferent indivisual encodings(ENC0, ENC1) with different bitrate, picture si= ze and processed pixels rate in encoding group0(EG0).
The provide associate the media capture V= C0 with EG0. The consumer wants the VC0 using both ENC0 and ENC1 simultaneo= usly.
in this case can we use the static mappin= g like this? Do we have other meathod to support this case?

m=3Dvideo 49200 RTP/AVP 99
 a=3Drtpmap:99 H264/90000 ...
      a=3Dssrc:11111 Captu= reID:1 EncodingID:ENC0
      a=3Dssrc:22222 Captu= reID:1 EncodingID:ENC1


Thank you and Best regards,
Liang



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.

--_000_760B7D45D1EFF74988DBF5C2122830C2299A8E84szxpml504mbxexm_-- From pkyzivat@alum.mit.edu Mon Jul 8 07:52:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762921F9C75 for ; Mon, 8 Jul 2013 07:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-atmEkBK9jK for ; Mon, 8 Jul 2013 07:52:47 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id A101D21F9A98 for ; Mon, 8 Jul 2013 07:52:47 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id xnL01l0040cZkys5EqsV3Y; Mon, 08 Jul 2013 14:52:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id xqsU1l00q3ZTu2S3WqsUEu; Mon, 08 Jul 2013 14:52:29 +0000 Message-ID: <51DAD22B.2080005@alum.mit.edu> Date: Mon, 08 Jul 2013 10:52:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <760B7D45D1EFF74988DBF5C2122830C2299A8E84@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C2299A8E84@szxpml504-mbx.exmail.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373295149; bh=k/cKUZjYBWLL6hTbgnYwTaLAOA1Nf63GTFFcuKMPFzQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TAq73gmtSVLgct1eulB01HvCEOJAJHgDZa3LMXoyWV9wQdcDv/nIAqDVemomcJv2z B/X9ufqfgwr2EGb3ZjGRXfmm46FdJe3rmFBTrrcVMeZk+Q1HGBHeSmye4dEl087eX3 sx26X/N9phjdjv4HP7one33XxJj3ho3xrcTH1boY/bQYXINuXc5+j9t8fCV3BuePVb gMJlz20qq8l+pxGK4rG6oGsiWsPDW80BbLQy7BLu1lunq5AXUH2rRVriMpEGHpOQYf hke+jkWjj1Ax9ExyLsjYsRtD86gAdzf6Apohh0LfqJc3UXw3ErYmkAtHwF9209m7Uu ukSm6DwARprzA== Subject: Re: [clue] hi there, question about the static mapping in draft'http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5' X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 14:52:54 -0000 Roni, On 7/8/13 5:18 AM, Roni Even wrote: > Hi, > > The question is what is mapped, is it mapping of a specific SSRC and > m-line to the advertisement ,it will need to be mapped to captureID. This draft hasn't been updated recently, and it isn't clear if it will be consistent with whatever gets decided about bundling in MMUSIC. But I thought it was long settled that we need to map *capture-encodings* to RTP - that the same capture map be configured more than once, to different encoding, and each then needs to be correlated to the proper ssrc in RTP. I had suggested that we could get by with mapping the RTP to an encoding, since at any point in time that encoding will have been configured to at most one capture. (So, if you know the encoding you can look up what capture has been configured to it, and so discover the capture-encoding.) If we go with Rob's proposal to represent encodings as m-lines in SDP, then the RTP mapping can just be to a label/ID associated with that m-line. ISTM its time to update this draft. Thanks, Paul > Roni > > ------------------------------------------------------------------------ > *From:* wang.liang12@zte.com.cn [wang.liang12@zte.com.cn] > *Sent:* Monday, July 08, 2013 12:10 PM > *To:* jonathan@vidyo.com; Roni Even > *Subject:* hi there, question about the static mapping in > draft'http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5' > > > Hi there, > > I noticed that in the clue-rtp-mapping draft. you described a static > mapping method and also gave the example quoted below: > > m=video 49200 RTP/AVP 99 > a=extmap:1 urn:ietf:params:rtp-hdrex:clue-capture-id / for support > of dynamic mapping > a=rtpmap:99 H264/90000 > a=max-send-ssrc:{*:6} > a=max-recv-ssrc:{*:4} > a=ssrc:11111 CaptureID:1 > a=ssrc:22222 CaptureID:2 > a=ssrc:33333 CaptureID:3 > a=ssrc:44444 CaptureID:4 > a=ssrc:55555 CaptureID:5 > a=ssrc:66666 CaptureID:6 > > we can see the static mapping here is between the ssrc and CaptureID but > not related whit the capture-encoding-ID. > when the consumer wants to select one CaptureID but use different > indivisual encoding it can't distinguish the streams from this kind of > mapping. > for example, the provider supports two different indivisual > encodings(ENC0, ENC1) with different bitrate, picture size and processed > pixels rate in encoding group0(EG0). > The provide associate the media capture VC0 with EG0. The consumer wants > the VC0 using both ENC0 and ENC1 simultaneously. > in this case can we use the static mapping like this? Do we have other > meathod to support this case? > > m=video 49200 RTP/AVP 99 > a=rtpmap:99 H264/90000 > ... > a=ssrc:11111 CaptureID:1 EncodingID:ENC0 > a=ssrc:22222 CaptureID:1 EncodingID:ENC1 > > > Thank you and Best regards, > Liang > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Jul 8 11:36:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8C21F9C06 for ; Mon, 8 Jul 2013 11:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3+U1Z9cTPpg for ; Mon, 8 Jul 2013 11:36:34 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id B87A921F9C08 for ; Mon, 8 Jul 2013 11:36:26 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so2552133qeb.27 for ; Mon, 08 Jul 2013 11:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yM0+pHFXGsdVJt7g5cnwC4sxS5yGUMWrkupd/A+z+kc=; b=ZoKSRpQOFQW/uWmpwWDH5U6k0bFgNxVcTAII2oFC9DBGiUg9fGEta7Fv06l9owGBLq 5chrx9VJvZvyWi2BEErmIa1azsB9NencIBJJRCFU9Y7EF3heG/+/SD7Ki+g3ym4p1ynL IpGgbnkBO78LZfVb+i6AI1gzaibbTfBl41Kj39g09bE42bSffnxekN4nlmPupU3TVHR+ Uhkgm903Izy1l95VHQfq7JjfPvWyLhsKtcvXSbg8RUNX9/H0iRVFf5iRA2pvk3ShZiVy uyYYqavdbIpXH/YlhB5n1bhhlAPvWad4dYahicKAFrM/6D8Csmni2yNUIDVNtm6WaaPR dfaA== MIME-Version: 1.0 X-Received: by 10.224.119.69 with SMTP id y5mr18766110qaq.93.1373308586111; Mon, 08 Jul 2013 11:36:26 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 8 Jul 2013 11:36:26 -0700 (PDT) Date: Mon, 8 Jul 2013 13:36:26 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Adopting draft-presta-clue-data-model-schema as a WG document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 18:36:34 -0000 Hi all, As was discussed at the virtual interim on June 25th, there is a proposal for the WG to approve the adoption of draft-presta-clue-data-model-schema as a CLUE WG document: http://datatracker.ietf.org/doc/draft-presta-clue-data-model-schema/ Please respond "Yes" or "No" as to whether you believe the document should be adopted no later than Sunday July 14th, 2013, so the authors have time to submit as a WG document before the deadline, noting that there is a single deadline for IETF-87 (July 15th, 24:00 UTC). If you have specific comments on the document, PLEASE post those in a separate thread with an appropriate title to facilitate tracking. Thanks, Mary. Note: we are working on the minutes from the virtual interim and will post within the next 24 hours. From trac+clue@trac.tools.ietf.org Mon Jul 8 11:51:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212C21F96E9 for ; Mon, 8 Jul 2013 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJwgIXcPKWzd for ; Mon, 8 Jul 2013 11:51:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 66A9021F8904 for ; Mon, 8 Jul 2013 11:51:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:45565 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwGWu-0004z7-90; Mon, 08 Jul 2013 20:51:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: Christian.Groves@nteczone.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 18:51:20 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/32 Message-ID: <068.7723bbdf395a2eec161c36c2ae5ba581@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Christian.Groves@nteczone.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #32: Definitions of Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:51:54 -0000 #32: Definitions of Roles There are a number of places where the term "Role" is defined. We need to figure out which are most appropriate for CLUE. Note, this has also been discussed on DISPATCH WG mailing list: http://www.ietf.org/mail- archive/web/clue/current/msg02527.html Note: Component will be changed to data-model once that's a WG document. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | Christian.Groves@nteczone.com Type: task | Status: new Priority: critical | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 11:55:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0C21F9675 for ; Mon, 8 Jul 2013 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-1pvR49Qu3n for ; Mon, 8 Jul 2013 11:55:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3831A21F9590 for ; Mon, 8 Jul 2013 11:55:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:46205 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwGaQ-0005OP-HH; Mon, 08 Jul 2013 20:54:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 18:54:58 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/33 Message-ID: <068.1827f04e5c8a8012c9dfe1e6ac856283@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #33: Security for Framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:55:01 -0000 #33: Security for Framework document The security considerations for the framework need to be documented. Note, that the content should be based on the security threats identified in the requirements document (TBD) as well as any additional security threats related to the overall framework itself. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: critical | Milestone: Component: framework | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 11:58:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6421F9D40 for ; Mon, 8 Jul 2013 11:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9pShayKeFZl for ; Mon, 8 Jul 2013 11:58:29 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7A821F9D34 for ; Mon, 8 Jul 2013 11:58:29 -0700 (PDT) Received: from localhost ([127.0.0.1]:46686 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwGdm-00022X-Br; Mon, 08 Jul 2013 20:58:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 18:58:26 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/20#comment:1 Message-ID: <083.edce23ba1dccb1e64edfc386c9ca0cd8@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:58:30 -0000 #20: Action item vii: Rejecting Configure Changes (by mary.ietf.barnes@gmail.com): * owner: Andy Pepperell => mark.duckworth@polycom.com * priority: minor => major Old description: > Action item vii from 19-20 Sept. 2012 interim. > > Andy: Add text to Framework for rejecting Configure New description: Action item vii from 19-20 Sept. 2012 interim. Andy: Add text to Framework for rejecting Configure As discussed at virtual interim on May 21st, this needs to be mentioned in the framework, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. -- -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 11:59:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6A821F9D39 for ; Mon, 8 Jul 2013 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KNaM7inha7Q for ; Mon, 8 Jul 2013 11:59:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 027FF21F9D34 for ; Mon, 8 Jul 2013 11:59:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:46746 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwGeV-0002IR-Hg; Mon, 08 Jul 2013 20:59:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 18:59:11 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/20#comment:2 Message-ID: <083.ced705d2437250b3b091839293c1d63c@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:59:15 -0000 #20: Action item vii: Rejecting Configure Description changed by mary.ietf.barnes@gmail.com: Old description: > Action item vii from 19-20 Sept. 2012 interim. > > Andy: Add text to Framework for rejecting Configure > > As discussed at virtual interim on May 21st, this needs to be mentioned > in the framework, so that the subsequent actions can be described. (E.g., > does the prior configure remain in effect?) > > The details of how this is communicated belong in the solution. New description: Action item vii from 19-20 Sept. 2012 interim. Andy: Add text to Framework for rejecting Configure As discussed at virtual interim on May 21st, 2013: http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- interim-2013-clue-1 this needs to be mentioned in the framework, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. -- -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 12:05:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C315E21F9964 for ; Mon, 8 Jul 2013 12:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJcW+nZJ7eX8 for ; Mon, 8 Jul 2013 12:05:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3621F86DE for ; Mon, 8 Jul 2013 12:05:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:47732 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwGka-0007m7-5Q; Mon, 08 Jul 2013 21:05:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: christian.groves@nteczone.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 19:05:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/25#comment:1 Message-ID: <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: christian.groves@nteczone.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:05:37 -0000 #25: Advertisement: Complete "all" or "delta" Changes (by mary.ietf.barnes@gmail.com): * owner: draft-ietf-clue-framework@tools.ietf.org => christian.groves@nteczone.com * severity: - => Active WG Document Old description: > Issue a from 19-20 Sept. 2012 interim > > Need to decide whether advertisement is complete information "all" or > just a "delta" [Note: current framework is "all"] New description: Issue a from 19-20 Sept. 2012 interim Need to decide whether advertisement is complete information "all" or just a "delta" [Note: current framework is "all"] Issue was discussed again at May 21, 2013 interim: http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- interim-2013-clue-1 General sense that this is a solution issue. However, Christian doesn't necessarily agree. Action: Christian/Roni figure out if and where this should be addressed in FW. -- Comment: Ticket update to reflect new assignee and discussion from May 21st, 2013 interim. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | christian.groves@nteczone.com Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Jul 8 12:28:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857D421F9977 for ; Mon, 8 Jul 2013 12:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puk9zxyiZAw4 for ; Mon, 8 Jul 2013 12:28:43 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D645121F96EF for ; Mon, 8 Jul 2013 12:28:42 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so2481508qcx.21 for ; Mon, 08 Jul 2013 12:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WWtzslAtDrVa94gxC2b6G3DP6jRNa90+/wjkHEhvBds=; b=0pOS5YMrahfF0sXTB8XHnTNsoe9rOIC0T6ru+L8et9yIcNpi0Ah1ErRV5Ko1ug/Vwx ytt4+0J5s0MLP/Noy5caJTYOUsPst+EBw4QTmKhWis1ao/stz9woPDYkjqmKkNJn+aSU pGmZufqA82oG5QonpVxCk6xT2t92TfRbhIuSzphIhCl1NaengYzNuwaVbtPaNBCR8o+K KGrAfBddFEcrjFpuDPNc/FYCQRvVwLlogZmSvO6jeJ1WoHlkwEa8Qtx7oHUsS12s+ulW aCMuC+aojvjFk1ARNlsiPTW/aXx9AdVh/ZUeGNT42+r8keTj1kP/TzdI12qigT7o3uQG Pk0w== MIME-Version: 1.0 X-Received: by 10.224.119.69 with SMTP id y5mr18949858qaq.93.1373311722353; Mon, 08 Jul 2013 12:28:42 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 8 Jul 2013 12:28:42 -0700 (PDT) Date: Mon, 8 Jul 2013 14:28:42 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:28:43 -0000 The chairs would like to start a 3 week WGLC for draft-ietf-clue-telepresence-use-cases-05. Please post your review comments, including an indication as to whether you believe the document is ready to progress, no later than Sunday, July 28th, 2013 24:00 UTC. Thanks, Mary. From trac+clue@trac.tools.ietf.org Mon Jul 8 12:59:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5321F9DED for ; Mon, 8 Jul 2013 12:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A6A-VeVXCpo for ; Mon, 8 Jul 2013 12:59:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D264E21F9DEC for ; Mon, 8 Jul 2013 12:59:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:53001 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwHak-0004wU-TY; Mon, 08 Jul 2013 21:59:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 19:59:22 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/34 Message-ID: <068.af8e067d89686381df3799eef29348b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #34: Update Framework Examples X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:59:32 -0000 #34: Update Framework Examples Per the June 25, 2013 virtual interim, the examples in the framework need to be updated. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: minor | Milestone: Component: framework | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 13:00:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE721F93E5 for ; Mon, 8 Jul 2013 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea8jRn3Hs97P for ; Mon, 8 Jul 2013 13:00:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0E21F9473 for ; Mon, 8 Jul 2013 13:00:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:53135 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwHbo-0005kl-3u; Mon, 08 Jul 2013 22:00:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 20:00:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/35 Message-ID: <068.8b9edcb50384258a87a71b895fd195c1@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130708200034.00A0E21F9473@ietfa.amsl.com> Resent-Date: Mon, 8 Jul 2013 13:00:33 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #35: Ensure Framework and Data model terminology is consistent X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:00:34 -0000 #35: Ensure Framework and Data model terminology is consistent From the June 25th, 2013 virtual interim meeting. This action belongs to both the framework document and data model document. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: framework | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Jul 8 13:04:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0127B21F9A57 for ; Mon, 8 Jul 2013 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.637 X-Spam-Level: X-Spam-Status: No, score=-100.637 tagged_above=-999 required=5 tests=[AWL=-1.963, BAYES_00=-2.599, MIME_ASCII0=1.5, NULL_IN_BODY=2.425, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiAcpr-EqtM1 for ; Mon, 8 Jul 2013 13:04:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CE48B21F9A29 for ; Mon, 8 Jul 2013 13:04:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:53978 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UwHfi-00019M-8Y; Mon, 08 Jul 2013 22:04:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 08 Jul 2013 20:04:30 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/36 Message-ID: <068.6a5d03d7c6b40be36d09dfcce1dc9d11@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #36: Cleanup encoding parameters for pixels/sec (computational complexity) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:04:38 -0000 #36: Cleanup encoding parameters for pixels/sec (computational complexity) Clean up Encoding parameters for pixels/sec (computational complexity), should be independent of codec (e.g. H.264, H.265, 鈥) . Note, need input from WG. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Jul 8 14:04:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC13821F9E36 for ; Mon, 8 Jul 2013 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO+AKDCzfQ37 for ; Mon, 8 Jul 2013 14:04:45 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id AB11121F9E2A for ; Mon, 8 Jul 2013 14:04:37 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so2583304qea.21 for ; Mon, 08 Jul 2013 14:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=19JvM8LqNCb+/VpAt/mfvGZmmzMLGTkacLcV+AVmj08=; b=hGWW2/9Whfzt4yUj6A+gZy7JVGvhaGitcXeLNVb1XaRfjGyrblrz3AQBOByKa6ZodN TvuX2lBAeK/KEV2H3vqVjF8p43KcCZ5LpvTnNuR26xAHTWBOktOMIaWwdS16zlvxlaRY GpVxw9CHMKhjBhD7lI+zwVyqZ8hFH1fkmVGFPhYV6NLWqsFLC/3VUCXsH3AveaDZymy4 I5LW7wYcUwwG+2lL74Y1d3nbyGPfpCpkBjPbmNt/ASCW3UBIIpwp4eU0AnVo5uVwnAnQ GzBLISvbkUrhFLIhItNylW1hkQEy4JsE1NEi8YQA9RR1HByrwGJ+X8387/yZNHpzIsAB nOYg== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr18014552qeb.8.1373317477048; Mon, 08 Jul 2013 14:04:37 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 8 Jul 2013 14:04:36 -0700 (PDT) Date: Mon, 8 Jul 2013 16:04:36 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Minutes: CLUE WG virtual Interim - June 25, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 21:04:45 -0000 Hi all, The minutes from the interim meeting have been uploaded: http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 It was a tough meeting to minute, so if there are questions or comments, folks might find it helpful to listen to the recording (the link is in the minutes), as that's what I needed to do to piece together my chicken scratch notes with Paul's. Folks may have noticed that a number of new tickets were opened. These are just to track known issues. I'm finally starting to like the issue tracker, but we would still like to limit the addition of new tickets to the chairs, however, if document editors would find it helpful, please let the chairs know. Thanks, Mary. From pkyzivat@alum.mit.edu Mon Jul 8 15:09:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8421F9E8C for ; Mon, 8 Jul 2013 15:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLyijCtv6eOx for ; Mon, 8 Jul 2013 15:09:17 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id AF98E21F9E32 for ; Mon, 8 Jul 2013 15:09:17 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id xxzT1l0051YDfWL5Ay9G3B; Mon, 08 Jul 2013 22:09:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id xy9G1l00u3ZTu2S3gy9GUt; Mon, 08 Jul 2013 22:09:16 +0000 Message-ID: <51DB388B.4030103@alum.mit.edu> Date: Mon, 08 Jul 2013 18:09:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> In-Reply-To: <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373321356; bh=+xUDsEbFzAsCxvfmD6XV/8hadA2ExDKy29PZ6QOLUgI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZjLWKySLXMSZIFWO8VeWReSndo+vwWbfB/Jl0lYZg/ybrx5pZsFaHLQ0EKHzWcFKf Vbw0sFQRQrNBxJzoYPb9G/TNo0xpNWb8puJ48NUOXx9jArsMo1JzUuvQieSdeDNVvM cqlSJrwQbWc6GYdKBTV0D8iBxv8q0fzxPq28Vn1kbEZYpRYqgYfLZ81rSMuE69YwHN QEGeAbqR+nfbLXVKQEhTfHwiHHm+d2FFb76TchS74vC9CCBBggP6Gmo1+Etvn+4OLt +IP6HicUsuYV4LVcqkHTMYkw5ebXDmMCktwrHex6nDQqY1x0JIHZG8F+rdv7iDXf6f 8Fv2y6ik5hJqA== Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 22:09:22 -0000 (as individual) IMO this should be an issue for signaling, not the framework. I consider it a level of detail below what the framework needs to mention. Of course we don't yet have a *wg* signaling draft to target this to. Thanks, Paul On 7/8/13 3:05 PM, clue issue tracker wrote: > #25: Advertisement: Complete "all" or "delta" > > Changes (by mary.ietf.barnes@gmail.com): > > * owner: draft-ietf-clue-framework@tools.ietf.org => > christian.groves@nteczone.com > * severity: - => Active WG Document > > > Old description: > >> Issue a from 19-20 Sept. 2012 interim >> >> Need to decide whether advertisement is complete information "all" or >> just a "delta" [Note: current framework is "all"] > > New description: > > Issue a from 19-20 Sept. 2012 interim > > Need to decide whether advertisement is complete information "all" or just > a "delta" [Note: current framework is "all"] > > Issue was discussed again at May 21, 2013 interim: > http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- > interim-2013-clue-1 > General sense that this is a solution issue. However, Christian doesn't > necessarily agree. Action: Christian/Roni figure out if and where this > should be addressed in FW. > > -- > > Comment: > > Ticket update to reflect new assignee and discussion from May 21st, 2013 > interim. > From pkyzivat@alum.mit.edu Mon Jul 8 15:18:56 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FF321F9E6D for ; Mon, 8 Jul 2013 15:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArHVn33a3GJj for ; Mon, 8 Jul 2013 15:18:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A03A921F9E77 for ; Mon, 8 Jul 2013 15:18:49 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id xxzv1l0051HzFnQ55yJmdq; Mon, 08 Jul 2013 22:18:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id xyJm1l0073ZTu2S3ayJmic; Mon, 08 Jul 2013 22:18:46 +0000 Message-ID: <51DB3AC5.2080201@alum.mit.edu> Date: Mon, 08 Jul 2013 18:18:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373321926; bh=LJMjk49OxqOUX9DbkPrVMXsn/r2UtvMDWiNlLyK9KrQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GaQteM5DoboVvTXwu2IkOyJgjAEYdJMIh7BYpX62kJcJ/dHShlLAVBogyAcMLLXUg GodT0o0FqAKqPX9eH70gALhwipbIvWWvV6+vrIUz9AOEOXuolu2G3Gge5o3BrSJH2V pCPRDs4oRK7WUCEw4byfKNo0eQedbFFP+OIF9qqm5q/VsdPvBktBhJBpdPrq9Mk8zb wACALa8AOAXgg280e8IoUmHD1MwW3GNbObKcH9Al0sfnmbmk5FSk1SrN1yYHYZrvZ7 0FYuBXMLBhqU8dal+d5/r/1QFx9U2DSuvx9dxW/OdaO9GgQkOG9i5GvBZCQzX/JUiL mJAACQTU+jKJA== Cc: CLUE Subject: Re: [clue] Minutes: CLUE WG virtual Interim - June 25, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 22:18:57 -0000 Correction re signaling/solution: Paul *already* folded Rob's proposal in kyzivat-clue-signaling. But it hasn't been thoroughly integrated, or even sanity checked by Rob. More important - we haven't yet decided that we want to go this way. (That is captured as (7) in the notes.) Thanks, Paul On 7/8/13 5:04 PM, Mary Barnes wrote: > Hi all, > > The minutes from the interim meeting have been uploaded: > http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 > > It was a tough meeting to minute, so if there are questions or > comments, folks might find it helpful to listen to the recording (the > link is in the minutes), as that's what I needed to do to piece > together my chicken scratch notes with Paul's. > > Folks may have noticed that a number of new tickets were opened. These > are just to track known issues. I'm finally starting to like the issue > tracker, but we would still like to limit the addition of new tickets > to the chairs, however, if document editors would find it helpful, > please let the chairs know. > > Thanks, > Mary. > From mary.ietf.barnes@gmail.com Mon Jul 8 17:20:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1563E11E80EC for ; Mon, 8 Jul 2013 17:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqeSpANueol1 for ; Mon, 8 Jul 2013 17:20:54 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 77DF311E80EA for ; Mon, 8 Jul 2013 17:20:54 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so2703064qcw.30 for ; Mon, 08 Jul 2013 17:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iUTqfQzifa+xvWEey7WXPTw4Sgk1MMBGEQwTyX7VoPE=; b=Rk3rA+1dixF+kNfIvO3XpyMbfEJKlB6RKMUzBiphxpoAidbVtY7PfapjZ5gj/fj67R BE4vCHWjhMuRZXO6wW449iRvClxqCa3yYLUV5m2EQw3GbZmtnbrT2/PQw/4TSDRrYnbx XCdoZNUabZjPFAnQrdKiEzTkoIOGbgLKU3qKyRlsvc1UFd79rNe5MVYdxrteizTwYNVz m4MuSiXIzxt6hx6A/25GunFODaToeQiPYeTZ3Gnl3NP4qZ3pDBH+eHFrL0dCf+E6kmWs aVt05V5enFPG1jyjkZo2NFJMG2d1NV01Wd2N/kupOjc0lPNbmYyWQtD9xG88o6Nn9hG2 u28A== MIME-Version: 1.0 X-Received: by 10.229.163.4 with SMTP id y4mr4346683qcx.4.1373329247449; Mon, 08 Jul 2013 17:20:47 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 8 Jul 2013 17:20:47 -0700 (PDT) In-Reply-To: <51DB388B.4030103@alum.mit.edu> References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> <51DB388B.4030103@alum.mit.edu> Date: Mon, 8 Jul 2013 19:20:47 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 00:20:55 -0000 This issue is because Christian does not think it is just a signaling issue. Per the text in the ticket: " General sense that this is a solution issue. However, Christian doesn't necessarily agree. Action: Christian/Roni?figure out if and where this should be addressed in FW." Once we get consensus that it's not a FW issue, we can close and then open a new issue or just update this one. Mary. On Mon, Jul 8, 2013 at 5:09 PM, Paul Kyzivat wrote: > (as individual) > > IMO this should be an issue for signaling, not the framework. > I consider it a level of detail below what the framework needs to mention. > > Of course we don't yet have a *wg* signaling draft to target this to. > > Thanks, > Paul > > > On 7/8/13 3:05 PM, clue issue tracker wrote: >> >> #25: Advertisement: Complete "all" or "delta" >> >> Changes (by mary.ietf.barnes@gmail.com): >> >> * owner: draft-ietf-clue-framework@tools.ietf.org => >> christian.groves@nteczone.com >> * severity: - => Active WG Document >> >> >> Old description: >> >>> Issue a from 19-20 Sept. 2012 interim >>> >>> Need to decide whether advertisement is complete information "all" or >>> just a "delta" [Note: current framework is "all"] >> >> >> New description: >> >> Issue a from 19-20 Sept. 2012 interim >> >> Need to decide whether advertisement is complete information "all" or >> just >> a "delta" [Note: current framework is "all"] >> >> Issue was discussed again at May 21, 2013 interim: >> http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- >> interim-2013-clue-1 >> General sense that this is a solution issue. However, Christian doesn't >> necessarily agree. Action: Christian/Roni figure out if and where this >> should be addressed in FW. >> >> -- >> >> Comment: >> >> Ticket update to reflect new assignee and discussion from May 21st, 2013 >> interim. >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Jul 8 20:03:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5B11E810F for ; Mon, 8 Jul 2013 20:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7LcjM+1-Nmd for ; Mon, 8 Jul 2013 20:03:57 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id E4A1911E810D for ; Mon, 8 Jul 2013 20:03:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJN821F20QPz/2dsb2JhbAANTYM7R4MOvXmBNIMXAQEBBCMVGxsKARALGAICBRYLAgIJAwIBAgFFBg0BBwEBBYgNBaZpc5E4gSaNE4EyB4JUgRwDo3mIRYFf Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 12:33:56 +0930 Message-ID: <51DB7D96.8060208@nteczone.com> Date: Tue, 09 Jul 2013 13:03:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue issue tracker References: <068.7723bbdf395a2eec161c36c2ae5ba581@trac.tools.ietf.org> In-Reply-To: <068.7723bbdf395a2eec161c36c2ae5ba581@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] #32: Definitions of Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 03:03:58 -0000 Hello Mary, I've just submitted my draft on this: http://www.ietf.org/internet-drafts/draft-groves-clue-role-clarifications-00.txt The intention behind the draft is to discuss the various functions that people associate with "role" so that we can choose the appropriate function/s for CLUE. Regards, Christian On 9/07/2013 4:51 AM, clue issue tracker wrote: > #32: Definitions of Roles > > There are a number of places where the term "Role" is defined. We need > to figure out which are most appropriate for CLUE. Note, this has also > been discussed on DISPATCH WG mailing list: http://www.ietf.org/mail- > archive/web/clue/current/msg02527.html > > > Note: Component will be changed to data-model once that's a WG document. > From Christian.Groves@nteczone.com Mon Jul 8 20:16:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15821F9BB4 for ; Mon, 8 Jul 2013 20:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6PD5GAK6Uts for ; Mon, 8 Jul 2013 20:16:37 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 49EF211E8106 for ; Mon, 8 Jul 2013 20:16:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEqA21F20QPz/2dsb2JhbAANTYM7wU6BMoMXAQEBAwEBAQE1GxsKEQsYCRYPCQMCAQIBDwYwEwYCAQEFEodiAwkSpmyJTA2IUY0AgR4lgS8Wg1oDlWyOCohI Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 12:46:26 +0930 Message-ID: <51DB8087.1080507@nteczone.com> Date: Tue, 09 Jul 2013 13:16:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> <51DB388B.4030103@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 03:16:37 -0000 Hello Mary and Paul, I agree that the details need to be worked out in the signalling document. My comment was more related to that the framework should contain a short summary of what ever is worked out in the signalling document. It should be possible for someone to read the framework document and have an overview of how CLUE is used (including whether an all or delta approach is used). We can't add the summary until we figure out what we'll use in the signalling document. Regards, Christian On 9/07/2013 10:20 AM, Mary Barnes wrote: > This issue is because Christian does not think it is just a signaling > issue. Per the text in the ticket: > " General sense that this is a solution issue. However, Christian > doesn't necessarily agree. Action: Christian/Roni?figure out if and > where this should be addressed in FW." > > Once we get consensus that it's not a FW issue, we can close and then > open a new issue or just update this one. > > Mary. > > On Mon, Jul 8, 2013 at 5:09 PM, Paul Kyzivat wrote: >> (as individual) >> >> IMO this should be an issue for signaling, not the framework. >> I consider it a level of detail below what the framework needs to mention. >> >> Of course we don't yet have a *wg* signaling draft to target this to. >> >> Thanks, >> Paul >> >> >> On 7/8/13 3:05 PM, clue issue tracker wrote: >>> #25: Advertisement: Complete "all" or "delta" >>> >>> Changes (by mary.ietf.barnes@gmail.com): >>> >>> * owner: draft-ietf-clue-framework@tools.ietf.org => >>> christian.groves@nteczone.com >>> * severity: - => Active WG Document >>> >>> >>> Old description: >>> >>>> Issue a from 19-20 Sept. 2012 interim >>>> >>>> Need to decide whether advertisement is complete information "all" or >>>> just a "delta" [Note: current framework is "all"] >>> >>> New description: >>> >>> Issue a from 19-20 Sept. 2012 interim >>> >>> Need to decide whether advertisement is complete information "all" or >>> just >>> a "delta" [Note: current framework is "all"] >>> >>> Issue was discussed again at May 21, 2013 interim: >>> http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- >>> interim-2013-clue-1 >>> General sense that this is a solution issue. However, Christian doesn't >>> necessarily agree. Action: Christian/Roni figure out if and where this >>> should be addressed in FW. >>> >>> -- >>> >>> Comment: >>> >>> Ticket update to reflect new assignee and discussion from May 21st, 2013 >>> interim. >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Jul 8 20:24:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7F11E810C for ; Mon, 8 Jul 2013 20:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOTrfbw6Fl+O for ; Mon, 8 Jul 2013 20:24:10 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74411E8106 for ; Mon, 8 Jul 2013 20:24:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHeB21F20QPz/2dsb2JhbAANTYM7wU6BMoMXAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiBemZZIpj3IWg1oDmHyTQg Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 12:54:08 +0930 Message-ID: <51DB8252.2050105@nteczone.com> Date: Tue, 09 Jul 2013 13:24:02 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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] Adopting draft-presta-clue-data-model-schema as a WG document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 03:24:10 -0000 Hello Mary, YES but there are things (e.g. micPattern, aspect ratio) in the data model that are not described in the framework. I'd support it as a WG draft that aligns with the framework. Regards, Christian On 9/07/2013 4:36 AM, Mary Barnes wrote: > Hi all, > > As was discussed at the virtual interim on June 25th, there is a > proposal for the WG to approve the adoption of > draft-presta-clue-data-model-schema as a CLUE WG document: > http://datatracker.ietf.org/doc/draft-presta-clue-data-model-schema/ > > Please respond "Yes" or "No" as to whether you believe the document > should be adopted no later than Sunday July 14th, 2013, so the authors > have time to submit as a WG document before the deadline, noting that > there is a single deadline for IETF-87 (July 15th, 24:00 UTC). > > If you have specific comments on the document, PLEASE post those in a > separate thread with an appropriate title to facilitate tracking. > > Thanks, > Mary. > > > Note: we are working on the minutes from the virtual interim and will > post within the next 24 hours. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From wang.liang12@zte.com.cn Mon Jul 8 20:37:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CED11E8112; Mon, 8 Jul 2013 20:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.497 X-Spam-Level: X-Spam-Status: No, score=-94.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPAonp9mrKjo; Mon, 8 Jul 2013 20:37:03 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 989A611E8113; Mon, 8 Jul 2013 20:37:02 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 09A2E12F11A6; Tue, 9 Jul 2013 11:36:35 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 415CB703418; Tue, 9 Jul 2013 11:36:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r693aQqw091484; Tue, 9 Jul 2013 11:36:26 +0800 (GMT-8) (envelope-from wang.liang12@zte.com.cn) In-Reply-To: To: clue@ietf.org Cc: clue@ietf.org, clue-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.liang12@zte.com.cn Date: Tue, 9 Jul 2013 11:36:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-09 11:36:24, Serialize complete at 2013-07-09 11:36:24 Content-Type: multipart/alternative; boundary="=_alternative 0013D53948257BA3_=" X-MAIL: mse02.zte.com.cn r693aQqw091484 Subject: [clue] about encoding a single Media Capture into multiple different Capture Encodings simultaniously and mapping X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 03:37:07 -0000 This is a multipart message in MIME format. --=_alternative 0013D53948257BA3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgdGhlcmUsDQoNCmZyYW1ld29yayBzZWN0aW9uIDggZGVzY2liZXMgb25lIHJlcXVpcmVtZW50 Og0KIA0KICAgSWYgdGhlcmUgYXJlIG11bHRpcGxlIEluZGl2aWR1YWwgRW5jb2RpbmdzIGluIHRo ZSBncm91cCwgdGhlbiB0aGUNCiAgIENvbnN1bWVyIGNhbiBjb25maWd1cmUgdGhlIFByb3ZpZGVy LCB2aWEgYSBDb25maWd1cmUgbWVzc2FnZSwgdG8NCiAgIGVuY29kZSBhIHNpbmdsZSBNZWRpYSBD YXB0dXJlIGludG8gbXVsdGlwbGUgZGlmZmVyZW50IENhcHR1cmUNCiAgIEVuY29kaW5ncyBhdCB0 aGUgc2FtZSB0aW1lLCBzdWJqZWN0IHRvIHRoZSBNYXggQ2FwdHVyZSBFbmNvZGluZ3MNCiAgIGNv bnN0cmFpbnQsIHdpdGggZWFjaCBjYXB0dXJlIGVuY29kaW5nIGZvbGxvd2luZyB0aGUgY29uc3Ry YWludHMgb2YNCiAgIGEgZGlmZmVyZW50IEluZGl2aWR1YWwgRW5jb2RpbmcuDQoNCiBpbiB3aGF0 IHNpdHVhdGlvbiB0aGUgY29uc3VtZXIgbmVlZHMgdGhlIHNhbWUgbWVkaWEgY2FwdHVyZSBpbiBk aWZmZXJlbnQgDQppbmRpdmlkdWFsIGVuY29kaW5ncyBzaW11bHRhbmlvdXNseT8NCg0KYW5kIGFi b3V0IHRoZSBtYXBwaW5nIGlzIHRoYXQgYmV0dGVyIGlmIHdlIHVzZSBhbiBhZGRpdGlvbmFsIGRl bXVsdGlwbGV4SUQgDQp3aGljaCBpcyBmcm9tIGNhcHR1cmVJRC1lbmNvZGluZ0lELg0KYmVjYXVz ZSBpbiB0aGUgZHluYW1pYyBtYXBwaW5nIG1ldGhvZCBsaWtlIFJUUCBoZWFkIGV4dGVudGlvbiBp ZiB3ZSB1c2UgDQptdWx0aXBsZXhJRCB3ZSBvbmx5IG5lZWQgb25lIFJUUCBleHRlbnRpb24uIA0K QnV0IGlmIHdlIHVzZSB0d28gZmllbGRzKGNhcHR1cmVJRC1lbmNvZGluZ0lEKSBpdCB3aWxsIHRh a2UgdHdvIA0KZXh0ZW50aW9ucy4NCnRoZSBjb25zdW1lciBjYW4gY29uZmlndXJlIHRoZSBkZW11 bHRpcGxleElEIGluIHRoZSBjb25maWd1cmUgbWVzc2FnZS4NCg0KDQpUaGFuayB5b3UgYW5kIEJl c3QgcmVnYXJkcywNCkxpYW5nDQoNCg0KDQoNCg0KY2x1ZS1yZXF1ZXN0QGlldGYub3JnIA0Kt6K8 /sjLOiAgY2x1ZS1ib3VuY2VzQGlldGYub3JnDQoyMDEzLzA3LzA5IDAyOjU4DQrH67TwuLQguPgN CmNsdWVAaWV0Zi5vcmcNCg0KDQrK1bz+yMsNCmNsdWVAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0K Y2x1ZSBEaWdlc3QsIFZvbCAzMiwgSXNzdWUgNA0KDQoNCg0KDQoNCg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0KYXR0 YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5 b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0byANCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCkNsaWNrIHRoZSAnVW5zdWJzY3JpYmUg b3IgZWRpdCBvcHRpb25zJyBidXR0b24sIGxvZyBpbiwgYW5kIHNldCAiR2V0DQpNSU1FIG9yIFBs YWluIFRleHQgRGlnZXN0cz8iIHRvIE1JTUUuICBZb3UgY2FuIHNldCB0aGlzIG9wdGlvbg0KZ2xv YmFsbHkgZm9yIGFsbCB0aGUgbGlzdCBkaWdlc3RzIHlvdSByZWNlaXZlIGF0IHRoaXMgcG9pbnQu DQoNCg0KDQpTZW5kIGNsdWUgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQogICAgICAgICAg ICAgICAgIGNsdWVAaWV0Zi5vcmcNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0 aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQogICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3Nh Z2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQogICAgICAgICAgICAgICAgIGNsdWUt cmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhl IGxpc3QgYXQNCiAgICAgICAgICAgICAgICAgY2x1ZS1vd25lckBpZXRmLm9yZw0KDQpXaGVuIHJl cGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNp ZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgY2x1ZSBkaWdlc3QuLi4iDQpUb2RheSdzIFRvcGlj czoNCg0KICAgMS4gUmU6IGhpIHRoZXJlLCBxdWVzdGlvbiBhYm91dCB0aGUgc3RhdGljIG1hcHBp bmcgaW4NCiANCmRyYWZ0J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1 ZS1ydHAtbWFwcGluZy0wMCNzZWN0aW9uLTQuNScNCiAgICAgIChSb25pIEV2ZW4pDQogICAyLiBS ZTogaGkgdGhlcmUsIHF1ZXN0aW9uIGFib3V0IHRoZSBzdGF0aWMgbWFwcGluZyBpbg0KIA0KZHJh ZnQnaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5n LTAwI3NlY3Rpb24tNC41Jw0KICAgICAgKFBhdWwgS3l6aXZhdCkNCiAgIDMuIEFkb3B0aW5nIGRy YWZ0LXByZXN0YS1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hIGFzIGEgV0cgZG9jdW1lbnQNCiAgICAg IChNYXJ5IEJhcm5lcykNCiAgIDQuICAjMzI6IERlZmluaXRpb25zIG9mIFJvbGVzIChjbHVlIGlz c3VlIHRyYWNrZXIpDQogICA1LiAgIzMzOiBTZWN1cml0eSBmb3IgRnJhbWV3b3JrIGRvY3VtZW50 IChjbHVlIGlzc3VlIHRyYWNrZXIpDQogICA2LiBSZTogIzIwOiBBY3Rpb24gaXRlbSB2aWk6ICBS ZWplY3RpbmcgQ29uZmlndXJlDQogICAgICAoY2x1ZSBpc3N1ZSB0cmFja2VyKQ0KDQoNCi0tLS0t IE1lc3NhZ2UgZnJvbSBSb25pIEV2ZW4gPHJvbmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNvbT4gb24g TW9uLCA4IEp1bCANCjIwMTMgMDk6MTg6MDQgKzAwMDAgLS0tLS0NClRvOg0KIndhbmcubGlhbmcx MkB6dGUuY29tLmNuIiA8d2FuZy5saWFuZzEyQHp0ZS5jb20uY24+LCAiam9uYXRoYW5AdmlkeW8u Y29tIiANCjxqb25hdGhhbkB2aWR5by5jb20+DQpjYzoNCiJjbHVlQGlldGYub3JnIiA8Y2x1ZUBp ZXRmLm9yZz4NClN1YmplY3Q6DQpSZTogW2NsdWVdIGhpIHRoZXJlLCBxdWVzdGlvbiBhYm91dCB0 aGUgc3RhdGljIG1hcHBpbmcgaW4gDQpkcmFmdCdodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMDAjc2VjdGlvbi00LjUnDQoNCkhpLA0KVGhlIHF1 ZXN0aW9uIGlzIHdoYXQgaXMgbWFwcGVkLCBpcyBpdCBtYXBwaW5nIG9mIGEgc3BlY2lmaWMgU1NS QyBhbmQgDQptLWxpbmUgdG8gdGhlIGFkdmVydGlzZW1lbnQgLGl0IHdpbGwgbmVlZCB0byBiZSBt YXBwZWQgdG8gY2FwdHVyZUlELiANClJvbmkNCg0KRnJvbTogd2FuZy5saWFuZzEyQHp0ZS5jb20u Y24gW3dhbmcubGlhbmcxMkB6dGUuY29tLmNuXQ0KU2VudDogTW9uZGF5LCBKdWx5IDA4LCAyMDEz IDEyOjEwIFBNDQpUbzogam9uYXRoYW5AdmlkeW8uY29tOyBSb25pIEV2ZW4NClN1YmplY3Q6IGhp IHRoZXJlLCBxdWVzdGlvbiBhYm91dCB0aGUgc3RhdGljIG1hcHBpbmcgaW4gDQpkcmFmdCdodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMDAjc2Vj dGlvbi00LjUnDQoNCg0KDQpIaSB0aGVyZSwgDQoNCkkgbm90aWNlZCB0aGF0IGluIHRoZSBjbHVl LXJ0cC1tYXBwaW5nIGRyYWZ0LiB5b3UgZGVzY3JpYmVkIGEgc3RhdGljIA0KbWFwcGluZyBtZXRo b2QgYW5kIGFsc28gZ2F2ZSB0aGUgZXhhbXBsZSBxdW90ZWQgYmVsb3c6IA0KDQogICAgICBtPXZp ZGVvIDQ5MjAwIFJUUC9BVlAgOTkgDQogICAgICBhPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpy dHAtaGRyZXg6Y2x1ZS1jYXB0dXJlLWlkIC8gZm9yIHN1cHBvcnQgDQogICAgICBvZiBkeW5hbWlj IG1hcHBpbmcgDQogICAgICBhPXJ0cG1hcDo5OSBIMjY0LzkwMDAwIA0KICAgICAgYT1tYXgtc2Vu ZC1zc3JjOnsqOjZ9IA0KICAgICAgYT1tYXgtcmVjdi1zc3JjOnsqOjR9IA0KICAgICAgYT1zc3Jj OjExMTExIENhcHR1cmVJRDoxIA0KICAgICAgYT1zc3JjOjIyMjIyIENhcHR1cmVJRDoyIA0KICAg ICAgYT1zc3JjOjMzMzMzIENhcHR1cmVJRDozIA0KICAgICAgYT1zc3JjOjQ0NDQ0IENhcHR1cmVJ RDo0IA0KICAgICAgYT1zc3JjOjU1NTU1IENhcHR1cmVJRDo1IA0KICAgICAgYT1zc3JjOjY2NjY2 IENhcHR1cmVJRDo2IA0KDQp3ZSBjYW4gc2VlIHRoZSBzdGF0aWMgbWFwcGluZyBoZXJlIGlzIGJl dHdlZW4gdGhlIHNzcmMgYW5kIENhcHR1cmVJRCBidXQgDQpub3QgcmVsYXRlZCB3aGl0IHRoZSBj YXB0dXJlLWVuY29kaW5nLUlELiANCndoZW4gdGhlIGNvbnN1bWVyIHdhbnRzIHRvIHNlbGVjdCBv bmUgQ2FwdHVyZUlEICBidXQgdXNlIGRpZmZlcmVudCANCmluZGl2aXN1YWwgZW5jb2RpbmcgaXQg Y2FuJ3QgZGlzdGluZ3Vpc2ggdGhlIHN0cmVhbXMgZnJvbSB0aGlzIGtpbmQgb2YgDQptYXBwaW5n LiANCmZvciBleGFtcGxlLCB0aGUgcHJvdmlkZXIgc3VwcG9ydHMgdHdvIGRpZmZlcmVudCBpbmRp dmlzdWFsIA0KZW5jb2RpbmdzKEVOQzAsIEVOQzEpIHdpdGggZGlmZmVyZW50IGJpdHJhdGUsIHBp Y3R1cmUgc2l6ZSBhbmQgcHJvY2Vzc2VkIA0KcGl4ZWxzIHJhdGUgaW4gZW5jb2RpbmcgZ3JvdXAw KEVHMCkuIA0KVGhlIHByb3ZpZGUgYXNzb2NpYXRlIHRoZSBtZWRpYSBjYXB0dXJlIFZDMCB3aXRo IEVHMC4gVGhlIGNvbnN1bWVyIHdhbnRzIA0KdGhlIFZDMCB1c2luZyBib3RoIEVOQzAgYW5kIEVO QzEgc2ltdWx0YW5lb3VzbHkuIA0KaW4gdGhpcyBjYXNlIGNhbiB3ZSB1c2UgdGhlIHN0YXRpYyBt YXBwaW5nIGxpa2UgdGhpcz8gRG8gd2UgaGF2ZSBvdGhlciANCm1lYXRob2QgdG8gc3VwcG9ydCB0 aGlzIGNhc2U/IA0KDQptPXZpZGVvIDQ5MjAwIFJUUC9BVlAgOTkgDQogYT1ydHBtYXA6OTkgSDI2 NC85MDAwMCANCi4uLiANCiAgICAgIGE9c3NyYzoxMTExMSBDYXB0dXJlSUQ6MSBFbmNvZGluZ0lE OkVOQzAgDQogICAgICBhPXNzcmM6MjIyMjIgQ2FwdHVyZUlEOjEgRW5jb2RpbmdJRDpFTkMxIA0K DQoNClRoYW5rIHlvdSBhbmQgQmVzdCByZWdhcmRzLA0KTGlhbmcNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IA0KYW4gaW50ZW5kZWQg cmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig b3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgDQppbW1lZGlhdGVseS4N Cg0KDQoNCg0KLS0tLS0gTWVzc2FnZSBmcm9tIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5t aXQuZWR1PiBvbiBNb24sIDA4IEp1bCANCjIwMTMgMTA6NTI6MjcgLTA0MDAgLS0tLS0NClRvOg0K Y2x1ZUBpZXRmLm9yZw0KU3ViamVjdDoNClJlOiBbY2x1ZV0gaGkgdGhlcmUsIHF1ZXN0aW9uIGFi b3V0IHRoZSBzdGF0aWMgbWFwcGluZyBpbiANCmRyYWZ0J2h0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0wMCNzZWN0aW9uLTQuNScNCg0KUm9uaSwN Cg0KT24gNy84LzEzIDU6MTggQU0sIFJvbmkgRXZlbiB3cm90ZToNCj4gSGksDQo+DQo+IFRoZSBx dWVzdGlvbiBpcyB3aGF0IGlzIG1hcHBlZCwgaXMgaXQgbWFwcGluZyBvZiBhIHNwZWNpZmljIFNT UkMgYW5kDQo+IG0tbGluZSB0byB0aGUgYWR2ZXJ0aXNlbWVudCAsaXQgd2lsbCBuZWVkIHRvIGJl IG1hcHBlZCB0byBjYXB0dXJlSUQuDQoNClRoaXMgZHJhZnQgaGFzbid0IGJlZW4gdXBkYXRlZCBy ZWNlbnRseSwgYW5kIGl0IGlzbid0IGNsZWFyIGlmIGl0IHdpbGwgDQpiZSBjb25zaXN0ZW50IHdp dGggd2hhdGV2ZXIgZ2V0cyBkZWNpZGVkIGFib3V0IGJ1bmRsaW5nIGluIE1NVVNJQy4gQnV0IEkg DQp0aG91Z2h0IGl0IHdhcyBsb25nIHNldHRsZWQgdGhhdCB3ZSBuZWVkIHRvIG1hcCAqY2FwdHVy ZS1lbmNvZGluZ3MqIHRvIA0KUlRQIC0gdGhhdCB0aGUgc2FtZSBjYXB0dXJlIG1hcCBiZSBjb25m aWd1cmVkIG1vcmUgdGhhbiBvbmNlLCB0byANCmRpZmZlcmVudCBlbmNvZGluZywgYW5kIGVhY2gg dGhlbiBuZWVkcyB0byBiZSBjb3JyZWxhdGVkIHRvIHRoZSBwcm9wZXIgDQpzc3JjIGluIFJUUC4N Cg0KSSBoYWQgc3VnZ2VzdGVkIHRoYXQgd2UgY291bGQgZ2V0IGJ5IHdpdGggbWFwcGluZyB0aGUg UlRQIHRvIGFuIA0KZW5jb2RpbmcsIHNpbmNlIGF0IGFueSBwb2ludCBpbiB0aW1lIHRoYXQgZW5j b2Rpbmcgd2lsbCBoYXZlIGJlZW4gDQpjb25maWd1cmVkIHRvIGF0IG1vc3Qgb25lIGNhcHR1cmUu IChTbywgaWYgeW91IGtub3cgdGhlIGVuY29kaW5nIHlvdSBjYW4gDQpsb29rIHVwIHdoYXQgY2Fw dHVyZSBoYXMgYmVlbiBjb25maWd1cmVkIHRvIGl0LCBhbmQgc28gZGlzY292ZXIgdGhlIA0KY2Fw dHVyZS1lbmNvZGluZy4pDQoNCklmIHdlIGdvIHdpdGggUm9iJ3MgcHJvcG9zYWwgdG8gcmVwcmVz ZW50IGVuY29kaW5ncyBhcyBtLWxpbmVzIGluIFNEUCwgDQp0aGVuIHRoZSBSVFAgbWFwcGluZyBj YW4ganVzdCBiZSB0byBhIGxhYmVsL0lEIGFzc29jaWF0ZWQgd2l0aCB0aGF0IA0KbS1saW5lLg0K DQpJU1RNIGl0cyB0aW1lIHRvIHVwZGF0ZSB0aGlzIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAg IFRoYW5rcywNCiAgICAgICAgICAgICAgICAgUGF1bA0KDQo+IFJvbmkNCj4NCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ICpGcm9tOiogd2FuZy5saWFuZzEyQHp0ZS5jb20uY24gW3dhbmcubGlhbmcxMkB6 dGUuY29tLmNuXQ0KPiAqU2VudDoqIE1vbmRheSwgSnVseSAwOCwgMjAxMyAxMjoxMCBQTQ0KPiAq VG86KiBqb25hdGhhbkB2aWR5by5jb207IFJvbmkgRXZlbg0KPiAqU3ViamVjdDoqIGhpIHRoZXJl LCBxdWVzdGlvbiBhYm91dCB0aGUgc3RhdGljIG1hcHBpbmcgaW4NCj4gDQpkcmFmdCdodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMDAjc2VjdGlv bi00LjUnDQo+DQo+DQo+IEhpIHRoZXJlLA0KPg0KPiBJIG5vdGljZWQgdGhhdCBpbiB0aGUgY2x1 ZS1ydHAtbWFwcGluZyBkcmFmdC4geW91IGRlc2NyaWJlZCBhIHN0YXRpYw0KPiBtYXBwaW5nIG1l dGhvZCBhbmQgYWxzbyBnYXZlIHRoZSBleGFtcGxlIHF1b3RlZCBiZWxvdzoNCj4NCj4gICAgICAg IG09dmlkZW8gNDkyMDAgUlRQL0FWUCA5OQ0KPiAgICAgICAgYT1leHRtYXA6MSB1cm46aWV0Zjpw YXJhbXM6cnRwLWhkcmV4OmNsdWUtY2FwdHVyZS1pZCAvIGZvciANCnN1cHBvcnQNCj4gICAgICAg IG9mIGR5bmFtaWMgbWFwcGluZw0KPiAgICAgICAgYT1ydHBtYXA6OTkgSDI2NC85MDAwMA0KPiAg ICAgICAgYT1tYXgtc2VuZC1zc3JjOnsqOjZ9DQo+ICAgICAgICBhPW1heC1yZWN2LXNzcmM6eyo6 NH0NCj4gICAgICAgIGE9c3NyYzoxMTExMSBDYXB0dXJlSUQ6MQ0KPiAgICAgICAgYT1zc3JjOjIy MjIyIENhcHR1cmVJRDoyDQo+ICAgICAgICBhPXNzcmM6MzMzMzMgQ2FwdHVyZUlEOjMNCj4gICAg ICAgIGE9c3NyYzo0NDQ0NCBDYXB0dXJlSUQ6NA0KPiAgICAgICAgYT1zc3JjOjU1NTU1IENhcHR1 cmVJRDo1DQo+ICAgICAgICBhPXNzcmM6NjY2NjYgQ2FwdHVyZUlEOjYNCj4NCj4gd2UgY2FuIHNl ZSB0aGUgc3RhdGljIG1hcHBpbmcgaGVyZSBpcyBiZXR3ZWVuIHRoZSBzc3JjIGFuZCBDYXB0dXJl SUQgYnV0DQo+IG5vdCByZWxhdGVkIHdoaXQgdGhlIGNhcHR1cmUtZW5jb2RpbmctSUQuDQo+IHdo ZW4gdGhlIGNvbnN1bWVyIHdhbnRzIHRvIHNlbGVjdCBvbmUgQ2FwdHVyZUlEICBidXQgdXNlIGRp ZmZlcmVudA0KPiBpbmRpdmlzdWFsIGVuY29kaW5nIGl0IGNhbid0IGRpc3Rpbmd1aXNoIHRoZSBz dHJlYW1zIGZyb20gdGhpcyBraW5kIG9mDQo+IG1hcHBpbmcuDQo+IGZvciBleGFtcGxlLCB0aGUg cHJvdmlkZXIgc3VwcG9ydHMgdHdvIGRpZmZlcmVudCBpbmRpdmlzdWFsDQo+IGVuY29kaW5ncyhF TkMwLCBFTkMxKSB3aXRoIGRpZmZlcmVudCBiaXRyYXRlLCBwaWN0dXJlIHNpemUgYW5kIHByb2Nl c3NlZA0KPiBwaXhlbHMgcmF0ZSBpbiBlbmNvZGluZyBncm91cDAoRUcwKS4NCj4gVGhlIHByb3Zp ZGUgYXNzb2NpYXRlIHRoZSBtZWRpYSBjYXB0dXJlIFZDMCB3aXRoIEVHMC4gVGhlIGNvbnN1bWVy IHdhbnRzDQo+IHRoZSBWQzAgdXNpbmcgYm90aCBFTkMwIGFuZCBFTkMxIHNpbXVsdGFuZW91c2x5 Lg0KPiBpbiB0aGlzIGNhc2UgY2FuIHdlIHVzZSB0aGUgc3RhdGljIG1hcHBpbmcgbGlrZSB0aGlz PyBEbyB3ZSBoYXZlIG90aGVyDQo+IG1lYXRob2QgdG8gc3VwcG9ydCB0aGlzIGNhc2U/DQo+DQo+ IG09dmlkZW8gNDkyMDAgUlRQL0FWUCA5OQ0KPiAgIGE9cnRwbWFwOjk5IEgyNjQvOTAwMDANCj4g Li4uDQo+ICAgICAgICBhPXNzcmM6MTExMTEgQ2FwdHVyZUlEOjEgRW5jb2RpbmdJRDpFTkMwDQo+ ICAgICAgICBhPXNzcmM6MjIyMjIgQ2FwdHVyZUlEOjEgRW5jb2RpbmdJRDpFTkMxDQo+DQo+DQo+ IFRoYW5rIHlvdSBhbmQgQmVzdCByZWdhcmRzLA0KPiBMaWFuZw0KPg0KPg0KPg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlz IHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IA0KYW4gaW50 ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgDQppbW1lZGlh dGVseS4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4NCg0KDQoNCg0KLS0tLS0g TWVzc2FnZSBmcm9tIE1hcnkgQmFybmVzIDxtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4gb24g TW9uLCA4IEp1bCANCjIwMTMgMTM6MzY6MjYgLTA1MDAgLS0tLS0NClRvOg0KQ0xVRSA8Y2x1ZUBp ZXRmLm9yZz4NClN1YmplY3Q6DQpbY2x1ZV0gQWRvcHRpbmcgZHJhZnQtcHJlc3RhLWNsdWUtZGF0 YS1tb2RlbC1zY2hlbWEgYXMgYSBXRyBkb2N1bWVudA0KDQpIaSBhbGwsDQoNCkFzIHdhcyBkaXNj dXNzZWQgYXQgdGhlIHZpcnR1YWwgaW50ZXJpbSBvbiBKdW5lIDI1dGgsIHRoZXJlIGlzIGENCnBy b3Bvc2FsIGZvciB0aGUgV0cgdG8gYXBwcm92ZSB0aGUgYWRvcHRpb24gb2YNCmRyYWZ0LXByZXN0 YS1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hIGFzIGEgQ0xVRSBXRyBkb2N1bWVudDoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHJlc3RhLWNsdWUtZGF0YS1tb2RlbC1zY2hl bWEvDQoNClBsZWFzZSByZXNwb25kICJZZXMiIG9yICJObyIgYXMgdG8gd2hldGhlciB5b3UgYmVs aWV2ZSB0aGUgZG9jdW1lbnQNCnNob3VsZCBiZSBhZG9wdGVkIG5vIGxhdGVyIHRoYW4gU3VuZGF5 IEp1bHkgMTR0aCwgMjAxMywgc28gdGhlIGF1dGhvcnMNCmhhdmUgdGltZSB0byBzdWJtaXQgYXMg YSBXRyBkb2N1bWVudCBiZWZvcmUgdGhlIGRlYWRsaW5lLCBub3RpbmcgdGhhdA0KdGhlcmUgaXMg YSBzaW5nbGUgZGVhZGxpbmUgZm9yIElFVEYtODcgKEp1bHkgMTV0aCwgMjQ6MDAgVVRDKS4NCg0K SWYgeW91IGhhdmUgc3BlY2lmaWMgY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBQTEVBU0UgcG9z dCB0aG9zZSBpbiBhDQpzZXBhcmF0ZSB0aHJlYWQgd2l0aCBhbiBhcHByb3ByaWF0ZSB0aXRsZSB0 byBmYWNpbGl0YXRlIHRyYWNraW5nLg0KDQpUaGFua3MsDQpNYXJ5Lg0KDQoNCk5vdGU6IHdlIGFy ZSB3b3JraW5nIG9uIHRoZSBtaW51dGVzIGZyb20gdGhlIHZpcnR1YWwgaW50ZXJpbSBhbmQgd2ls bA0KcG9zdCB3aXRoaW4gdGhlIG5leHQgMjQgaG91cnMuDQoNCg0KDQotLS0tLSBNZXNzYWdlIGZy b20gImNsdWUgaXNzdWUgdHJhY2tlciIgPHRyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnPiBv biANCk1vbiwgMDggSnVsIDIwMTMgMTg6NTE6MjAgLTAwMDAgLS0tLS0NClRvOg0KQ2hyaXN0aWFu Lkdyb3Zlc0BudGVjem9uZS5jb20sIG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tDQpjYzoNCmNs dWVAaWV0Zi5vcmcNClN1YmplY3Q6DQpbY2x1ZV0gIzMyOiBEZWZpbml0aW9ucyBvZiBSb2xlcw0K DQojMzI6IERlZmluaXRpb25zIG9mIFJvbGVzDQoNCiBUaGVyZSBhcmUgYSBudW1iZXIgb2YgcGxh Y2VzIHdoZXJlIHRoZSB0ZXJtICJSb2xlIiBpcyBkZWZpbmVkLiAgIFdlIG5lZWQNCiB0byBmaWd1 cmUgb3V0IHdoaWNoIGFyZSBtb3N0IGFwcHJvcHJpYXRlIGZvciBDTFVFLiAgIE5vdGUsIHRoaXMg aGFzIGFsc28NCiBiZWVuIGRpc2N1c3NlZCBvbiBESVNQQVRDSCBXRyBtYWlsaW5nIGxpc3Q6IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCiBhcmNoaXZlL3dlYi9jbHVlL2N1cnJlbnQvbXNnMDI1 MjcuaHRtbA0KDQoNCiBOb3RlOiBDb21wb25lbnQgd2lsbCBiZSBjaGFuZ2VkIHRvIGRhdGEtbW9k ZWwgb25jZSB0aGF0J3MgYSBXRyBkb2N1bWVudC4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiBSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6DQogIG1h cnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tICAgICAgICAgfCAgQ2hyaXN0aWFuLkdyb3Zlc0BudGVj em9uZS5jb20NCiAgICAgVHlwZTogIHRhc2sgICAgICAgICAgICAgICAgICAgICB8ICAgICBTdGF0 dXM6ICBuZXcNCiBQcmlvcml0eTogIGNyaXRpY2FsICAgICAgICAgICAgICAgICB8ICBNaWxlc3Rv bmU6ICBtaWxlc3RvbmUxDQpDb21wb25lbnQ6ICBjaGFydGVyICAgICAgICAgICAgICAgICAgfCAg ICBWZXJzaW9uOiAgMS4wDQogU2V2ZXJpdHk6ICBDYW5kaWRhdGUgV0cgRG9jdW1lbnQgICAgfCAg IEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy93Zy9jbHVlL3RyYWMvdGlja2V0LzMyPg0KY2x1ZSA8aHR0cDovL3Rv b2xzLmlldGYub3JnL3dnL2NsdWUvPg0KDQoNCg0KDQotLS0tLSBNZXNzYWdlIGZyb20gImNsdWUg aXNzdWUgdHJhY2tlciIgPHRyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnPiBvbiANCk1vbiwg MDggSnVsIDIwMTMgMTg6NTQ6NTggLTAwMDAgLS0tLS0NClRvOg0KbWFyay5kdWNrd29ydGhAcG9s eWNvbS5jb20sIG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tDQpjYzoNCmNsdWVAaWV0Zi5vcmcN ClN1YmplY3Q6DQpbY2x1ZV0gIzMzOiBTZWN1cml0eSBmb3IgRnJhbWV3b3JrIGRvY3VtZW50DQoN CiMzMzogU2VjdXJpdHkgZm9yIEZyYW1ld29yayBkb2N1bWVudA0KDQogVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGZvciB0aGUgZnJhbWV3b3JrIG5lZWQgdG8gYmUgZG9jdW1lbnRlZC4NCiBO b3RlLCB0aGF0IHRoZSBjb250ZW50IHNob3VsZCBiZSBiYXNlZCBvbiB0aGUgc2VjdXJpdHkgdGhy ZWF0cyBpZGVudGlmaWVkDQogaW4gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCAoVEJEKSBhcyB3 ZWxsIGFzIGFueSBhZGRpdGlvbmFsIHNlY3VyaXR5DQogdGhyZWF0cyByZWxhdGVkIHRvIHRoZSBv dmVyYWxsIGZyYW1ld29yayBpdHNlbGYuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVw b3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOg0KICBtYXJ5Lmll dGYuYmFybmVzQGdtYWlsLmNvbSAgICAgICAgIHwgIG1hcmsuZHVja3dvcnRoQHBvbHljb20uY29t DQogICAgIFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3 DQogUHJpb3JpdHk6ICBjcml0aWNhbCAgICAgICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KQ29t cG9uZW50OiAgZnJhbWV3b3JrICAgICAgICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0 eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jbHVlL3RyYWMv dGlja2V0LzMzPg0KY2x1ZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2NsdWUvPg0KDQoNCg0K DQotLS0tLSBNZXNzYWdlIGZyb20gImNsdWUgaXNzdWUgdHJhY2tlciIgPHRyYWMrY2x1ZUB0cmFj LnRvb2xzLmlldGYub3JnPiBvbiANCk1vbiwgMDggSnVsIDIwMTMgMTg6NTg6MjYgLTAwMDAgLS0t LS0NClRvOg0KbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb20sIG1hcnkuaWV0Zi5iYXJuZXNAZ21h aWwuY29tDQpjYzoNCmNsdWVAaWV0Zi5vcmcNClN1YmplY3Q6DQpSZTogW2NsdWVdICMyMDogQWN0 aW9uIGl0ZW0gdmlpOiBSZWplY3RpbmcgQ29uZmlndXJlDQoNCiMyMDogQWN0aW9uIGl0ZW0gdmlp OiAgUmVqZWN0aW5nIENvbmZpZ3VyZQ0KDQpDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbSk6DQoNCiAqIG93bmVyOiAgQW5keSBQZXBwZXJlbGwgPT4gbWFyay5kdWNrd29ydGhA cG9seWNvbS5jb20NCiAqIHByaW9yaXR5OiAgbWlub3IgPT4gbWFqb3INCg0KDQpPbGQgZGVzY3Jp cHRpb246DQoNCj4gQWN0aW9uIGl0ZW0gdmlpIGZyb20gMTktMjAgU2VwdC4gMjAxMiBpbnRlcmlt Lg0KPg0KPiBBbmR5OiBBZGQgdGV4dCB0byBGcmFtZXdvcmsgZm9yIHJlamVjdGluZyBDb25maWd1 cmUNCg0KTmV3IGRlc2NyaXB0aW9uOg0KDQogQWN0aW9uIGl0ZW0gdmlpIGZyb20gMTktMjAgU2Vw dC4gMjAxMiBpbnRlcmltLg0KDQogQW5keTogQWRkIHRleHQgdG8gRnJhbWV3b3JrIGZvciByZWpl Y3RpbmcgQ29uZmlndXJlDQoNCiBBcyBkaXNjdXNzZWQgYXQgdmlydHVhbCBpbnRlcmltIG9uIE1h eSAyMXN0LCB0aGlzIG5lZWRzIHRvIGJlIG1lbnRpb25lZCANCmluDQogdGhlIGZyYW1ld29yaywg c28gdGhhdCB0aGUgc3Vic2VxdWVudCBhY3Rpb25zIGNhbiBiZSBkZXNjcmliZWQuIChFLmcuLA0K IGRvZXMgdGhlIHByaW9yIGNvbmZpZ3VyZSByZW1haW4gaW4gZWZmZWN0PykNCg0KIFRoZSBkZXRh aWxzIG9mIGhvdyB0aGlzIGlzIGNvbW11bmljYXRlZCBiZWxvbmcgaW4gdGhlIHNvbHV0aW9uLg0K DQotLQ0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgT3duZXI6DQogIG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29t ICAgICAgICAgfCAgbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb20NCiAgICAgVHlwZTogIHRhc2sg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpv ciAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGZyYW1ld29y ayAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgLSAgICAgICAgICAg ICAgICAgICAgICAgIHwgIFJlc29sdXRpb246DQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvd2cvY2x1ZS90cmFjL3RpY2tldC8yMCNjb21tZW50OjE+DQpjbHVlIDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS8+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpjbHVlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90 aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy aXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4g ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 0013D53948257BA3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvcmJlbCI+aGkgdGhlcmUsPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3JiZWwiPmZyYW1ld29yayBzZWN0aW9uIDggZGVzY2li ZXMgb25lIHJlcXVpcmVtZW50OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ29yYmVs Ij4mbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3JiZWwiPiZu YnNwOyAmbmJzcDtJZiB0aGVyZSBhcmUgbXVsdGlwbGUgSW5kaXZpZHVhbA0KRW5jb2RpbmdzIGlu IHRoZSBncm91cCwgdGhlbiB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvcmJl bCI+Jm5ic3A7ICZuYnNwO0NvbnN1bWVyIGNhbiBjb25maWd1cmUgdGhlDQpQcm92aWRlciwgdmlh IGEgQ29uZmlndXJlIG1lc3NhZ2UsIHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3JiZWwiPiZuYnNwOyA8Yj4mbmJzcDtlbmNvZGUgYSBzaW5nbGUgTWVkaWEgQ2FwdHVyZQ0KaW50 byBtdWx0aXBsZSBkaWZmZXJlbnQgQ2FwdHVyZTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvcmJlbCI+PGI+Jm5ic3A7ICZuYnNwO0VuY29kaW5ncyBhdCB0aGUgc2FtZSB0aW1l PC9iPiwNCnN1YmplY3QgdG8gdGhlIE1heCBDYXB0dXJlIEVuY29kaW5nczwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ29yYmVsIj4mbmJzcDsgJm5ic3A7Y29uc3RyYWludCwgd2l0aCBl YWNoIGNhcHR1cmUNCmVuY29kaW5nIGZvbGxvd2luZyB0aGUgY29uc3RyYWludHMgb2Y8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvcmJlbCI+Jm5ic3A7ICZuYnNwO2EgZGlmZmVyZW50 IEluZGl2aWR1YWwgRW5jb2RpbmcuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3JiZWwiPiZuYnNwO2luIHdoYXQgc2l0dWF0aW9uIHRoZSBjb25zdW1lciBuZWVkcw0KdGhl IHNhbWUgbWVkaWEgY2FwdHVyZSBpbiBkaWZmZXJlbnQgaW5kaXZpZHVhbCBlbmNvZGluZ3Mgc2lt dWx0YW5pb3VzbHk/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3JiZWwi PmFuZCBhYm91dCB0aGUgbWFwcGluZyBpcyB0aGF0IGJldHRlciBpZg0Kd2UgdXNlIGFuIGFkZGl0 aW9uYWwgZGVtdWx0aXBsZXhJRCB3aGljaCBpcyBmcm9tIGNhcHR1cmVJRC1lbmNvZGluZ0lELjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ29yYmVsIj5iZWNhdXNlIGluIHRoZSBkeW5h bWljIG1hcHBpbmcgbWV0aG9kIGxpa2UNClJUUCBoZWFkIGV4dGVudGlvbiBpZiB3ZSB1c2UgbXVs dGlwbGV4SUQgd2Ugb25seSBuZWVkIG9uZSBSVFAgZXh0ZW50aW9uLg0KPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3JiZWwiPkJ1dCBpZiB3ZSB1c2UgdHdvIGZpZWxkcyhjYXB0dXJl SUQtZW5jb2RpbmdJRCkNCml0IHdpbGwgdGFrZSB0d28gZXh0ZW50aW9ucy48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvcmJlbCI+dGhlIGNvbnN1bWVyIGNhbiBjb25maWd1cmUgdGhl IGRlbXVsdGlwbGV4SUQNCmluIHRoZSBjb25maWd1cmUgbWVzc2FnZS48L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvcmJlbCI+VGhhbmsgeW91IGFuZCBCZXN0IHJl Z2FyZHMsPGJyPg0KTGlhbmc8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9Is6iyO3RxbraIj48YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5jbHVlLXJlcXVlc3RA aWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PreivP7IyzogJm5ic3A7Y2x1ZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTMvMDcvMDkgMDI6NTg8L2ZvbnQ+DQo8dGFibGUgYm9y ZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2Vu dGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8YnI+DQpjbHVlQGll dGYub3JnPC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2x1ZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2x1ZSBEaWdlc3QsIFZv bCAzMiwgSXNzdWUgNDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mj48dHQ+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBh bGwgdGhlIGluZGl2aWR1YWwNCm1lc3NhZ2U8YnI+DQphdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVk IHRvIHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlvdXIgbGlzdDxicj4NCnN1YnNjcmlw dGlvbi4gJm5ic3A7VG8gZG8gc28sIGdvIHRvIDxicj4NCjxicj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZTxicj4NCjxicj4NCkNsaWNrIHRoZSAnVW5zdWJzY3Jp YmUgb3IgZWRpdCBvcHRpb25zJyBidXR0b24sIGxvZyBpbiwgYW5kIHNldCAmcXVvdDtHZXQ8YnI+ DQpNSU1FIG9yIFBsYWluIFRleHQgRGlnZXN0cz8mcXVvdDsgdG8gTUlNRS4gJm5ic3A7WW91IGNh biBzZXQgdGhpcyBvcHRpb248YnI+DQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMg eW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpTZW5kIGNs dWUgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmNsdWVAaWV0Zi5vcmc8YnI+DQo8 YnI+DQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwg dmlzaXQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPGJy Pg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hl bHAnIHRvPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCmNsdWUtcmVxdWVzdEBpZXRmLm9yZzxicj4NCjxicj4NCllvdSBjYW4gcmVh Y2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpjbHVlLW93bmVyQGlldGYu b3JnPGJyPg0KPGJyPg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxp bmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxicj4NCnRoYW4gJnF1b3Q7UmU6IENvbnRlbnRzIG9m IGNsdWUgZGlnZXN0Li4uJnF1b3Q7PGJyPg0KVG9kYXkncyBUb3BpY3M6PGJyPg0KPGJyPg0KICZu YnNwOyAxLiBSZTogaGkgdGhlcmUsIHF1ZXN0aW9uIGFib3V0IHRoZSBzdGF0aWMgbWFwcGluZyBp bjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0J2h0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0wMCNzZWN0aW9uLTQuNSc8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsoUm9uaSBFdmVuKTxicj4NCiAmbmJzcDsgMi4gUmU6IGhpIHRoZXJl LCBxdWVzdGlvbiBhYm91dCB0aGUgc3RhdGljIG1hcHBpbmcgaW48YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDtkcmFmdCdodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUt cnRwLW1hcHBpbmctMDAjc2VjdGlvbi00LjUnPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7KFBh dWwgS3l6aXZhdCk8YnI+DQogJm5ic3A7IDMuIEFkb3B0aW5nIGRyYWZ0LXByZXN0YS1jbHVlLWRh dGEtbW9kZWwtc2NoZW1hIGFzIGEgV0cgZG9jdW1lbnQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsoTWFyeSBCYXJuZXMpPGJyPg0KICZuYnNwOyA0LiAmbmJzcDsjMzI6IERlZmluaXRpb25zIG9m IFJvbGVzIChjbHVlIGlzc3VlIHRyYWNrZXIpPGJyPg0KICZuYnNwOyA1LiAmbmJzcDsjMzM6IFNl Y3VyaXR5IGZvciBGcmFtZXdvcmsgZG9jdW1lbnQgKGNsdWUgaXNzdWUgdHJhY2tlcik8YnI+DQog Jm5ic3A7IDYuIFJlOiAjMjA6IEFjdGlvbiBpdGVtIHZpaTogJm5ic3A7UmVqZWN0aW5nIENvbmZp Z3VyZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyhjbHVlIGlzc3VlIHRyYWNrZXIpPGJyPg0K PC90dD48L2ZvbnQ+DQo8ZGl2IGFsaWduPXJpZ2h0IGRpcj1ydGw+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KLS0tLS0gTWVzc2FnZSBmcm9t IFJvbmkgRXZlbiAmbHQ7cm9uaS5ldmVuQG1haWwwMS5odWF3ZWkuY29tJmd0OyBvbiBNb24sDQo4 IEp1bCAyMDEzIDA5OjE4OjA0ICswMDAwIC0tLS0tPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCUg ZGlyPXJ0bD4NCjx0cj4NCjx0ZCB3aWR0aD02JT4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxm b250IHNpemU9Mz48Yj5Ubzo8L2I+PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkzJT4NCjxkaXYg YWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXplPTM+JnF1b3Q7d2FuZy5saWFuZzEyQHp0ZS5j b20uY24mcXVvdDsNCiZsdDt3YW5nLmxpYW5nMTJAenRlLmNvbS5jbiZndDssICZxdW90O2pvbmF0 aGFuQHZpZHlvLmNvbSZxdW90OyAmbHQ7am9uYXRoYW5AdmlkeW8uY29tJmd0OzwvZm9udD48L2Rp dj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxmb250IHNpemU9Mz48Yj5j Yzo8L2I+PC9mb250PjwvZGl2Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodCBkaXI9cnRsPjxmb250 IHNpemU9Mz4mcXVvdDtjbHVlQGlldGYub3JnJnF1b3Q7ICZsdDtjbHVlQGlldGYub3JnJmd0Ozwv Zm9udD48L2Rpdj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxmb250IHNp emU9Mz48Yj5TdWJqZWN0OjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 IGRpcj1ydGw+PGZvbnQgc2l6ZT0zPlJlOiBbY2x1ZV0gaGkgdGhlcmUsIHF1ZXN0aW9uIGFib3V0 DQp0aGUgc3RhdGljIG1hcHBpbmcgaW4gZHJhZnQnaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTAwI3NlY3Rpb24tNC41JzwvZm9udD48L2Rpdj48 L3RhYmxlPg0KPGRpdiBhbGlnbj1yaWdodCBkaXI9cnRsPg0KPGJyPjwvZGl2Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPkhpLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj5UaGUgcXVlc3Rpb24gaXMgd2hhdCBpcyBtYXBwZWQsIGlzIGl0IG1hcHBpbmcNCm9m IGEgc3BlY2lmaWMgU1NSQyBhbmQgbS1saW5lIHRvIHRoZSBhZHZlcnRpc2VtZW50ICxpdCB3aWxs IG5lZWQgdG8gYmUNCm1hcHBlZCB0byBjYXB0dXJlSUQuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj5Sb25pPC9mb250Pg0KPHA+DQo8aHI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IHdhbmcubGlhbmcxMkB6dGUuY29tLmNuIFt3YW5n LmxpYW5nMTJAenRlLmNvbS5jbl08Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBKdWx5IDA4LCAy MDEzIDEyOjEwIFBNPGI+PGJyPg0KVG86PC9iPiBqb25hdGhhbkB2aWR5by5jb207IFJvbmkgRXZl bjxiPjxicj4NClN1YmplY3Q6PC9iPiBoaSB0aGVyZSwgcXVlc3Rpb24gYWJvdXQgdGhlIHN0YXRp YyBtYXBwaW5nIGluIGRyYWZ0J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y2x1ZS1ydHAtbWFwcGluZy0wMCNzZWN0aW9uLTQuNSc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxi cj4NCkhpIHRoZXJlLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPiA8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCkkgbm90aWNlZCB0aGF0IGluIHRo ZSBjbHVlLXJ0cC1tYXBwaW5nIGRyYWZ0LiB5b3UgZGVzY3JpYmVkIGEgc3RhdGljIG1hcHBpbmcN Cm1ldGhvZCBhbmQgYWxzbyBnYXZlIHRoZSBleGFtcGxlIHF1b3RlZCBiZWxvdzo8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7bT12aWRlbyA0OTIwMCBSVFAvQVZQ IDk5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9ZXh0bWFwOjEgdXJu OmlldGY6cGFyYW1zOnJ0cC1oZHJleDpjbHVlLWNhcHR1cmUtaWQNCi8gZm9yIHN1cHBvcnQ8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtvZiBkeW5hbWljIG1hcHBpbmc8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1ydHBtYXA6OTkgSDI2NC85MDAw MDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDthPW1heC1zZW5kLXNzcmM6 eyo6Nn08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1tYXgtcmVjdi1z c3JjOnsqOjR9PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9c3NyYzox MTExMSBDYXB0dXJlSUQ6MTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDth PXNzcmM6MjIyMjIgQ2FwdHVyZUlEOjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7YT1zc3JjOjMzMzMzIENhcHR1cmVJRDozPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwO2E9c3NyYzo0NDQ0NCBDYXB0dXJlSUQ6NDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmM6NTU1NTUgQ2FwdHVyZUlEOjU8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1zc3JjOjY2NjY2IENhcHR1cmVJRDo2PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPjxicj4NCndlIGNhbiBzZWUgdGhlIHN0YXRpYyBtYXBwaW5nIGhlcmUgaXMg YmV0d2VlbiB0aGUgc3NyYyBhbmQgQ2FwdHVyZUlEIGJ1dA0Kbm90IHJlbGF0ZWQgd2hpdCB0aGUg Y2FwdHVyZS1lbmNvZGluZy1JRC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kd2hlbiB0aGUgY29uc3VtZXIg d2FudHMgdG8gc2VsZWN0IG9uZSBDYXB0dXJlSUQgJm5ic3A7YnV0IHVzZSBkaWZmZXJlbnQNCmlu ZGl2aXN1YWwgZW5jb2RpbmcgaXQgY2FuJ3QgZGlzdGluZ3Vpc2ggdGhlIHN0cmVhbXMgZnJvbSB0 aGlzIGtpbmQgb2YNCm1hcHBpbmcuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyI+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KZm9yIGV4YW1wbGUsIHRoZSBw cm92aWRlciBzdXBwb3J0cyB0d28gZGlmZmVyZW50IGluZGl2aXN1YWwgZW5jb2RpbmdzKEVOQzAs DQpFTkMxKSB3aXRoIGRpZmZlcmVudCBiaXRyYXRlLCBwaWN0dXJlIHNpemUgYW5kIHByb2Nlc3Nl ZCBwaXhlbHMgcmF0ZSBpbg0KZW5jb2RpbmcgZ3JvdXAwKEVHMCkuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K VGhlIHByb3ZpZGUgYXNzb2NpYXRlIHRoZSBtZWRpYSBjYXB0dXJlIFZDMCB3aXRoIEVHMC4gVGhl IGNvbnN1bWVyIHdhbnRzDQp0aGUgVkMwIHVzaW5nIGJvdGggRU5DMCBhbmQgRU5DMSBzaW11bHRh bmVvdXNseS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KaW4gdGhpcyBjYXNlIGNhbiB3ZSB1c2UgdGhlIHN0 YXRpYyBtYXBwaW5nIGxpa2UgdGhpcz8gRG8gd2UgaGF2ZSBvdGhlcg0KbWVhdGhvZCB0byBzdXBw b3J0IHRoaXMgY2FzZT88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4gPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQptPXZpZGVvIDQ5MjAwIFJUUC9B VlAgOTk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4gPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj48YnI+DQogYT1ydHBtYXA6OTkgSDI2NC85MDAwMDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki Pjxicj4NCi4uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9c3NyYzox MTExMSBDYXB0dXJlSUQ6MSBFbmNvZGluZ0lEOkVOQzA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7YT1zc3JjOjIyMjIyIENhcHR1cmVJRDoxIEVuY29kaW5nSUQ6RU5DMTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQpUaGFuayB5b3UgYW5kIEJlc3QgcmVnYXJkcyw8 YnI+DQpMaWFuZzxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMiPjxicj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyI+PGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlvdQ0KYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbg0Kb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Ljxicj4NCjxicj4NCjwvZm9udD4NCjxicj4NCjxkaXYgYWxpZ249cmln aHQgZGlyPXJ0bD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQotLS0tLSBNZXNzYWdlIGZyb20gUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBh bHVtLm1pdC5lZHUmZ3Q7IG9uIE1vbiwgMDgNCkp1bCAyMDEzIDEwOjUyOjI3IC0wNDAwIC0tLS0t PC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCUgZGlyPXJ0bD4NCjx0cj4NCjx0ZCB3aWR0aD02JT4N CjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxmb250IHNpemU9Mz48Yj5Ubzo8L2I+PC9mb250Pjwv ZGl2Pg0KPHRkIHdpZHRoPTkzJT4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXpl PTM+Y2x1ZUBpZXRmLm9yZzwvZm9udD48L2Rpdj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVm dCBkaXI9cnRsPjxmb250IHNpemU9Mz48Yj5TdWJqZWN0OjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0IGRpcj1ydGw+PGZvbnQgc2l6ZT0zPlJlOiBbY2x1ZV0gaGkgdGhl cmUsIHF1ZXN0aW9uIGFib3V0DQp0aGUgc3RhdGljIG1hcHBpbmcgaW4gZHJhZnQnaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTAwI3NlY3Rpb24t NC41JzwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGRpdiBhbGlnbj1yaWdodCBkaXI9cnRsPg0KPGJy PjwvZGl2Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Um9uaSw8YnI+DQo8YnI+DQpPbiA3LzgvMTMg NToxOCBBTSwgUm9uaSBFdmVuIHdyb3RlOjxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhlIHF1ZXN0aW9uIGlzIHdoYXQgaXMgbWFwcGVkLCBpcyBpdCBtYXBwaW5nIG9mIGEgc3Bl Y2lmaWMgU1NSQyBhbmQ8YnI+DQomZ3Q7IG0tbGluZSB0byB0aGUgYWR2ZXJ0aXNlbWVudCAsaXQg d2lsbCBuZWVkIHRvIGJlIG1hcHBlZCB0byBjYXB0dXJlSUQuPGJyPg0KPGJyPg0KVGhpcyBkcmFm dCBoYXNuJ3QgYmVlbiB1cGRhdGVkIHJlY2VudGx5LCBhbmQgaXQgaXNuJ3QgY2xlYXIgaWYgaXQg d2lsbA0KPGJyPg0KYmUgY29uc2lzdGVudCB3aXRoIHdoYXRldmVyIGdldHMgZGVjaWRlZCBhYm91 dCBidW5kbGluZyBpbiBNTVVTSUMuIEJ1dA0KSSA8YnI+DQp0aG91Z2h0IGl0IHdhcyBsb25nIHNl dHRsZWQgdGhhdCB3ZSBuZWVkIHRvIG1hcCAqY2FwdHVyZS1lbmNvZGluZ3MqIHRvDQo8YnI+DQpS VFAgLSB0aGF0IHRoZSBzYW1lIGNhcHR1cmUgbWFwIGJlIGNvbmZpZ3VyZWQgbW9yZSB0aGFuIG9u Y2UsIHRvIDxicj4NCmRpZmZlcmVudCBlbmNvZGluZywgYW5kIGVhY2ggdGhlbiBuZWVkcyB0byBi ZSBjb3JyZWxhdGVkIHRvIHRoZSBwcm9wZXINCjxicj4NCnNzcmMgaW4gUlRQLjxicj4NCjxicj4N CkkgaGFkIHN1Z2dlc3RlZCB0aGF0IHdlIGNvdWxkIGdldCBieSB3aXRoIG1hcHBpbmcgdGhlIFJU UCB0byBhbiA8YnI+DQplbmNvZGluZywgc2luY2UgYXQgYW55IHBvaW50IGluIHRpbWUgdGhhdCBl bmNvZGluZyB3aWxsIGhhdmUgYmVlbiA8YnI+DQpjb25maWd1cmVkIHRvIGF0IG1vc3Qgb25lIGNh cHR1cmUuIChTbywgaWYgeW91IGtub3cgdGhlIGVuY29kaW5nIHlvdSBjYW4NCjxicj4NCmxvb2sg dXAgd2hhdCBjYXB0dXJlIGhhcyBiZWVuIGNvbmZpZ3VyZWQgdG8gaXQsIGFuZCBzbyBkaXNjb3Zl ciB0aGUgPGJyPg0KY2FwdHVyZS1lbmNvZGluZy4pPGJyPg0KPGJyPg0KSWYgd2UgZ28gd2l0aCBS b2IncyBwcm9wb3NhbCB0byByZXByZXNlbnQgZW5jb2RpbmdzIGFzIG0tbGluZXMgaW4gU0RQLA0K PGJyPg0KdGhlbiB0aGUgUlRQIG1hcHBpbmcgY2FuIGp1c3QgYmUgdG8gYSBsYWJlbC9JRCBhc3Nv Y2lhdGVkIHdpdGggdGhhdCBtLWxpbmUuPGJyPg0KPGJyPg0KSVNUTSBpdHMgdGltZSB0byB1cGRh dGUgdGhpcyBkcmFmdC48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQYXVsPGJyPg0KPGJyPg0K Jmd0OyBSb25pPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAq RnJvbToqIHdhbmcubGlhbmcxMkB6dGUuY29tLmNuIFt3YW5nLmxpYW5nMTJAenRlLmNvbS5jbl08 YnI+DQomZ3Q7ICpTZW50OiogTW9uZGF5LCBKdWx5IDA4LCAyMDEzIDEyOjEwIFBNPGJyPg0KJmd0 OyAqVG86KiBqb25hdGhhbkB2aWR5by5jb207IFJvbmkgRXZlbjxicj4NCiZndDsgKlN1YmplY3Q6 KiBoaSB0aGVyZSwgcXVlc3Rpb24gYWJvdXQgdGhlIHN0YXRpYyBtYXBwaW5nIGluPGJyPg0KJmd0 OyBkcmFmdCdodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRwLW1h cHBpbmctMDAjc2VjdGlvbi00LjUnPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEhpIHRo ZXJlLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbm90aWNlZCB0aGF0IGluIHRoZSBjbHVlLXJ0cC1t YXBwaW5nIGRyYWZ0LiB5b3UgZGVzY3JpYmVkIGEgc3RhdGljPGJyPg0KJmd0OyBtYXBwaW5nIG1l dGhvZCBhbmQgYWxzbyBnYXZlIHRoZSBleGFtcGxlIHF1b3RlZCBiZWxvdzo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttPXZpZGVvIDQ5MjAwIFJUUC9BVlAg OTk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9ZXh0bWFwOjEgdXJuOmll dGY6cGFyYW1zOnJ0cC1oZHJleDpjbHVlLWNhcHR1cmUtaWQNCi8gZm9yIHN1cHBvcnQ8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mIGR5bmFtaWMgbWFwcGluZzxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1ydHBtYXA6OTkgSDI2NC85MDAwMDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1tYXgtc2VuZC1zc3JjOnsqOjZ9PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthPW1heC1yZWN2LXNzcmM6eyo6NH08 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9c3NyYzoxMTExMSBDYXB0dXJl SUQ6MTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YT1zc3JjOjIyMjIyIENh cHR1cmVJRDoyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmM6MzMz MzMgQ2FwdHVyZUlEOjM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9c3Ny Yzo0NDQ0NCBDYXB0dXJlSUQ6NDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YT1zc3JjOjU1NTU1IENhcHR1cmVJRDo1PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDthPXNzcmM6NjY2NjYgQ2FwdHVyZUlEOjY8YnI+DQomZ3Q7PGJyPg0KJmd0OyB3ZSBjYW4g c2VlIHRoZSBzdGF0aWMgbWFwcGluZyBoZXJlIGlzIGJldHdlZW4gdGhlIHNzcmMgYW5kIENhcHR1 cmVJRA0KYnV0PGJyPg0KJmd0OyBub3QgcmVsYXRlZCB3aGl0IHRoZSBjYXB0dXJlLWVuY29kaW5n LUlELjxicj4NCiZndDsgd2hlbiB0aGUgY29uc3VtZXIgd2FudHMgdG8gc2VsZWN0IG9uZSBDYXB0 dXJlSUQgJm5ic3A7YnV0IHVzZSBkaWZmZXJlbnQ8YnI+DQomZ3Q7IGluZGl2aXN1YWwgZW5jb2Rp bmcgaXQgY2FuJ3QgZGlzdGluZ3Vpc2ggdGhlIHN0cmVhbXMgZnJvbSB0aGlzIGtpbmQNCm9mPGJy Pg0KJmd0OyBtYXBwaW5nLjxicj4NCiZndDsgZm9yIGV4YW1wbGUsIHRoZSBwcm92aWRlciBzdXBw b3J0cyB0d28gZGlmZmVyZW50IGluZGl2aXN1YWw8YnI+DQomZ3Q7IGVuY29kaW5ncyhFTkMwLCBF TkMxKSB3aXRoIGRpZmZlcmVudCBiaXRyYXRlLCBwaWN0dXJlIHNpemUgYW5kIHByb2Nlc3NlZDxi cj4NCiZndDsgcGl4ZWxzIHJhdGUgaW4gZW5jb2RpbmcgZ3JvdXAwKEVHMCkuPGJyPg0KJmd0OyBU aGUgcHJvdmlkZSBhc3NvY2lhdGUgdGhlIG1lZGlhIGNhcHR1cmUgVkMwIHdpdGggRUcwLiBUaGUg Y29uc3VtZXINCndhbnRzPGJyPg0KJmd0OyB0aGUgVkMwIHVzaW5nIGJvdGggRU5DMCBhbmQgRU5D MSBzaW11bHRhbmVvdXNseS48YnI+DQomZ3Q7IGluIHRoaXMgY2FzZSBjYW4gd2UgdXNlIHRoZSBz dGF0aWMgbWFwcGluZyBsaWtlIHRoaXM/IERvIHdlIGhhdmUgb3RoZXI8YnI+DQomZ3Q7IG1lYXRo b2QgdG8gc3VwcG9ydCB0aGlzIGNhc2U/PGJyPg0KJmd0Ozxicj4NCiZndDsgbT12aWRlbyA0OTIw MCBSVFAvQVZQIDk5PGJyPg0KJmd0OyAmbmJzcDsgYT1ydHBtYXA6OTkgSDI2NC85MDAwMDxicj4N CiZndDsgLi4uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmM6MTEx MTEgQ2FwdHVyZUlEOjEgRW5jb2RpbmdJRDpFTkMwPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDthPXNzcmM6MjIyMjIgQ2FwdHVyZUlEOjEgRW5jb2RpbmdJRDpFTkMxPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rIHlvdSBhbmQgQmVzdCByZWdhcmRzLDxicj4N CiZndDsgTGlhbmc8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K Jmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMNCm1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl d2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlvdQ0KYXJl IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s IGRpc3RyaWJ1dGlvbg0Kb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBjbHVlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgY2x1ZUBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPGJyPg0K Jmd0Ozxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGRpdiBhbGlnbj1yaWdodCBkaXI9 cnRsPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCi0tLS0tIE1lc3NhZ2UgZnJvbSBNYXJ5IEJhcm5lcyAmbHQ7bWFyeS5pZXRmLmJhcm5lc0Bn bWFpbC5jb20mZ3Q7IG9uIE1vbiwNCjggSnVsIDIwMTMgMTM6MzY6MjYgLTA1MDAgLS0tLS08L2Zv bnQ+DQo8dGFibGUgd2lkdGg9MTAwJSBkaXI9cnRsPg0KPHRyPg0KPHRkIHdpZHRoPTEyJT4NCjxk aXYgYWxpZ249bGVmdCBkaXI9cnRsPjxmb250IHNpemU9Mz48Yj5Ubzo8L2I+PC9mb250PjwvZGl2 Pg0KPHRkIHdpZHRoPTg3JT4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXplPTM+ Q0xVRSAmbHQ7Y2x1ZUBpZXRmLm9yZyZndDs8L2ZvbnQ+PC9kaXY+DQo8dHI+DQo8dGQ+DQo8ZGl2 IGFsaWduPWxlZnQgZGlyPXJ0bD48Zm9udCBzaXplPTM+PGI+U3ViamVjdDo8L2I+PC9mb250Pjwv ZGl2Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodCBkaXI9cnRsPjxmb250IHNpemU9Mz5bY2x1ZV0g QWRvcHRpbmcgZHJhZnQtcHJlc3RhLWNsdWUtZGF0YS1tb2RlbC1zY2hlbWENCmFzIGEgV0cgZG9j dW1lbnQ8L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD4NCjxi cj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpIGFsbCw8YnI+DQo8YnI+DQpBcyB3YXMg ZGlzY3Vzc2VkIGF0IHRoZSB2aXJ0dWFsIGludGVyaW0gb24gSnVuZSAyNXRoLCB0aGVyZSBpcyBh PGJyPg0KcHJvcG9zYWwgZm9yIHRoZSBXRyB0byBhcHByb3ZlIHRoZSBhZG9wdGlvbiBvZjxicj4N CmRyYWZ0LXByZXN0YS1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hIGFzIGEgQ0xVRSBXRyBkb2N1bWVu dDo8YnI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXByZXN0YS1jbHVl LWRhdGEtbW9kZWwtc2NoZW1hLzxicj4NCjxicj4NClBsZWFzZSByZXNwb25kICZxdW90O1llcyZx dW90OyBvciAmcXVvdDtObyZxdW90OyBhcyB0byB3aGV0aGVyIHlvdSBiZWxpZXZlDQp0aGUgZG9j dW1lbnQ8YnI+DQpzaG91bGQgYmUgYWRvcHRlZCBubyBsYXRlciB0aGFuIFN1bmRheSBKdWx5IDE0 dGgsIDIwMTMsIHNvIHRoZSBhdXRob3JzPGJyPg0KaGF2ZSB0aW1lIHRvIHN1Ym1pdCBhcyBhIFdH IGRvY3VtZW50IGJlZm9yZSB0aGUgZGVhZGxpbmUsIG5vdGluZyB0aGF0PGJyPg0KdGhlcmUgaXMg YSBzaW5nbGUgZGVhZGxpbmUgZm9yIElFVEYtODcgKEp1bHkgMTV0aCwgMjQ6MDAgVVRDKS48YnI+ DQo8YnI+DQpJZiB5b3UgaGF2ZSBzcGVjaWZpYyBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIFBM RUFTRSBwb3N0IHRob3NlIGluIGE8YnI+DQpzZXBhcmF0ZSB0aHJlYWQgd2l0aCBhbiBhcHByb3By aWF0ZSB0aXRsZSB0byBmYWNpbGl0YXRlIHRyYWNraW5nLjxicj4NCjxicj4NClRoYW5rcyw8YnI+ DQpNYXJ5Ljxicj4NCjxicj4NCjxicj4NCk5vdGU6IHdlIGFyZSB3b3JraW5nIG9uIHRoZSBtaW51 dGVzIGZyb20gdGhlIHZpcnR1YWwgaW50ZXJpbSBhbmQgd2lsbDxicj4NCnBvc3Qgd2l0aGluIHRo ZSBuZXh0IDI0IGhvdXJzLjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGRpdiBhbGlnbj1yaWdo dCBkaXI9cnRsPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCi0tLS0tIE1lc3NhZ2UgZnJvbSAmcXVvdDtjbHVlIGlzc3VlIHRyYWNrZXImcXVv dDsgJmx0O3RyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnJmd0Ow0Kb24gTW9uLCAwOCBKdWwg MjAxMyAxODo1MToyMCAtMDAwMCAtLS0tLTwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlIGRpcj1y dGw+DQo8dHI+DQo8dGQgd2lkdGg9MTQlPg0KPGRpdiBhbGlnbj1sZWZ0IGRpcj1ydGw+PGZvbnQg c2l6ZT0zPjxiPlRvOjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODUlPg0KPGRpdiBhbGln bj1yaWdodCBkaXI9cnRsPjxmb250IHNpemU9Mz5DaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNv bSwgbWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208L2ZvbnQ+PC9kaXY+DQo8dHI+DQo8dGQ+DQo8 ZGl2IGFsaWduPWxlZnQgZGlyPXJ0bD48Zm9udCBzaXplPTM+PGI+Y2M6PC9iPjwvZm9udD48L2Rp dj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXplPTM+Y2x1ZUBpZXRm Lm9yZzwvZm9udD48L2Rpdj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxm b250IHNpemU9Mz48Yj5TdWJqZWN0OjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0IGRpcj1ydGw+PGZvbnQgc2l6ZT0zPltjbHVlXSAjMzI6IERlZmluaXRpb25zIG9mIFJv bGVzPC9mb250PjwvZGl2PjwvdGFibGU+DQo8ZGl2IGFsaWduPXJpZ2h0IGRpcj1ydGw+DQo8YnI+ PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4jMzI6IERlZmluaXRpb25zIG9mIFJvbGVzPGJy Pg0KPGJyPg0KIFRoZXJlIGFyZSBhIG51bWJlciBvZiBwbGFjZXMgd2hlcmUgdGhlIHRlcm0gJnF1 b3Q7Um9sZSZxdW90OyBpcyBkZWZpbmVkLg0KJm5ic3A7IFdlIG5lZWQ8YnI+DQogdG8gZmlndXJl IG91dCB3aGljaCBhcmUgbW9zdCBhcHByb3ByaWF0ZSBmb3IgQ0xVRS4gJm5ic3A7IE5vdGUsIHRo aXMgaGFzDQphbHNvPGJyPg0KIGJlZW4gZGlzY3Vzc2VkIG9uIERJU1BBVENIIFdHIG1haWxpbmcg bGlzdDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLTxicj4NCiBhcmNoaXZlL3dlYi9jbHVlL2N1 cnJlbnQvbXNnMDI1MjcuaHRtbDxicj4NCjxicj4NCjxicj4NCiBOb3RlOiBDb21wb25lbnQgd2ls bCBiZSBjaGFuZ2VkIHRvIGRhdGEtbW9kZWwgb25jZSB0aGF0J3MgYSBXRyBkb2N1bWVudC48YnI+ DQo8YnI+DQotLSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQogUmVwb3J0ZXI6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwO093bmVy Ojxicj4NCiAmbmJzcDttYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDtDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbTxicj4NCiAm bmJzcDsgJm5ic3A7IFR5cGU6ICZuYnNwO3Rhc2sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgU3RhdHVzOiAmbmJzcDtuZXc8YnI+DQogUHJpb3JpdHk6ICZuYnNwO2NyaXRpY2FsICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IHwgJm5i c3A7TWlsZXN0b25lOiAmbmJzcDttaWxlc3RvbmUxPGJyPg0KQ29tcG9uZW50OiAmbmJzcDtjaGFy dGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO1ZlcnNpb246ICZuYnNwOzEuMDxicj4NCiBTZXZlcml0 eTogJm5ic3A7Q2FuZGlkYXRlIFdHIERvY3VtZW50ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyBLZXl3 b3Jkczo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaWNrZXQgVVJMOiAmbHQ7 aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS90cmFjL3RpY2tldC8zMiZndDs8YnI+ DQpjbHVlICZsdDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS8mZ3Q7PGJyPg0KPGJyPg0K PGJyPg0KPC90dD48L2ZvbnQ+DQo8ZGl2IGFsaWduPXJpZ2h0IGRpcj1ydGw+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KLS0tLS0gTWVzc2Fn ZSBmcm9tICZxdW90O2NsdWUgaXNzdWUgdHJhY2tlciZxdW90OyAmbHQ7dHJhYytjbHVlQHRyYWMu dG9vbHMuaWV0Zi5vcmcmZ3Q7DQpvbiBNb24sIDA4IEp1bCAyMDEzIDE4OjU0OjU4IC0wMDAwIC0t LS0tPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCUgZGlyPXJ0bD4NCjx0cj4NCjx0ZCB3aWR0aD0x NCU+DQo8ZGl2IGFsaWduPWxlZnQgZGlyPXJ0bD48Zm9udCBzaXplPTM+PGI+VG86PC9iPjwvZm9u dD48L2Rpdj4NCjx0ZCB3aWR0aD04NSU+DQo8ZGl2IGFsaWduPXJpZ2h0IGRpcj1ydGw+PGZvbnQg c2l6ZT0zPm1hcmsuZHVja3dvcnRoQHBvbHljb20uY29tLCBtYXJ5LmlldGYuYmFybmVzQGdtYWls LmNvbTwvZm9udD48L2Rpdj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRsPjxm b250IHNpemU9Mz48Yj5jYzo8L2I+PC9mb250PjwvZGl2Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dCBkaXI9cnRsPjxmb250IHNpemU9Mz5jbHVlQGlldGYub3JnPC9mb250PjwvZGl2Pg0KPHRyPg0K PHRkPg0KPGRpdiBhbGlnbj1sZWZ0IGRpcj1ydGw+PGZvbnQgc2l6ZT0zPjxiPlN1YmplY3Q6PC9i PjwvZm9udD48L2Rpdj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXpl PTM+W2NsdWVdICMzMzogU2VjdXJpdHkgZm9yIEZyYW1ld29yaw0KZG9jdW1lbnQ8L2ZvbnQ+PC9k aXY+PC90YWJsZT4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD4NCjxicj48L2Rpdj4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiMzMzogU2VjdXJpdHkgZm9yIEZyYW1ld29yayBkb2N1bWVudDxicj4N Cjxicj4NCiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBmcmFtZXdvcmsgbmVl ZCB0byBiZSBkb2N1bWVudGVkLjxicj4NCiBOb3RlLCB0aGF0IHRoZSBjb250ZW50IHNob3VsZCBi ZSBiYXNlZCBvbiB0aGUgc2VjdXJpdHkgdGhyZWF0cyBpZGVudGlmaWVkPGJyPg0KIGluIHRoZSBy ZXF1aXJlbWVudHMgZG9jdW1lbnQgKFRCRCkgYXMgd2VsbCBhcyBhbnkgYWRkaXRpb25hbCBzZWN1 cml0eTxicj4NCiB0aHJlYXRzIHJlbGF0ZWQgdG8gdGhlIG92ZXJhbGwgZnJhbWV3b3JrIGl0c2Vs Zi48YnI+DQo8YnI+DQotLSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQogUmVwb3J0ZXI6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw O093bmVyOjxicj4NCiAmbmJzcDttYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDttYXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNvbTxicj4N CiAmbmJzcDsgJm5ic3A7IFR5cGU6ICZuYnNwO3Rhc2sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgU3RhdHVzOiAmbmJzcDtuZXc8YnI+DQogUHJpb3JpdHk6ICZuYnNwO2NyaXRpY2FsICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IHwg Jm5ic3A7TWlsZXN0b25lOjxicj4NCkNvbXBvbmVudDogJm5ic3A7ZnJhbWV3b3JrICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fCAmbmJzcDsg Jm5ic3A7VmVyc2lvbjo8YnI+DQogU2V2ZXJpdHk6ICZuYnNwO0FjdGl2ZSBXRyBEb2N1bWVudCAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyBLZXl3b3Jkczo8YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQo8YnI+DQpUaWNrZXQgVVJMOiAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL3dn L2NsdWUvdHJhYy90aWNrZXQvMzMmZ3Q7PGJyPg0KY2x1ZSAmbHQ7aHR0cDovL3Rvb2xzLmlldGYu b3JnL3dnL2NsdWUvJmd0Ozxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGRpdiBhbGln bj1yaWdodCBkaXI9cnRsPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODAwMDgwIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCi0tLS0tIE1lc3NhZ2UgZnJvbSAmcXVvdDtjbHVlIGlzc3VlIHRyYWNr ZXImcXVvdDsgJmx0O3RyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnJmd0Ow0Kb24gTW9uLCAw OCBKdWwgMjAxMyAxODo1ODoyNiAtMDAwMCAtLS0tLTwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAl IGRpcj1ydGw+DQo8dHI+DQo8dGQgd2lkdGg9MTQlPg0KPGRpdiBhbGlnbj1sZWZ0IGRpcj1ydGw+ PGZvbnQgc2l6ZT0zPjxiPlRvOjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODUlPg0KPGRp diBhbGlnbj1yaWdodCBkaXI9cnRsPjxmb250IHNpemU9Mz5tYXJrLmR1Y2t3b3J0aEBwb2x5Y29t LmNvbSwgbWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208L2ZvbnQ+PC9kaXY+DQo8dHI+DQo8dGQ+ DQo8ZGl2IGFsaWduPWxlZnQgZGlyPXJ0bD48Zm9udCBzaXplPTM+PGI+Y2M6PC9iPjwvZm9udD48 L2Rpdj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQgZGlyPXJ0bD48Zm9udCBzaXplPTM+Y2x1ZUBp ZXRmLm9yZzwvZm9udD48L2Rpdj4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249bGVmdCBkaXI9cnRs Pjxmb250IHNpemU9Mz48Yj5TdWJqZWN0OjwvYj48L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0IGRpcj1ydGw+PGZvbnQgc2l6ZT0zPlJlOiBbY2x1ZV0gIzIwOiBBY3Rpb24gaXRl bSB2aWk6DQpSZWplY3RpbmcgQ29uZmlndXJlPC9mb250PjwvZGl2PjwvdGFibGU+DQo8ZGl2IGFs aWduPXJpZ2h0IGRpcj1ydGw+DQo8YnI+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4jMjA6 IEFjdGlvbiBpdGVtIHZpaTogJm5ic3A7UmVqZWN0aW5nIENvbmZpZ3VyZTxicj4NCjxicj4NCkNo YW5nZXMgKGJ5IG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tKTo8YnI+DQo8YnI+DQogKiBvd25l cjogJm5ic3A7QW5keSBQZXBwZXJlbGwgPSZndDsgbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb208 YnI+DQogKiBwcmlvcml0eTogJm5ic3A7bWlub3IgPSZndDsgbWFqb3I8YnI+DQo8YnI+DQo8YnI+ DQpPbGQgZGVzY3JpcHRpb246PGJyPg0KPGJyPg0KJmd0OyBBY3Rpb24gaXRlbSB2aWkgZnJvbSAx OS0yMCBTZXB0LiAyMDEyIGludGVyaW0uPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5keTogQWRkIHRl eHQgdG8gRnJhbWV3b3JrIGZvciByZWplY3RpbmcgQ29uZmlndXJlPGJyPg0KPGJyPg0KTmV3IGRl c2NyaXB0aW9uOjxicj4NCjxicj4NCiBBY3Rpb24gaXRlbSB2aWkgZnJvbSAxOS0yMCBTZXB0LiAy MDEyIGludGVyaW0uPGJyPg0KPGJyPg0KIEFuZHk6IEFkZCB0ZXh0IHRvIEZyYW1ld29yayBmb3Ig cmVqZWN0aW5nIENvbmZpZ3VyZTxicj4NCjxicj4NCiBBcyBkaXNjdXNzZWQgYXQgdmlydHVhbCBp bnRlcmltIG9uIE1heSAyMXN0LCB0aGlzIG5lZWRzIHRvIGJlIG1lbnRpb25lZA0KaW48YnI+DQog dGhlIGZyYW1ld29yaywgc28gdGhhdCB0aGUgc3Vic2VxdWVudCBhY3Rpb25zIGNhbiBiZSBkZXNj cmliZWQuIChFLmcuLDxicj4NCiBkb2VzIHRoZSBwcmlvciBjb25maWd1cmUgcmVtYWluIGluIGVm ZmVjdD8pPGJyPg0KPGJyPg0KIFRoZSBkZXRhaWxzIG9mIGhvdyB0aGlzIGlzIGNvbW11bmljYXRl ZCBiZWxvbmcgaW4gdGhlIHNvbHV0aW9uLjxicj4NCjxicj4NCi0tPGJyPg0KPGJyPg0KLS0gPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KIFJlcG9ydGVyOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT3duZXI6PGJyPg0KICZuYnNw O21hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO21hcmsuZHVja3dvcnRoQHBvbHljb20uY29tPGJyPg0KICZuYnNwOyAmbmJzcDsgVHlw ZTogJm5ic3A7dGFzayAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDtTdGF0dXM6 ICZuYnNwO25ldzxicj4NCiBQcmlvcml0eTogJm5ic3A7bWFqb3IgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7IE1pbGVzdG9uZTo8YnI+DQpDb21wb25lbnQ6ICZuYnNwO2ZyYW1ld29yayAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZu YnNwOyBWZXJzaW9uOjxicj4NCiBTZXZlcml0eTogJm5ic3A7LSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8ICZuYnNwO1Jlc29sdXRpb246PGJyPg0KIEtleXdvcmRzOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+ DQpUaWNrZXQgVVJMOiAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2NsdWUvdHJhYy90aWNr ZXQvMjAjY29tbWVudDoxJmd0Ozxicj4NCmNsdWUgJmx0O2h0dHA6Ly90b29scy5pZXRmLm9yZy93 Zy9jbHVlLyZndDs8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmNsdWUgbWFpbGluZyBsaXN0PGJyPg0KY2x1ZUBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZTxicj4N CjwvdHQ+PC9mb250Pg0KPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pg0K DQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkg YXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlk ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJl c3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Ns b3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24g b3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0 ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8 YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0 YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50 aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3Nl ZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1 cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3Ig dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 0013D53948257BA3_=-- From Christian.Groves@nteczone.com Mon Jul 8 20:37:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777FF11E8112 for ; Mon, 8 Jul 2013 20:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiEnZMPoStv4 for ; Mon, 8 Jul 2013 20:37:45 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42721F9A5F for ; Mon, 8 Jul 2013 20:37:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBALuE21F20QPz/2dsb2JhbAANQwqDO8FOgTODFwEBAQQBAQE1GxsJEgsRAwEBAQEJGgsPAhYnAQgGDQYCAQEFiBKmXpIpji+BQwaDagOUAIR8kXeBSw Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 13:07:43 +0930 Message-ID: <51DB8583.40709@nteczone.com> Date: Tue, 09 Jul 2013 13:37:39 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "clue@ietf.org" References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:37:46 -0000 Hello Roni, How would you envisage using this for CLUE? Would a "CLUE capture ID" attribute need to be defined? i.e. a=appID:2 CLUECapID:1 or something else? Regards, Christian On 29/06/2013 2:31 AM, Mary Barnes wrote: > ---------- Forwarded message ---------- > From: Roni Even > Date: Fri, Jun 28, 2013 at 10:54 AM > Subject: [MMUSIC] FW: New Version Notification for > draft-even-mmusic-application-token-00.txt > To: "mmusic@ietf.org" > > > Hi, > We have submitted this document that defines a mechanism to provide > the mapping between the > SSRCs of RTP streams and the application semantics by defining > extensions to RTP and RTCP messages. > > It defines a new SDP attribute, RTCP SDES message and RTP header > extension for this puropose. The document explains how it can be used > with the different multiplexing proposal (Plan A, Plan B and no plan). > > It can be used also in CLUE to map SSRCs to Clue media capture. > > Please review and send comments > Thanks > Roni Even > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, June 28, 2013 6:27 PM > To: Jonathan Lennox; Qin Wu; Roni Even > Subject: New Version Notification for > draft-even-mmusic-application-token-00.txt > > A new version of I-D, draft-even-mmusic-application-token-00.txt > has been successfully submitted by Roni Even and posted to the > IETF repository. > > Filename: draft-even-mmusic-application-token > Revision: 00 > Title: The Session Description Protocol (SDP) Application > Token Attribute > Creation date: 2013-06-28 > Group: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-00.txt > Status: > http://datatracker.ietf.org/doc/draft-even-mmusic-application-token > Htmlized: > http://tools.ietf.org/html/draft-even-mmusic-application-token-00 > > > Abstract: > The RTP fixed header includes the payload type number and the SSRC > values of the RTP stream. RTP defines how you de-multiplex streams > within an RTP session, but in some use cases applications need > further identifiers in order to identify the application semantics > associated with particular streams within the session. > > This document defines a mechanism to provide the mapping between the > SSRCs of RTP streams and the application semantics by defining > extensions to RTP and RTCP messages. > > > > > The IETF Secretariat > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Tue Jul 9 00:13:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA02D21F9F6F; Tue, 9 Jul 2013 00:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2QFhiFZLtxR; Tue, 9 Jul 2013 00:13:29 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id E7BE821F9F34; Tue, 9 Jul 2013 00:13:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHe321F20QPz/2dsb2JhbAANTcITgneBM4MXAQEBBDgbFRABEAsOCgkWDwkDAgECAUUGDQEHAQGuXpI+j2sHg3ADrD4 Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 16:43:27 +0930 Message-ID: <51DBB813.4060607@nteczone.com> Date: Tue, 09 Jul 2013 17:13:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" , mmusic@ietf.org Subject: Re: [clue] [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 07:13:30 -0000 Hello Randall, I had a look at the draft with respect to CLUE. The main difference between the CLUE usage of language and what is being proposed is the ability for the sender to specify sending AND receiving preferences. The current CLUE model is that an each endpoint Advertises what it can do and then each consumer chooses from this list. This could still result in an asymmetric usage of language (just negotiated differently). You may need to consider the case where there are multiple streams of the same media type with different languages. e.g. an audio conference where one stream is the main audio of the conference and there's a second stream with a translation/s. This is the type of thing CLUE is considering. I'm not sure how this fits in with your work? Some other comments: With regards to the SIP "hint" it wasn't clear to me how this matches the languages in "humintlang-send" and "humintlang-recv". Is it planned that both will be supported in the header? The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller sets media and language) but in the final paragraph of the 7.3 it sounds like the "hint" is only for audio? 7.4 Silly states - How do the language sub-tags come into play here? For example: the endpoint might specify a language for an audio stream which may be valid. If the endpoint also specified a sub-tag with "script" I guess it makes it a silly state? Regards, Christian On 8/07/2013 8:40 AM, Randall Gellens wrote: > At 4:50 PM +1100 3/25/13, Christian Groves wrote: > >> Hello, >> >> One thing that doesn't seem to be noted is an overlap with the work >> of the CLUE WG. There has been some discussion in the CLUE working >> group about adding attributes to captures to describe the language, >> whether sub-titles are used, whether a stream comes from an >> interpreter, etc. Where multiple streams are used I would expect any >> work in this area should be aligned. >> >> Regards, Christian > > Hi Christian, > > Thanks for the info. Would it make sense to talk about this in > Berlin? I agree that if there is overlap in the approaches we should > align them. > > Also, I have an updated draft that was just uploaded. It is now named > 'draft-gellens-mmusic-negotiating-human-language-00' (adding -mmusic > and hence reverting back to -00). > From ron.even.tlv@gmail.com Tue Jul 9 01:42:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF86521F9F0A for ; Tue, 9 Jul 2013 01:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoHFhewxUAKS for ; Tue, 9 Jul 2013 01:42:09 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D5A7C21F9EE6 for ; Tue, 9 Jul 2013 01:42:08 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so4452194wes.39 for ; Tue, 09 Jul 2013 01:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=8fsZ0tdnVnA7tD4BVRq+KX3LC7kkvZVjZvlYKjR2APw=; b=0iUnl3v16mZ9wI18JqafzhC4024/gY0Pc53fYh7YzJdXFY3pAmWvDQzv916G+LwX6n Bwt6EvSHMKb0P4RtZ+yOT6FSvSViKPHF1G6foa8gs7pDSDldVi6S6wk6WUisTB520bhM ZqKjXprqEyebe085Ay6Q8IlQgrD/x/4b5O7gyDsGAMHfduPUCrzXsZRSxITsGHcPl6xx WLm1etGjk/3uzM2AGkUG5ABOBPjUVFCpXvXCKjUlPOQWGx6q/56RlKyMuaq5MpC0nj2S nB8Mrt6/ut5Wm7ZPX4MI/rqykpGxbNiGTD9uY3TAgaUBLeS5zk3U/Rm9s+aUYysDVsYt HEvw== X-Received: by 10.194.20.193 with SMTP id p1mr14149524wje.65.1373359327915; Tue, 09 Jul 2013 01:42:07 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id s19sm59549275wik.11.2013.07.09.01.42.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 01:42:07 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> In-Reply-To: <51DB8583.40709@nteczone.com> Date: Tue, 9 Jul 2013 11:40:25 +0300 Message-ID: <04de01ce7c7f$f72dae60$e5890b20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeUlghD62FOWC7Z8hplVA8xNyLagHaS0jkAQJ/Y4UBU9tMTZqa1aVA Content-Language: en-us Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:42:10 -0000 Hi Christian, This is something we need to look at, is it to a captureID or to a capture encoding. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 09 July, 2013 6:38 AM > To: clue@ietf.org > Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft- > even-mmusic-application-token-00.txt > > Hello Roni, > > How would you envisage using this for CLUE? Would a "CLUE capture ID" > attribute need to be defined? > i.e. a=appID:2 CLUECapID:1 > > or something else? > > Regards, Christian > > On 29/06/2013 2:31 AM, Mary Barnes wrote: > > ---------- Forwarded message ---------- > > From: Roni Even > > Date: Fri, Jun 28, 2013 at 10:54 AM > > Subject: [MMUSIC] FW: New Version Notification for > > draft-even-mmusic-application-token-00.txt > > To: "mmusic@ietf.org" > > > > > > Hi, > > We have submitted this document that defines a mechanism to provide > > the mapping between the > > SSRCs of RTP streams and the application semantics by defining > > extensions to RTP and RTCP messages. > > > > It defines a new SDP attribute, RTCP SDES message and RTP header > > extension for this puropose. The document explains how it can be used > > with the different multiplexing proposal (Plan A, Plan B and no plan). > > > > It can be used also in CLUE to map SSRCs to Clue media capture. > > > > Please review and send comments > > Thanks > > Roni Even > > > > ________________________________________ > > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > > Sent: Friday, June 28, 2013 6:27 PM > > To: Jonathan Lennox; Qin Wu; Roni Even > > Subject: New Version Notification for > > draft-even-mmusic-application-token-00.txt > > > > A new version of I-D, draft-even-mmusic-application-token-00.txt > > has been successfully submitted by Roni Even and posted to the IETF > > repository. > > > > Filename: draft-even-mmusic-application-token > > Revision: 00 > > Title: The Session Description Protocol (SDP) Application > > Token Attribute > > Creation date: 2013-06-28 > > Group: Individual Submission > > Number of pages: 11 > > URL: > > http://www.ietf.org/internet-drafts/draft-even-mmusic-application-toke > > n-00.txt > > Status: > > http://datatracker.ietf.org/doc/draft-even-mmusic-application-token > > Htmlized: > > http://tools.ietf.org/html/draft-even-mmusic-application-token-00 > > > > > > Abstract: > > The RTP fixed header includes the payload type number and the SSRC > > values of the RTP stream. RTP defines how you de-multiplex streams > > within an RTP session, but in some use cases applications need > > further identifiers in order to identify the application semantics > > associated with particular streams within the session. > > > > This document defines a mechanism to provide the mapping between > the > > SSRCs of RTP streams and the application semantics by defining > > extensions to RTP and RTCP messages. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Jul 9 03:59:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5A821F9EEF for ; Tue, 9 Jul 2013 03:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mho+snjOAFwF for ; Tue, 9 Jul 2013 03:59:13 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 2054B21F9EBD for ; Tue, 9 Jul 2013 03:59:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJfs21F20QPz/2dsb2JhbAANQwqDO8FUgS6DFwEBAQQBAQE1GxsJAgwECw4DAwEBAQEJGgQHDwIWHwgBCAYNAQUCAQEFiBKnLpI/ji+BPAcGg2wDlACEfJF3gUs Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 20:29:11 +0930 Message-ID: <51DBECF9.90607@nteczone.com> Date: Tue, 09 Jul 2013 20:59:05 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> <04de01ce7c7f$f72dae60$e5890b20$@gmail.com> In-Reply-To: <04de01ce7c7f$f72dae60$e5890b20$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:59:14 -0000 Hello Roni, It probably would be the capture encoding, however the main question was whether a new attribute would be needed? Christian On 9/07/2013 6:40 PM, Roni Even wrote: > Hi Christian, > This is something we need to look at, is it to a captureID or to a capture > encoding. > > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 09 July, 2013 6:38 AM >> To: clue@ietf.org >> Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft- >> even-mmusic-application-token-00.txt >> >> Hello Roni, >> >> How would you envisage using this for CLUE? Would a "CLUE capture ID" >> attribute need to be defined? >> i.e. a=appID:2 CLUECapID:1 >> >> or something else? >> >> Regards, Christian >> >> On 29/06/2013 2:31 AM, Mary Barnes wrote: >>> ---------- Forwarded message ---------- >>> From: Roni Even >>> Date: Fri, Jun 28, 2013 at 10:54 AM >>> Subject: [MMUSIC] FW: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> To: "mmusic@ietf.org" >>> >>> >>> Hi, >>> We have submitted this document that defines a mechanism to provide >>> the mapping between the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> It defines a new SDP attribute, RTCP SDES message and RTP header >>> extension for this puropose. The document explains how it can be used >>> with the different multiplexing proposal (Plan A, Plan B and no plan). >>> >>> It can be used also in CLUE to map SSRCs to Clue media capture. >>> >>> Please review and send comments >>> Thanks >>> Roni Even >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Friday, June 28, 2013 6:27 PM >>> To: Jonathan Lennox; Qin Wu; Roni Even >>> Subject: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> >>> A new version of I-D, draft-even-mmusic-application-token-00.txt >>> has been successfully submitted by Roni Even and posted to the IETF >>> repository. >>> >>> Filename: draft-even-mmusic-application-token >>> Revision: 00 >>> Title: The Session Description Protocol (SDP) Application >>> Token Attribute >>> Creation date: 2013-06-28 >>> Group: Individual Submission >>> Number of pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-toke >>> n-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >>> Htmlized: >>> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>> >>> >>> Abstract: >>> The RTP fixed header includes the payload type number and the SSRC >>> values of the RTP stream. RTP defines how you de-multiplex streams >>> within an RTP session, but in some use cases applications need >>> further identifiers in order to identify the application semantics >>> associated with particular streams within the session. >>> >>> This document defines a mechanism to provide the mapping between >> the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Jul 9 08:02:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70AE11E8135 for ; Tue, 9 Jul 2013 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkfi+4RA4vQ1 for ; Tue, 9 Jul 2013 08:02:24 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A04221F9C95 for ; Tue, 9 Jul 2013 08:02:22 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id yBK61l0030vyq2s58F2Hhg; Tue, 09 Jul 2013 15:02:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id yF2H1l00K3ZTu2S3RF2H3H; Tue, 09 Jul 2013 15:02:17 +0000 Message-ID: <51DC25F8.5000202@alum.mit.edu> Date: Tue, 09 Jul 2013 11:02:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> <04de01ce7c7f$f72dae60$e5890b20$@gmail.com> In-Reply-To: <04de01ce7c7f$f72dae60$e5890b20$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373382137; bh=NFsXBxnCGP08t1CVx5SZdpm6fBOTtI9womtgZv6bd10=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UnniP/WuYwmbpNl9R2jFFJTgQov1ed1Wii0bPQP0wsi/z1hcZrmcT4VY5PTX8ZTf5 cG5NpQXJGkd+CF2/O8DXHYzdKLjhJWWxerWOzCPmsV/5guFthEWIYK6j0borSL5VjJ 2fWl81WUfSDGMw3MGi5wD9YWwcb48/Cc781MA1vZN+zVsbQMCVp8SPNSRXpTz3pNTO QG9qsDULl4IkHZFFJKPiUY2Ho8ZHy9W2toR7bP3nMQ2mna0PQJ4+22ywcGyb276OW6 IaluPnXFxrCkUjAKv3fqBRQmTclCOqymFyRd7NZKtjv64h3GfoVfqpbHBfM1QJTXqN 8jw659LBtzPDg== Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:02:28 -0000 On 7/9/13 4:40 AM, Roni Even wrote: > Hi Christian, > This is something we need to look at, is it to a captureID or to a capture > encoding. Making it a captureID is insufficient if multiple encodings of the same capture have been configured. So IMO it can't be that. Making it a capture-encoding will cover precisely what we configure, so it is a reasonable choice. But having it be just an Encoding can also work, because at any point in time an encoding is configured with at most one capture. So the encodingID is sufficient to determine the captureID. And having it be just an encodingID would be especially convenient if we describe encodings in SDP, because then the linkage would have some significance even without the clue messaging. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 09 July, 2013 6:38 AM >> To: clue@ietf.org >> Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft- >> even-mmusic-application-token-00.txt >> >> Hello Roni, >> >> How would you envisage using this for CLUE? Would a "CLUE capture ID" >> attribute need to be defined? >> i.e. a=appID:2 CLUECapID:1 >> >> or something else? >> >> Regards, Christian >> >> On 29/06/2013 2:31 AM, Mary Barnes wrote: >>> ---------- Forwarded message ---------- >>> From: Roni Even >>> Date: Fri, Jun 28, 2013 at 10:54 AM >>> Subject: [MMUSIC] FW: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> To: "mmusic@ietf.org" >>> >>> >>> Hi, >>> We have submitted this document that defines a mechanism to provide >>> the mapping between the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> It defines a new SDP attribute, RTCP SDES message and RTP header >>> extension for this puropose. The document explains how it can be used >>> with the different multiplexing proposal (Plan A, Plan B and no plan). >>> >>> It can be used also in CLUE to map SSRCs to Clue media capture. >>> >>> Please review and send comments >>> Thanks >>> Roni Even >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Friday, June 28, 2013 6:27 PM >>> To: Jonathan Lennox; Qin Wu; Roni Even >>> Subject: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> >>> A new version of I-D, draft-even-mmusic-application-token-00.txt >>> has been successfully submitted by Roni Even and posted to the IETF >>> repository. >>> >>> Filename: draft-even-mmusic-application-token >>> Revision: 00 >>> Title: The Session Description Protocol (SDP) Application >>> Token Attribute >>> Creation date: 2013-06-28 >>> Group: Individual Submission >>> Number of pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-toke >>> n-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >>> Htmlized: >>> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>> >>> >>> Abstract: >>> The RTP fixed header includes the payload type number and the SSRC >>> values of the RTP stream. RTP defines how you de-multiplex streams >>> within an RTP session, but in some use cases applications need >>> further identifiers in order to identify the application semantics >>> associated with particular streams within the session. >>> >>> This document defines a mechanism to provide the mapping between >> the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> clue mailing 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 jonathan@vidyo.com Tue Jul 9 11:34:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41EE21F9E94 for ; Tue, 9 Jul 2013 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m77MBOD9Nd8A for ; Tue, 9 Jul 2013 11:34:19 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id E301921F9E88 for ; Tue, 9 Jul 2013 11:34:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 61FD4556FDC; Tue, 9 Jul 2013 14:34:14 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8CE62556F99; Tue, 9 Jul 2013 14:34:10 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 9 Jul 2013 14:33:22 -0400 From: Jonathan Lennox To: Christian Groves Date: Tue, 9 Jul 2013 14:34:10 -0400 Thread-Topic: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt Thread-Index: Ac580sqlJMyYuiAWR6CPhM7r0LwE6Q== Message-ID: References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> In-Reply-To: <51DB8583.40709@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:34:23 -0000 On Jul 8, 2013, at 11:37 PM, Christian Groves wrote: > Hello Roni, >=20 > How would you envisage using this for CLUE? Would a "CLUE capture ID"=20 > attribute need to be defined? > i.e. a=3DappID:2 CLUECapID:1 >=20 > or something else? >=20 > Regards, Christian Not to speak for Roni, but as his co-author, my vague idea is that we'd bin= d appIDs to m-lines (either one per m-line, or multiple per m-line, dependi= ng on whether MMUSIC goes with Plan A or Plan B); then the CLUE channel wou= ld associate appIDs to either encodings or capture encodings (depending on = decisions in this group). > On 29/06/2013 2:31 AM, Mary Barnes wrote: >> ---------- Forwarded message ---------- >> From: Roni Even >> Date: Fri, Jun 28, 2013 at 10:54 AM >> Subject: [MMUSIC] FW: New Version Notification for >> draft-even-mmusic-application-token-00.txt >> To: "mmusic@ietf.org" >>=20 >>=20 >> Hi, >> We have submitted this document that defines a mechanism to provide >> the mapping between the >> SSRCs of RTP streams and the application semantics by defining >> extensions to RTP and RTCP messages. >>=20 >> It defines a new SDP attribute, RTCP SDES message and RTP header >> extension for this puropose. The document explains how it can be used >> with the different multiplexing proposal (Plan A, Plan B and no plan). >>=20 >> It can be used also in CLUE to map SSRCs to Clue media capture. >>=20 >> Please review and send comments >> Thanks >> Roni Even >>=20 >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, June 28, 2013 6:27 PM >> To: Jonathan Lennox; Qin Wu; Roni Even >> Subject: New Version Notification for >> draft-even-mmusic-application-token-00.txt >>=20 >> A new version of I-D, draft-even-mmusic-application-token-00.txt >> has been successfully submitted by Roni Even and posted to the >> IETF repository. >>=20 >> Filename: draft-even-mmusic-application-token >> Revision: 00 >> Title: The Session Description Protocol (SDP) Application >> Token Attribute >> Creation date: 2013-06-28 >> Group: Individual Submission >> Number of pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-= 00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >> Htmlized: >> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>=20 >>=20 >> Abstract: >> The RTP fixed header includes the payload type number and the SSRC >> values of the RTP stream. RTP defines how you de-multiplex streams >> within an RTP session, but in some use cases applications need >> further identifiers in order to identify the application semantics >> associated with particular streams within the session. >>=20 >> This document defines a mechanism to provide the mapping between the >> SSRCs of RTP streams and the application semantics by defining >> extensions to RTP and RTCP messages. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> 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 -- Jonathan Lennox jonathan@vidyo.com From randy@qti.qualcomm.com Tue Jul 9 15:01:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52F21F9B38; Tue, 9 Jul 2013 15:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZJqI+78IdPZ; Tue, 9 Jul 2013 15:01:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 782DD21F8449; Tue, 9 Jul 2013 15:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373407234; x=1404943234; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=pmFXySTM+w7wMt2mmty/HJ43gukfg1gxe6jgz9K4CIw=; b=x0WjA2LYZBmiLoqCK0XCOlEnck1Hm+qia8KZRU8awHGWb1LBHv0PPa4P KX/G3DARKP26Pt+nMdp1eEfsNhloBm5KDwHZbZfU+qtjk7odk1Ssesjke mQ9ZOQ6J2T0q+4QcTW+KnZCErO57ewNYJULEfZU3zQjfbmGhk6csIAgyQ w=; X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="61661349" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 09 Jul 2013 15:00:25 -0700 X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="502268243" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2013 15:00:14 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 15:00:12 -0700 Message-ID: In-Reply-To: <51DBB813.4060607@nteczone.com> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Tue, 9 Jul 2013 14:58:28 -0700 To: Christian Groves From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] X-Mailman-Approved-At: Tue, 09 Jul 2013 18:03:20 -0700 Cc: Randall Gellens , "clue@ietf.org" , mmusic@ietf.org Subject: Re: [clue] [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 22:01:04 -0000 Hi Christian, Thanks for the review and comments. At 5:13 PM +1000 7/9/13, Christian Groves wrote: > I had a look at the draft with respect to CLUE. The main difference > between the CLUE usage of language and what is being proposed is > the ability for the sender to specify sending AND receiving > preferences. The current CLUE model is that an each endpoint > Advertises what it can do and then each consumer chooses from this > list. This could still result in an asymmetric usage of language > (just negotiated differently). The draft doesn't try to accommodate asymmetric usage, since that usually can just happen without detailed technical backing. The "-send" and "-receive" attributes are there because Harald warned that we'd be violating SDP otherwise. If CLUE can allow the caller to indicate in the offer language needs for each stream, this to be taken into accounting in policy bvased routing, and the callee to respond to the offer with a language in common, then perhaps we don't need this proposal at all and can just drop it in favor of CLUE. I admit at this point I am ignorant of CLUE (yes, clueless about CLUE). > You may need to consider the case where there are multiple streams > of the same media type with different languages. e.g. an audio > conference where one stream is the main audio of the conference and > there's a second stream with a translation/s. This is the type of > thing CLUE is considering. I'm not sure how this fits in with your > work? This is a different, and more complex, scenario than what this proposal is trying to solve. This proposal is focused on simpler cases where someone places an emergency call or calls a corporate call center. Possibly this can be just a simple case of the more complex cases? > > Some other comments: > > With regards to the SIP "hint" it wasn't clear to me how this > matches the languages in "humintlang-send" and "humintlang-recv". > Is it planned that both will be supported in the header? I suppose this depends on if the "-send" and "-recv" are really needed, and if so if they should be the same. > > The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller > sets media and language) but in the final paragraph of the 7.3 it > sounds like the "hint" is only for audio? Good catch -- this will need to be sorted out. > > 7.4 Silly states - How do the language sub-tags come into play > here? For example: the endpoint might specify a language for an > audio stream which may be valid. If the endpoint also specified a > sub-tag with "script" I guess it makes it a silly state? > > Regards, Christian > > On 8/07/2013 8:40 AM, Randall Gellens wrote: >> At 4:50 PM +1100 3/25/13, Christian Groves wrote: >> >>> Hello, >>> >>> One thing that doesn't seem to be noted is an overlap with the >>> work of the CLUE WG. There has been some discussion in the CLUE >>> working group about adding attributes to captures to describe the >>> language, whether sub-titles are used, whether a stream comes >>> from an interpreter, etc. Where multiple streams are used I would >>> expect any work in this area should be aligned. >>> >>> Regards, Christian >> >> Hi Christian, >> >> Thanks for the info. Would it make sense to talk about this in >> Berlin? I agree that if there is overlap in the approaches we >> should align them. >> >> Also, I have an updated draft that was just uploaded. It is now >> named 'draft-gellens-mmusic-negotiating-human-language-00' (adding >> -mmusic and hence reverting back to -00). >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Not a shred of evidence exists in favor of the idea that life is serious. --Brendan Gill From mary.ietf.barnes@gmail.com Tue Jul 9 18:09:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501FD21F9AC1 for ; Tue, 9 Jul 2013 18:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfxHiAPwFWgd for ; Tue, 9 Jul 2013 18:09:58 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9660521F9AAE for ; Tue, 9 Jul 2013 18:09:57 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so3420123qeb.13 for ; Tue, 09 Jul 2013 18:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w/Kf6dxpdOTjZbnIo5TwqSanFP6K5uTaAcVfUpgz93w=; b=YvyAF8XjzVHe5zQZmMsvNdrCtL//JIASpyxHKHgwyb7sDz7SIGhiESQSVuy3Knnlij BZtosLcsNtguzgQCmJpCaESW0fNcGGqTf6ZbXiNVeBOFBINJNs03DRmf8qhfm7+GQkI2 7gcMv5CgY354pydbo6fUa1mDE16jFHjZcMz9U8HFFzX5Kw87ni0IHLzSXcnMfis5SDM9 XU+Q/4AfL03U4Vk3F/b1dh7PzarQzl4To7ZUTz2e1+7wYxfGVvQuFyDLSuQ0CUCH82p9 Ex69Z4R9znDUwv8OLPxxIfcSirqiL2SRfFsrFKy15TigPxO2/l7BpVAu/e0kh07vluA4 Gg0Q== MIME-Version: 1.0 X-Received: by 10.49.26.202 with SMTP id n10mr23297165qeg.60.1373418596979; Tue, 09 Jul 2013 18:09:56 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 9 Jul 2013 18:09:56 -0700 (PDT) Date: Tue, 9 Jul 2013 20:09:56 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Please don't cross-post X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 01:09:59 -0000 While I realize posting to multiple mailing lists might seem an expedient thing to do, it is often quite problematic in cases where folks that aren't subscribed to ALL of the multiple mailing lists in the thread respond. That situation requires the moderators (usually WG chairs) to then moderate the messages from non-members - often valid postings but the IETF email lists are typically configured to hold any postings from non-members. A better option is to post a link to the discussion thread in other WGs on the WG mailing lists that might have interest in the topic. While this might seem a tedious comment (i.e., how hard is it to approve messages and whitelist posters?), I moderate over 30 IETF related WG mailing lists, so just a few messages from folks that are not members to each of these lists adds up to a lot of emails in my mailbox and a lot of links to click and passwords to enter. Note, that I also think that cross-posting makes it difficult for folks that file emails per WG to keep track of the topics since the emails can end up spread across multiple folders. Thanks, Mary. From Christian.Groves@nteczone.com Tue Jul 9 23:41:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31421F9ED9 for ; Tue, 9 Jul 2013 23:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qajbhftoV2W for ; Tue, 9 Jul 2013 23:41:33 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA321F9ECE for ; Tue, 9 Jul 2013 23:41:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBABQB3VF20VFL/2dsb2JhbAANTYM7g1W+BIElgxcBAQEEAQEBIA8BBRsbChELGAICBRYLAgIJAwIBAgEVMBMGAgEBBYgSpwdzkR2BJo5MglaBHgOqdYFL Received: from ppp118-209-81-75.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.81.75]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Jul 2013 16:11:29 +0930 Message-ID: <51DD0213.8000202@nteczone.com> Date: Wed, 10 Jul 2013 16:41:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 06:41:33 -0000 Hello, No problem with the draft going forward. I don't think there are any major issues. Some comments below: Abstract: The first sentence seems a bit clunky. As a participant if I'm sitting somewhere I'm really present. Elsewhere telepresence has been defined as: " telepresence: An interactive audio-visual communications experience between remote locations, where the users enjoy a strong sense of realism and presence between participants by optimizing a variety of attributes such as audio and video quality, eye contact, gaze awareness, body language, spatial audio, coordinated environments and natural image size." Perhaps we can pick up the remote locations aspect? Section 2 1st para: Propose to insert a word, "We specifically do not include in our scenarios the <> infrastructure..." Section 2 2nd para: Propose to insert a word, "Microphones pick up sound and audio codec(s)<> produce one or..." Section 2 3rd para: Is the use of M, N and D needed? They're not used anywhere else in the document. Also "content streams" is not used elsewhere. Presentation stream appears to be the common term. Also the word "back" could be removed ie. "...or playing a video for display". Section 2 above list: Modify text " The fundamental parameters describing typical telepresence scenario<> include:" Section 2 list item 3: "Monitors" is broken into "main" and "presentation" should it be the same for "cameras"? Section 2 list item 6 (and general): The terms "screen", "display" and "monitor" are all used interchangeably it would be good to use one term. Section 3 appears to use "screen". Section 2 list item 9: Could we just say "The number of primary screens at each site"? Section 2 list item 10: What is meant by 鈥渢ype鈥 here? Is it the type of presentation or the type of monitor? Section 2 list item 12: "Viewpoint" Should we say "point of capture"? In general should we align the terminology where possible with the framework? Section 2 list item 13: Would it be better to say "...fields or view and how they spatially relate to each other."? Section 2 Last paragraph: "spatial position of the speaker"... Should this be "microphone"? Speaker is a person, loudspeaker is the device. Should check the draft to see that "loudspeaker" is used when a device is meant. Section 2 Last paragraph: What is meant by "single-node" video conferencing unit? Node isn't used anywhere else in the draft. Section 3 1st para: Could the first 2 sentences be removed or changed? I take it we won't be adding more use cases once WGLC is done? Section 3.2 4th para: ", or put up the date" Is this needed? Putting up a date wouldn't maintain full size. Section 3.5 2nd last para: "e. g." seems to have a large space. Section 3.6 1st para: modify "... panoramic views at all the site<>." Section 3.7 1st para: typo "...and spatial layout of p<>rticipants." Regards, Christian On 9/07/2013 5:28 AM, Mary Barnes wrote: > The chairs would like to start a 3 week WGLC for > draft-ietf-clue-telepresence-use-cases-05. > > Please post your review comments, including an indication as to > whether you believe the document is ready to progress, no later than > Sunday, July 28th, 2013 24:00 UTC. > > Thanks, > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Jul 10 07:19:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF52C21E8089 for ; Wed, 10 Jul 2013 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ238CblekJc for ; Wed, 10 Jul 2013 07:19:31 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 8847921E8092 for ; Wed, 10 Jul 2013 07:19:17 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id ybYW1l0040QuhwU57eKGxY; Wed, 10 Jul 2013 14:19:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id yeKG1l00o3ZTu2S3NeKG7W; Wed, 10 Jul 2013 14:19:16 +0000 Message-ID: <51DD6D64.8090406@alum.mit.edu> Date: Wed, 10 Jul 2013 10:19:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51DD0213.8000202@nteczone.com> In-Reply-To: <51DD0213.8000202@nteczone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373465956; bh=ytT5cZZArinWk2zexGK2jPdgpUL71129p3S1tc7+TvM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R0kw+wY80Ai7H95BstVqdI8mcXtwoWnHn2tnzBg0Gq9nYvqA9eEf/i0xsG6CxYc+/ NZfa5eOpsexoNB0FsjJ0froRyC8w+I2ab2KJiRq2D0cViHTC1rA0DqL8FA+Zy0Z7xp UCsvbqQzRV4Mo3Tu+Cd/7qn+g6qCCeAtuQPkvOwbnmEb+231Ms8FDMIUBUfxA00/Wh AEx++5Xp2G5lTZZOwBpfg/y2wZB3bM83kujE9Sxl3k3l0IWJuoJ4PcuijpJ2NUOL4Z gc4o3h+pxv+byTfGOODPAeHi7mokz/Q9RPDAB3Y+Rirr8FT0qYAoevCOW9OLhXYj/Q PA4tP5vr5GNuA== Subject: Re: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:19:36 -0000 (as co-chair) Christian, IMO we can consider your comments below to be WGLC comments. Thanks, Paul On 7/10/13 2:41 AM, Christian Groves wrote: > Hello, > > No problem with the draft going forward. I don't think there are any > major issues. Some comments below: > > Abstract: The first sentence seems a bit clunky. As a participant if I'm > sitting somewhere I'm really present. Elsewhere telepresence has been > defined as: > > " telepresence: An interactive audio-visual communications experience > between remote locations, where the users enjoy a strong sense of > realism and presence between participants by optimizing a variety of > attributes such as audio and video quality, eye contact, gaze awareness, > body language, spatial audio, coordinated environments and natural image > size." > > Perhaps we can pick up the remote locations aspect? > > > Section 2 1st para: Propose to insert a word, "We specifically do not > include in our scenarios the <> infrastructure..." > > Section 2 2nd para: Propose to insert a word, "Microphones pick up sound > and audio codec(s)<> produce one or..." > > Section 2 3rd para: Is the use of M, N and D needed? They're not used > anywhere else in the document. Also "content streams" is not used > elsewhere. Presentation stream appears to be the common term. Also the > word "back" could be removed ie. "...or playing a video for display". > > Section 2 above list: Modify text " The fundamental parameters > describing typical telepresence scenario<> include:" > > Section 2 list item 3: "Monitors" is broken into "main" and > "presentation" should it be the same for "cameras"? > > Section 2 list item 6 (and general): The terms "screen", "display" and > "monitor" are all used interchangeably it would be good to use one term. > Section 3 appears to use "screen". > > Section 2 list item 9: Could we just say "The number of primary screens > at each site"? > > Section 2 list item 10: What is meant by 鈥渢ype鈥 here? Is it the type of > presentation or the type of monitor? > > Section 2 list item 12: "Viewpoint" Should we say "point of capture"? In > general should we align the terminology where possible with the framework? > > Section 2 list item 13: Would it be better to say "...fields or view and > how they spatially relate to each other."? > > Section 2 Last paragraph: "spatial position of the speaker"... Should > this be "microphone"? Speaker is a person, loudspeaker is the device. > Should check the draft to see that "loudspeaker" is used when a device > is meant. > > Section 2 Last paragraph: What is meant by "single-node" video > conferencing unit? Node isn't used anywhere else in the draft. > > Section 3 1st para: Could the first 2 sentences be removed or changed? I > take it we won't be adding more use cases once WGLC is done? > > Section 3.2 4th para: ", or put up the date" Is this needed? Putting up > a date wouldn't maintain full size. > > Section 3.5 2nd last para: "e. g." seems to have a large space. > > Section 3.6 1st para: modify "... panoramic views at all the site<>." > > Section 3.7 1st para: typo "...and spatial layout of p<>rticipants." > > > Regards, Christian > > On 9/07/2013 5:28 AM, Mary Barnes wrote: >> The chairs would like to start a 3 week WGLC for >> draft-ietf-clue-telepresence-use-cases-05. >> >> Please post your review comments, including an indication as to >> whether you believe the document is ready to progress, no later than >> Sunday, July 28th, 2013 24:00 UTC. >> >> Thanks, >> Mary. >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From spromano@unina.it Wed Jul 10 10:19:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB99221F9F13 for ; Wed, 10 Jul 2013 10:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTY1u+fJLbJH for ; Wed, 10 Jul 2013 10:19:26 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABDA21F9DAA for ; Wed, 10 Jul 2013 10:19:10 -0700 (PDT) Received: from [143.225.162.130] ([143.225.162.130]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6AHJ7JT018400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jul 2013 19:19:08 +0200 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_9A930208-A85A-4CFE-B323-76C7F73B51BD" Date: Wed, 10 Jul 2013 19:19:10 +0200 Message-Id: <13C8B6E2-329E-49EB-B66B-C08E61A7171E@unina.it> To: clue@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [clue] Protocol draft attempt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 17:19:30 -0000 --Apple-Mail=_9A930208-A85A-4CFE-B323-76C7F73B51BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello guys, as you probably noticed, we have just submitted a first attempt at = defining a state machine for both the CLUE Media Producer and CLUE Media = Consumer entities. http://www.ietf.org/id/draft-presta-clue-protocol-00.txt Please have a look at it and treat it like no more than a first stone in = the lake of discussion! Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_9A930208-A85A-4CFE-B323-76C7F73B51BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = guys,

as you probably noticed, we have just submitted = a first attempt at defining a state machine for both the CLUE Media = Producer and CLUE Media Consumer entities.


<= div>Please have a look at it and treat it like no more than a first = stone in the lake of = discussion!

Cheers,

Simo= n



      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_9A930208-A85A-4CFE-B323-76C7F73B51BD-- From mary.ietf.barnes@gmail.com Wed Jul 10 10:43:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB221F9F52 for ; Wed, 10 Jul 2013 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PbXbZFvD8Qp for ; Wed, 10 Jul 2013 10:43:41 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B737821F9EAA for ; Wed, 10 Jul 2013 10:43:39 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bn16so2144802qab.5 for ; Wed, 10 Jul 2013 10:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IbjotM8jKwd/kyuClhs4h9R2bgQ6fJ5bfZE2asPZYgg=; b=FyHOoR8iKuQhXHaeAGfaI8ac67Jk+ytZJp+OSDDtqoynqfoGk0GCSBGPgx708lgf83 WzL8cNKwy0k9MM9B2rBQOQ1v/K+dhsVgzT4zzW/2XmCw7jO0ei8guSRSj/VOOB5JugrA GvGbece8p8bZIS3YLXitObPMblgigmCzK8QDwteM9f3YRFCihGndZqcpg7t6O3YkoXnJ n1WeAL7SK+FoFSqCJg1yn9PfUH/FFR1sFRIepb+kYXAfTxcIgWF4MNK6Ppi0NY2aNyqE P+YApsttJiV+vgUdxg8VnTWAcu2B5MUkyKOVYCNR7n5pBRS9u/aiQAyDFplhzd3uJtk3 9i5Q== MIME-Version: 1.0 X-Received: by 10.49.95.97 with SMTP id dj1mr26420832qeb.46.1373478219232; Wed, 10 Jul 2013 10:43:39 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 10 Jul 2013 10:43:39 -0700 (PDT) In-Reply-To: <51DB3AC5.2080201@alum.mit.edu> References: <51DB3AC5.2080201@alum.mit.edu> Date: Wed, 10 Jul 2013 12:43:39 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Minutes: CLUE WG virtual Interim - June 25, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 17:43:41 -0000 I've made that change to the minutes. Note that you may need to refresh your browser to see the updated version. Thanks, Mary. On Mon, Jul 8, 2013 at 5:18 PM, Paul Kyzivat wrote: > Correction re signaling/solution: > > Paul *already* folded Rob's proposal in kyzivat-clue-signaling. But it > hasn't been thoroughly integrated, or even sanity checked by Rob. > > More important - we haven't yet decided that we want to go this way. (That > is captured as (7) in the notes.) > > Thanks, > Paul > > > On 7/8/13 5:04 PM, Mary Barnes wrote: >> >> Hi all, >> >> The minutes from the interim meeting have been uploaded: >> >> http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 >> >> It was a tough meeting to minute, so if there are questions or >> comments, folks might find it helpful to listen to the recording (the >> link is in the minutes), as that's what I needed to do to piece >> together my chicken scratch notes with Paul's. >> >> Folks may have noticed that a number of new tickets were opened. These >> are just to track known issues. I'm finally starting to like the issue >> tracker, but we would still like to limit the addition of new tickets >> to the chairs, however, if document editors would find it helpful, >> please let the chairs know. >> >> Thanks, >> Mary. >> > From Mark.Duckworth@polycom.com Wed Jul 10 10:52:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2596721F9CCC for ; Wed, 10 Jul 2013 10:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-RmYJBkztUO for ; Wed, 10 Jul 2013 10:52:08 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47A21F9CAE for ; Wed, 10 Jul 2013 10:52:08 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 10 Jul 2013 10:51:55 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 10 Jul 2013 10:51:52 -0700 Thread-Topic: [clue] about encoding a single Media Capture into multiple different Capture Encodings simultaniously and mapping Thread-Index: Ac58VZsfO54nMxJrTE2dSoKv9cfW0QBP+YwA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9353@CRPMBOXPRD07.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: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9353CRPMBOXPRD07pol_" MIME-Version: 1.0 Cc: "wang.liang12@zte.com.cn" Subject: Re: [clue] about encoding a single Media Capture into multiple different Capture Encodings simultaniously and mapping X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 17:52:13 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9353CRPMBOXPRD07pol_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gTGlhbmcsDQoNCkEgTWVkaWEgQ29uc3VtZXIgaW4gYW4gTUNVIG1pZ2h0IHdhbnQgdG8g cmVjZWl2ZSBkaWZmZXJlbnQgZW5jb2RpbmdzIG9mIHRoZSBzYW1lIGNhcHR1cmUgc2ltdWx0YW5l b3VzbHkuICBGb3IgZXhhbXBsZSBpdCBjb3VsZCByZWNlaXZlIGEgaGlnaCByZXNvbHV0aW9uIGFu ZCBhIGxvdyByZXNvbHV0aW9uIHZpZGVvIGVuY29kaW5nLCBhbmQgZGlzdHJpYnV0ZSBvbmUgb3Ig dGhlIG90aGVyIHRvIGEgZGlmZmVyZW50IGVuZHBvaW50IE1lZGlhIENvbnN1bWVyIGRlcGVuZGlu ZyBvbiB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoYXQgb3RoZXIgY29uc3VtZXIgYW5kIGJhbmR3aWR0 aCBhdmFpbGFiaWxpdHkuDQoNCk1hcmsNCg0KRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygd2FuZy5saWFuZzEyQHp0 ZS5jb20uY24NClNlbnQ6IE1vbmRheSwgSnVseSAwOCwgMjAxMyAxMTozNiBQTQ0KVG86IGNsdWVA aWV0Zi5vcmcNCkNjOiBjbHVlQGlldGYub3JnOyBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtjbHVlXSBhYm91dCBlbmNvZGluZyBhIHNpbmdsZSBNZWRpYSBDYXB0dXJlIGludG8gbXVs dGlwbGUgZGlmZmVyZW50IENhcHR1cmUgRW5jb2RpbmdzIHNpbXVsdGFuaW91c2x5IGFuZCBtYXBw aW5nDQoNCg0KaGkgdGhlcmUsDQoNCmZyYW1ld29yayBzZWN0aW9uIDggZGVzY2liZXMgb25lIHJl cXVpcmVtZW50Og0KDQogICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgSW5kaXZpZHVhbCBFbmNvZGlu Z3MgaW4gdGhlIGdyb3VwLCB0aGVuIHRoZQ0KICAgQ29uc3VtZXIgY2FuIGNvbmZpZ3VyZSB0aGUg UHJvdmlkZXIsIHZpYSBhIENvbmZpZ3VyZSBtZXNzYWdlLCB0bw0KICAgZW5jb2RlIGEgc2luZ2xl IE1lZGlhIENhcHR1cmUgaW50byBtdWx0aXBsZSBkaWZmZXJlbnQgQ2FwdHVyZQ0KICAgRW5jb2Rp bmdzIGF0IHRoZSBzYW1lIHRpbWUsIHN1YmplY3QgdG8gdGhlIE1heCBDYXB0dXJlIEVuY29kaW5n cw0KICAgY29uc3RyYWludCwgd2l0aCBlYWNoIGNhcHR1cmUgZW5jb2RpbmcgZm9sbG93aW5nIHRo ZSBjb25zdHJhaW50cyBvZg0KICAgYSBkaWZmZXJlbnQgSW5kaXZpZHVhbCBFbmNvZGluZy4NCg0K IGluIHdoYXQgc2l0dWF0aW9uIHRoZSBjb25zdW1lciBuZWVkcyB0aGUgc2FtZSBtZWRpYSBjYXB0 dXJlIGluIGRpZmZlcmVudCBpbmRpdmlkdWFsIGVuY29kaW5ncyBzaW11bHRhbmlvdXNseT8NCg0K YW5kIGFib3V0IHRoZSBtYXBwaW5nIGlzIHRoYXQgYmV0dGVyIGlmIHdlIHVzZSBhbiBhZGRpdGlv bmFsIGRlbXVsdGlwbGV4SUQgd2hpY2ggaXMgZnJvbSBjYXB0dXJlSUQtZW5jb2RpbmdJRC4NCmJl Y2F1c2UgaW4gdGhlIGR5bmFtaWMgbWFwcGluZyBtZXRob2QgbGlrZSBSVFAgaGVhZCBleHRlbnRp b24gaWYgd2UgdXNlIG11bHRpcGxleElEIHdlIG9ubHkgbmVlZCBvbmUgUlRQIGV4dGVudGlvbi4N CkJ1dCBpZiB3ZSB1c2UgdHdvIGZpZWxkcyhjYXB0dXJlSUQtZW5jb2RpbmdJRCkgaXQgd2lsbCB0 YWtlIHR3byBleHRlbnRpb25zLg0KdGhlIGNvbnN1bWVyIGNhbiBjb25maWd1cmUgdGhlIGRlbXVs dGlwbGV4SUQgaW4gdGhlIGNvbmZpZ3VyZSBtZXNzYWdlLg0KDQoNClRoYW5rIHlvdSBhbmQgQmVz dCByZWdhcmRzLA0KTGlhbmcNCg0KDQoNCmNsdWUtcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86Y2x1 ZS1yZXF1ZXN0QGlldGYub3JnPg0Kt6K8/sjLOiAgY2x1ZS1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmc+DQoNCjIwMTMvMDcvMDkgMDI6NTgNCsfrtPC4tCC4+A0K Y2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCg0KDQrK1bz+yMsNCg0KY2x1ZUBp ZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCg0Ks63LzQ0KDQrW98ziDQoNCmNsdWUgRGln ZXN0LCBWb2wgMzIsIElzc3VlIDQNCg0KDQoNCg0KDQoNCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVu dHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxp c3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0bw0KDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0 IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4 dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBm b3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCg0KDQoN ClNlbmQgY2x1ZSBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgICAgICAgICBj bHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0KDQpUbyBzdWJzY3JpYmUgb3IgdW5z dWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCiAgICAgICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCm9yLCB2aWEgZW1haWws IHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KICAgICAgICAg ICAgICAgIGNsdWUtcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86Y2x1ZS1yZXF1ZXN0QGlldGYub3Jn Pg0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCiAgICAg ICAgICAgICAgICBjbHVlLW93bmVyQGlldGYub3JnPG1haWx0bzpjbHVlLW93bmVyQGlldGYub3Jn Pg0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBp cyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgY2x1ZSBkaWdlc3QuLi4iDQpU b2RheSdzIFRvcGljczoNCg0KICAxLiBSZTogaGkgdGhlcmUsIHF1ZXN0aW9uIGFib3V0IHRoZSBz dGF0aWMgbWFwcGluZyBpbg0KICAgICBkcmFmdCdodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMDAjc2VjdGlvbi00LjUnDQogICAgIChSb25pIEV2 ZW4pDQogIDIuIFJlOiBoaSB0aGVyZSwgcXVlc3Rpb24gYWJvdXQgdGhlIHN0YXRpYyBtYXBwaW5n IGluDQogICAgIGRyYWZ0J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1 ZS1ydHAtbWFwcGluZy0wMCNzZWN0aW9uLTQuNScNCiAgICAgKFBhdWwgS3l6aXZhdCkNCiAgMy4g QWRvcHRpbmcgZHJhZnQtcHJlc3RhLWNsdWUtZGF0YS1tb2RlbC1zY2hlbWEgYXMgYSBXRyBkb2N1 bWVudA0KICAgICAoTWFyeSBCYXJuZXMpDQogIDQuICAjMzI6IERlZmluaXRpb25zIG9mIFJvbGVz IChjbHVlIGlzc3VlIHRyYWNrZXIpDQogIDUuICAjMzM6IFNlY3VyaXR5IGZvciBGcmFtZXdvcmsg ZG9jdW1lbnQgKGNsdWUgaXNzdWUgdHJhY2tlcikNCiAgNi4gUmU6ICMyMDogQWN0aW9uIGl0ZW0g dmlpOiAgUmVqZWN0aW5nIENvbmZpZ3VyZQ0KICAgICAoY2x1ZSBpc3N1ZSB0cmFja2VyKQ0KDQoN Ci0tLS0tIE1lc3NhZ2UgZnJvbSBSb25pIEV2ZW4gPHJvbmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNv bTxtYWlsdG86cm9uaS5ldmVuQG1haWwwMS5odWF3ZWkuY29tPj4gb24gTW9uLCA4IEp1bCAyMDEz IDA5OjE4OjA0ICswMDAwIC0tLS0tDQpUbzoNCg0KIndhbmcubGlhbmcxMkB6dGUuY29tLmNuPG1h aWx0bzp3YW5nLmxpYW5nMTJAenRlLmNvbS5jbj4iIDx3YW5nLmxpYW5nMTJAenRlLmNvbS5jbjxt YWlsdG86d2FuZy5saWFuZzEyQHp0ZS5jb20uY24+PiwgImpvbmF0aGFuQHZpZHlvLmNvbTxtYWls dG86am9uYXRoYW5AdmlkeW8uY29tPiIgPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRo YW5AdmlkeW8uY29tPj4NCg0KY2M6DQoNCiJjbHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYu b3JnPiIgPGNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0Og0K DQpSZTogW2NsdWVdIGhpIHRoZXJlLCBxdWVzdGlvbiBhYm91dCB0aGUgc3RhdGljIG1hcHBpbmcg aW4gZHJhZnQnaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1t YXBwaW5nLTAwI3NlY3Rpb24tNC41Jw0KDQoNCg0KSGksDQpUaGUgcXVlc3Rpb24gaXMgd2hhdCBp cyBtYXBwZWQsIGlzIGl0IG1hcHBpbmcgb2YgYSBzcGVjaWZpYyBTU1JDIGFuZCBtLWxpbmUgdG8g dGhlIGFkdmVydGlzZW1lbnQgLGl0IHdpbGwgbmVlZCB0byBiZSBtYXBwZWQgdG8gY2FwdHVyZUlE Lg0KUm9uaQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogd2FuZy5s aWFuZzEyQHp0ZS5jb20uY248bWFpbHRvOndhbmcubGlhbmcxMkB6dGUuY29tLmNuPiBbd2FuZy5s aWFuZzEyQHp0ZS5jb20uY25dDQpTZW50OiBNb25kYXksIEp1bHkgMDgsIDIwMTMgMTI6MTAgUE0N ClRvOiBqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT47IFJvbmkg RXZlbg0KU3ViamVjdDogaGkgdGhlcmUsIHF1ZXN0aW9uIGFib3V0IHRoZSBzdGF0aWMgbWFwcGlu ZyBpbiBkcmFmdCdodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRw LW1hcHBpbmctMDAjc2VjdGlvbi00LjUnDQoNCg0KSGkgdGhlcmUsDQoNCkkgbm90aWNlZCB0aGF0 IGluIHRoZSBjbHVlLXJ0cC1tYXBwaW5nIGRyYWZ0LiB5b3UgZGVzY3JpYmVkIGEgc3RhdGljIG1h cHBpbmcgbWV0aG9kIGFuZCBhbHNvIGdhdmUgdGhlIGV4YW1wbGUgcXVvdGVkIGJlbG93Og0KDQog ICAgIG09dmlkZW8gNDkyMDAgUlRQL0FWUCA5OQ0KICAgICBhPWV4dG1hcDoxIHVybjppZXRmOnBh cmFtczpydHAtaGRyZXg6Y2x1ZS1jYXB0dXJlLWlkIC8gZm9yIHN1cHBvcnQNCiAgICAgb2YgZHlu YW1pYyBtYXBwaW5nDQogICAgIGE9cnRwbWFwOjk5IEgyNjQvOTAwMDANCiAgICAgYT1tYXgtc2Vu ZC1zc3JjOnsqOjZ9DQogICAgIGE9bWF4LXJlY3Ytc3NyYzp7Kjo0fQ0KICAgICBhPXNzcmM6MTEx MTEgQ2FwdHVyZUlEOjENCiAgICAgYT1zc3JjOjIyMjIyIENhcHR1cmVJRDoyDQogICAgIGE9c3Ny YzozMzMzMyBDYXB0dXJlSUQ6Mw0KICAgICBhPXNzcmM6NDQ0NDQgQ2FwdHVyZUlEOjQNCiAgICAg YT1zc3JjOjU1NTU1IENhcHR1cmVJRDo1DQogICAgIGE9c3NyYzo2NjY2NiBDYXB0dXJlSUQ6Ng0K DQp3ZSBjYW4gc2VlIHRoZSBzdGF0aWMgbWFwcGluZyBoZXJlIGlzIGJldHdlZW4gdGhlIHNzcmMg YW5kIENhcHR1cmVJRCBidXQgbm90IHJlbGF0ZWQgd2hpdCB0aGUgY2FwdHVyZS1lbmNvZGluZy1J RC4NCndoZW4gdGhlIGNvbnN1bWVyIHdhbnRzIHRvIHNlbGVjdCBvbmUgQ2FwdHVyZUlEICBidXQg dXNlIGRpZmZlcmVudCBpbmRpdmlzdWFsIGVuY29kaW5nIGl0IGNhbid0IGRpc3Rpbmd1aXNoIHRo ZSBzdHJlYW1zIGZyb20gdGhpcyBraW5kIG9mIG1hcHBpbmcuDQpmb3IgZXhhbXBsZSwgdGhlIHBy b3ZpZGVyIHN1cHBvcnRzIHR3byBkaWZmZXJlbnQgaW5kaXZpc3VhbCBlbmNvZGluZ3MoRU5DMCwg RU5DMSkgd2l0aCBkaWZmZXJlbnQgYml0cmF0ZSwgcGljdHVyZSBzaXplIGFuZCBwcm9jZXNzZWQg cGl4ZWxzIHJhdGUgaW4gZW5jb2RpbmcgZ3JvdXAwKEVHMCkuDQpUaGUgcHJvdmlkZSBhc3NvY2lh dGUgdGhlIG1lZGlhIGNhcHR1cmUgVkMwIHdpdGggRUcwLiBUaGUgY29uc3VtZXIgd2FudHMgdGhl IFZDMCB1c2luZyBib3RoIEVOQzAgYW5kIEVOQzEgc2ltdWx0YW5lb3VzbHkuDQppbiB0aGlzIGNh c2UgY2FuIHdlIHVzZSB0aGUgc3RhdGljIG1hcHBpbmcgbGlrZSB0aGlzPyBEbyB3ZSBoYXZlIG90 aGVyIG1lYXRob2QgdG8gc3VwcG9ydCB0aGlzIGNhc2U/DQoNCm09dmlkZW8gNDkyMDAgUlRQL0FW UCA5OQ0KYT1ydHBtYXA6OTkgSDI2NC85MDAwMA0KLi4uDQogICAgIGE9c3NyYzoxMTExMSBDYXB0 dXJlSUQ6MSBFbmNvZGluZ0lEOkVOQzANCiAgICAgYT1zc3JjOjIyMjIyIENhcHR1cmVJRDoxIEVu Y29kaW5nSUQ6RU5DMQ0KDQoNClRoYW5rIHlvdSBhbmQgQmVzdCByZWdhcmRzLA0KTGlhbmcNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4g aW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmli dXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRl bHkuDQoNCg0KDQotLS0tLSBNZXNzYWdlIGZyb20gUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IG9uIE1vbiwgMDggSnVsIDIw MTMgMTA6NTI6MjcgLTA0MDAgLS0tLS0NClRvOg0KDQpjbHVlQGlldGYub3JnPG1haWx0bzpjbHVl QGlldGYub3JnPg0KDQpTdWJqZWN0Og0KDQpSZTogW2NsdWVdIGhpIHRoZXJlLCBxdWVzdGlvbiBh Ym91dCB0aGUgc3RhdGljIG1hcHBpbmcgaW4gZHJhZnQnaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTAwI3NlY3Rpb24tNC41Jw0KDQoNCg0KUm9u aSwNCg0KT24gNy84LzEzIDU6MTggQU0sIFJvbmkgRXZlbiB3cm90ZToNCj4gSGksDQo+DQo+IFRo ZSBxdWVzdGlvbiBpcyB3aGF0IGlzIG1hcHBlZCwgaXMgaXQgbWFwcGluZyBvZiBhIHNwZWNpZmlj IFNTUkMgYW5kDQo+IG0tbGluZSB0byB0aGUgYWR2ZXJ0aXNlbWVudCAsaXQgd2lsbCBuZWVkIHRv IGJlIG1hcHBlZCB0byBjYXB0dXJlSUQuDQoNClRoaXMgZHJhZnQgaGFzbid0IGJlZW4gdXBkYXRl ZCByZWNlbnRseSwgYW5kIGl0IGlzbid0IGNsZWFyIGlmIGl0IHdpbGwNCmJlIGNvbnNpc3RlbnQg d2l0aCB3aGF0ZXZlciBnZXRzIGRlY2lkZWQgYWJvdXQgYnVuZGxpbmcgaW4gTU1VU0lDLiBCdXQg SQ0KdGhvdWdodCBpdCB3YXMgbG9uZyBzZXR0bGVkIHRoYXQgd2UgbmVlZCB0byBtYXAgKmNhcHR1 cmUtZW5jb2RpbmdzKiB0bw0KUlRQIC0gdGhhdCB0aGUgc2FtZSBjYXB0dXJlIG1hcCBiZSBjb25m aWd1cmVkIG1vcmUgdGhhbiBvbmNlLCB0bw0KZGlmZmVyZW50IGVuY29kaW5nLCBhbmQgZWFjaCB0 aGVuIG5lZWRzIHRvIGJlIGNvcnJlbGF0ZWQgdG8gdGhlIHByb3Blcg0Kc3NyYyBpbiBSVFAuDQoN CkkgaGFkIHN1Z2dlc3RlZCB0aGF0IHdlIGNvdWxkIGdldCBieSB3aXRoIG1hcHBpbmcgdGhlIFJU UCB0byBhbg0KZW5jb2RpbmcsIHNpbmNlIGF0IGFueSBwb2ludCBpbiB0aW1lIHRoYXQgZW5jb2Rp bmcgd2lsbCBoYXZlIGJlZW4NCmNvbmZpZ3VyZWQgdG8gYXQgbW9zdCBvbmUgY2FwdHVyZS4gKFNv LCBpZiB5b3Uga25vdyB0aGUgZW5jb2RpbmcgeW91IGNhbg0KbG9vayB1cCB3aGF0IGNhcHR1cmUg aGFzIGJlZW4gY29uZmlndXJlZCB0byBpdCwgYW5kIHNvIGRpc2NvdmVyIHRoZQ0KY2FwdHVyZS1l bmNvZGluZy4pDQoNCklmIHdlIGdvIHdpdGggUm9iJ3MgcHJvcG9zYWwgdG8gcmVwcmVzZW50IGVu Y29kaW5ncyBhcyBtLWxpbmVzIGluIFNEUCwNCnRoZW4gdGhlIFJUUCBtYXBwaW5nIGNhbiBqdXN0 IGJlIHRvIGEgbGFiZWwvSUQgYXNzb2NpYXRlZCB3aXRoIHRoYXQgbS1saW5lLg0KDQpJU1RNIGl0 cyB0aW1lIHRvIHVwZGF0ZSB0aGlzIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAgVGhhbmtzLA0K ICAgICAgICAgICAgICAgIFBhdWwNCg0KPiBSb25pDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAq RnJvbToqIHdhbmcubGlhbmcxMkB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmxpYW5nMTJAenRlLmNv bS5jbj4gW3dhbmcubGlhbmcxMkB6dGUuY29tLmNuXQ0KPiAqU2VudDoqIE1vbmRheSwgSnVseSAw OCwgMjAxMyAxMjoxMCBQTQ0KPiAqVG86KiBqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0 aGFuQHZpZHlvLmNvbT47IFJvbmkgRXZlbg0KPiAqU3ViamVjdDoqIGhpIHRoZXJlLCBxdWVzdGlv biBhYm91dCB0aGUgc3RhdGljIG1hcHBpbmcgaW4NCj4gZHJhZnQnaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTAwI3NlY3Rpb24tNC41Jw0KPg0K Pg0KPiBIaSB0aGVyZSwNCj4NCj4gSSBub3RpY2VkIHRoYXQgaW4gdGhlIGNsdWUtcnRwLW1hcHBp bmcgZHJhZnQuIHlvdSBkZXNjcmliZWQgYSBzdGF0aWMNCj4gbWFwcGluZyBtZXRob2QgYW5kIGFs c28gZ2F2ZSB0aGUgZXhhbXBsZSBxdW90ZWQgYmVsb3c6DQo+DQo+ICAgICAgICBtPXZpZGVvIDQ5 MjAwIFJUUC9BVlAgOTkNCj4gICAgICAgIGE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1o ZHJleDpjbHVlLWNhcHR1cmUtaWQgLyBmb3Igc3VwcG9ydA0KPiAgICAgICAgb2YgZHluYW1pYyBt YXBwaW5nDQo+ICAgICAgICBhPXJ0cG1hcDo5OSBIMjY0LzkwMDAwDQo+ICAgICAgICBhPW1heC1z ZW5kLXNzcmM6eyo6Nn0NCj4gICAgICAgIGE9bWF4LXJlY3Ytc3NyYzp7Kjo0fQ0KPiAgICAgICAg YT1zc3JjOjExMTExIENhcHR1cmVJRDoxDQo+ICAgICAgICBhPXNzcmM6MjIyMjIgQ2FwdHVyZUlE OjINCj4gICAgICAgIGE9c3NyYzozMzMzMyBDYXB0dXJlSUQ6Mw0KPiAgICAgICAgYT1zc3JjOjQ0 NDQ0IENhcHR1cmVJRDo0DQo+ICAgICAgICBhPXNzcmM6NTU1NTUgQ2FwdHVyZUlEOjUNCj4gICAg ICAgIGE9c3NyYzo2NjY2NiBDYXB0dXJlSUQ6Ng0KPg0KPiB3ZSBjYW4gc2VlIHRoZSBzdGF0aWMg bWFwcGluZyBoZXJlIGlzIGJldHdlZW4gdGhlIHNzcmMgYW5kIENhcHR1cmVJRCBidXQNCj4gbm90 IHJlbGF0ZWQgd2hpdCB0aGUgY2FwdHVyZS1lbmNvZGluZy1JRC4NCj4gd2hlbiB0aGUgY29uc3Vt ZXIgd2FudHMgdG8gc2VsZWN0IG9uZSBDYXB0dXJlSUQgIGJ1dCB1c2UgZGlmZmVyZW50DQo+IGlu ZGl2aXN1YWwgZW5jb2RpbmcgaXQgY2FuJ3QgZGlzdGluZ3Vpc2ggdGhlIHN0cmVhbXMgZnJvbSB0 aGlzIGtpbmQgb2YNCj4gbWFwcGluZy4NCj4gZm9yIGV4YW1wbGUsIHRoZSBwcm92aWRlciBzdXBw b3J0cyB0d28gZGlmZmVyZW50IGluZGl2aXN1YWwNCj4gZW5jb2RpbmdzKEVOQzAsIEVOQzEpIHdp dGggZGlmZmVyZW50IGJpdHJhdGUsIHBpY3R1cmUgc2l6ZSBhbmQgcHJvY2Vzc2VkDQo+IHBpeGVs cyByYXRlIGluIGVuY29kaW5nIGdyb3VwMChFRzApLg0KPiBUaGUgcHJvdmlkZSBhc3NvY2lhdGUg dGhlIG1lZGlhIGNhcHR1cmUgVkMwIHdpdGggRUcwLiBUaGUgY29uc3VtZXIgd2FudHMNCj4gdGhl IFZDMCB1c2luZyBib3RoIEVOQzAgYW5kIEVOQzEgc2ltdWx0YW5lb3VzbHkuDQo+IGluIHRoaXMg Y2FzZSBjYW4gd2UgdXNlIHRoZSBzdGF0aWMgbWFwcGluZyBsaWtlIHRoaXM/IERvIHdlIGhhdmUg b3RoZXINCj4gbWVhdGhvZCB0byBzdXBwb3J0IHRoaXMgY2FzZT8NCj4NCj4gbT12aWRlbyA0OTIw MCBSVFAvQVZQIDk5DQo+ICAgYT1ydHBtYXA6OTkgSDI2NC85MDAwMA0KPiAuLi4NCj4gICAgICAg IGE9c3NyYzoxMTExMSBDYXB0dXJlSUQ6MSBFbmNvZGluZ0lEOkVOQzANCj4gICAgICAgIGE9c3Ny YzoyMjIyMiBDYXB0dXJlSUQ6MSBFbmNvZGluZ0lEOkVOQzENCj4NCj4NCj4gVGhhbmsgeW91IGFu ZCBCZXN0IHJlZ2FyZHMsDQo+IExpYW5nDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4NCj4NCj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1ZSBtYWls aW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+DQoNCg0KDQotLS0tLSBNZXNz YWdlIGZyb20gTWFyeSBCYXJuZXMgPG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPG1haWx0bzpt YXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4+IG9uIE1vbiwgOCBKdWwgMjAxMyAxMzozNjoyNiAt MDUwMCAtLS0tLQ0KVG86DQoNCkNMVUUgPGNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5v cmc+Pg0KDQpTdWJqZWN0Og0KDQpbY2x1ZV0gQWRvcHRpbmcgZHJhZnQtcHJlc3RhLWNsdWUtZGF0 YS1tb2RlbC1zY2hlbWEgYXMgYSBXRyBkb2N1bWVudA0KDQoNCg0KSGkgYWxsLA0KDQpBcyB3YXMg ZGlzY3Vzc2VkIGF0IHRoZSB2aXJ0dWFsIGludGVyaW0gb24gSnVuZSAyNXRoLCB0aGVyZSBpcyBh DQpwcm9wb3NhbCBmb3IgdGhlIFdHIHRvIGFwcHJvdmUgdGhlIGFkb3B0aW9uIG9mDQpkcmFmdC1w cmVzdGEtY2x1ZS1kYXRhLW1vZGVsLXNjaGVtYSBhcyBhIENMVUUgV0cgZG9jdW1lbnQ6DQpodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXByZXN0YS1jbHVlLWRhdGEtbW9kZWwt c2NoZW1hLw0KDQpQbGVhc2UgcmVzcG9uZCAiWWVzIiBvciAiTm8iIGFzIHRvIHdoZXRoZXIgeW91 IGJlbGlldmUgdGhlIGRvY3VtZW50DQpzaG91bGQgYmUgYWRvcHRlZCBubyBsYXRlciB0aGFuIFN1 bmRheSBKdWx5IDE0dGgsIDIwMTMsIHNvIHRoZSBhdXRob3JzDQpoYXZlIHRpbWUgdG8gc3VibWl0 IGFzIGEgV0cgZG9jdW1lbnQgYmVmb3JlIHRoZSBkZWFkbGluZSwgbm90aW5nIHRoYXQNCnRoZXJl IGlzIGEgc2luZ2xlIGRlYWRsaW5lIGZvciBJRVRGLTg3IChKdWx5IDE1dGgsIDI0OjAwIFVUQyku DQoNCklmIHlvdSBoYXZlIHNwZWNpZmljIGNvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgUExFQVNF IHBvc3QgdGhvc2UgaW4gYQ0Kc2VwYXJhdGUgdGhyZWFkIHdpdGggYW4gYXBwcm9wcmlhdGUgdGl0 bGUgdG8gZmFjaWxpdGF0ZSB0cmFja2luZy4NCg0KVGhhbmtzLA0KTWFyeS4NCg0KDQpOb3RlOiB3 ZSBhcmUgd29ya2luZyBvbiB0aGUgbWludXRlcyBmcm9tIHRoZSB2aXJ0dWFsIGludGVyaW0gYW5k IHdpbGwNCnBvc3Qgd2l0aGluIHRoZSBuZXh0IDI0IGhvdXJzLg0KDQoNCi0tLS0tIE1lc3NhZ2Ug ZnJvbSAiY2x1ZSBpc3N1ZSB0cmFja2VyIiA8dHJhYytjbHVlQHRyYWMudG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOnRyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnPj4gb24gTW9uLCAwOCBKdWwgMjAx MyAxODo1MToyMCAtMDAwMCAtLS0tLQ0KVG86DQoNCkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUu Y29tPG1haWx0bzpDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbT4sIG1hcnkuaWV0Zi5iYXJu ZXNAZ21haWwuY29tPG1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4NCg0KY2M6DQoN CmNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6DQoNCltjbHVl XSAjMzI6IERlZmluaXRpb25zIG9mIFJvbGVzDQoNCg0KDQojMzI6IERlZmluaXRpb25zIG9mIFJv bGVzDQoNClRoZXJlIGFyZSBhIG51bWJlciBvZiBwbGFjZXMgd2hlcmUgdGhlIHRlcm0gIlJvbGUi IGlzIGRlZmluZWQuICAgV2UgbmVlZA0KdG8gZmlndXJlIG91dCB3aGljaCBhcmUgbW9zdCBhcHBy b3ByaWF0ZSBmb3IgQ0xVRS4gICBOb3RlLCB0aGlzIGhhcyBhbHNvDQpiZWVuIGRpc2N1c3NlZCBv biBESVNQQVRDSCBXRyBtYWlsaW5nIGxpc3Q6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCmFy Y2hpdmUvd2ViL2NsdWUvY3VycmVudC9tc2cwMjUyNy5odG1sDQoNCg0KTm90ZTogQ29tcG9uZW50 IHdpbGwgYmUgY2hhbmdlZCB0byBkYXRhLW1vZGVsIG9uY2UgdGhhdCdzIGEgV0cgZG9jdW1lbnQu DQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJlcG9ydGVyOiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICBPd25lcjoNCiBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86 bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+ICAgICAgICAgfCAgQ2hyaXN0aWFuLkdyb3Zlc0Bu dGVjem9uZS5jb208bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPg0KICAgIFR5 cGU6ICB0YXNrICAgICAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQpQcmlvcml0 eTogIGNyaXRpY2FsICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6ICBtaWxlc3RvbmUxDQpD b21wb25lbnQ6ICBjaGFydGVyICAgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9uOiAgMS4wDQpT ZXZlcml0eTogIENhbmRpZGF0ZSBXRyBEb2N1bWVudCAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L2NsdWUvdHJhYy90aWNrZXQvMzI+DQpjbHVlIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2x1 ZS8+DQoNCg0KDQotLS0tLSBNZXNzYWdlIGZyb20gImNsdWUgaXNzdWUgdHJhY2tlciIgPHRyYWMr Y2x1ZUB0cmFjLnRvb2xzLmlldGYub3JnPG1haWx0bzp0cmFjK2NsdWVAdHJhYy50b29scy5pZXRm Lm9yZz4+IG9uIE1vbiwgMDggSnVsIDIwMTMgMTg6NTQ6NTggLTAwMDAgLS0tLS0NClRvOg0KDQpt YXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNvbTxtYWlsdG86bWFyay5kdWNrd29ydGhAcG9seWNvbS5j b20+LCBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0Bn bWFpbC5jb20+DQoNCmNjOg0KDQpjbHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0K DQpTdWJqZWN0Og0KDQpbY2x1ZV0gIzMzOiBTZWN1cml0eSBmb3IgRnJhbWV3b3JrIGRvY3VtZW50 DQoNCg0KDQojMzM6IFNlY3VyaXR5IGZvciBGcmFtZXdvcmsgZG9jdW1lbnQNCg0KVGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGUgZnJhbWV3b3JrIG5lZWQgdG8gYmUgZG9jdW1lbnRl ZC4NCk5vdGUsIHRoYXQgdGhlIGNvbnRlbnQgc2hvdWxkIGJlIGJhc2VkIG9uIHRoZSBzZWN1cml0 eSB0aHJlYXRzIGlkZW50aWZpZWQNCmluIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgKFRCRCkg YXMgd2VsbCBhcyBhbnkgYWRkaXRpb25hbCBzZWN1cml0eQ0KdGhyZWF0cyByZWxhdGVkIHRvIHRo ZSBvdmVyYWxsIGZyYW1ld29yayBpdHNlbGYuDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJl cG9ydGVyOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBPd25lcjoNCiBtYXJ5Lmll dGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+ICAg ICAgICAgfCAgbWFyay5kdWNrd29ydGhAcG9seWNvbS5jb208bWFpbHRvOm1hcmsuZHVja3dvcnRo QHBvbHljb20uY29tPg0KICAgIFR5cGU6ICB0YXNrICAgICAgICAgICAgICAgICAgICAgfCAgICAg U3RhdHVzOiAgbmV3DQpQcmlvcml0eTogIGNyaXRpY2FsICAgICAgICAgICAgICAgICB8ICBNaWxl c3RvbmU6DQpDb21wb25lbnQ6ICBmcmFtZXdvcmsgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9u Og0KU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICAgfCAgIEtleXdvcmRzOg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv Y2x1ZS90cmFjL3RpY2tldC8zMz4NCmNsdWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jbHVl Lz4NCg0KDQoNCi0tLS0tIE1lc3NhZ2UgZnJvbSAiY2x1ZSBpc3N1ZSB0cmFja2VyIiA8dHJhYytj bHVlQHRyYWMudG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnRyYWMrY2x1ZUB0cmFjLnRvb2xzLmlldGYu b3JnPj4gb24gTW9uLCAwOCBKdWwgMjAxMyAxODo1ODoyNiAtMDAwMCAtLS0tLQ0KVG86DQoNCm1h cmsuZHVja3dvcnRoQHBvbHljb20uY29tPG1haWx0bzptYXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNv bT4sIG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPG1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbT4NCg0KY2M6DQoNCmNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+DQoN ClN1YmplY3Q6DQoNClJlOiBbY2x1ZV0gIzIwOiBBY3Rpb24gaXRlbSB2aWk6IFJlamVjdGluZyBD b25maWd1cmUNCg0KDQoNCiMyMDogQWN0aW9uIGl0ZW0gdmlpOiAgUmVqZWN0aW5nIENvbmZpZ3Vy ZQ0KDQpDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5p ZXRmLmJhcm5lc0BnbWFpbC5jb20+KToNCg0KKiBvd25lcjogIEFuZHkgUGVwcGVyZWxsID0+IG1h cmsuZHVja3dvcnRoQHBvbHljb20uY29tPG1haWx0bzptYXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNv bT4NCiogcHJpb3JpdHk6ICBtaW5vciA9PiBtYWpvcg0KDQoNCk9sZCBkZXNjcmlwdGlvbjoNCg0K PiBBY3Rpb24gaXRlbSB2aWkgZnJvbSAxOS0yMCBTZXB0LiAyMDEyIGludGVyaW0uDQo+DQo+IEFu ZHk6IEFkZCB0ZXh0IHRvIEZyYW1ld29yayBmb3IgcmVqZWN0aW5nIENvbmZpZ3VyZQ0KDQpOZXcg ZGVzY3JpcHRpb246DQoNCkFjdGlvbiBpdGVtIHZpaSBmcm9tIDE5LTIwIFNlcHQuIDIwMTIgaW50 ZXJpbS4NCg0KQW5keTogQWRkIHRleHQgdG8gRnJhbWV3b3JrIGZvciByZWplY3RpbmcgQ29uZmln dXJlDQoNCkFzIGRpc2N1c3NlZCBhdCB2aXJ0dWFsIGludGVyaW0gb24gTWF5IDIxc3QsIHRoaXMg bmVlZHMgdG8gYmUgbWVudGlvbmVkIGluDQp0aGUgZnJhbWV3b3JrLCBzbyB0aGF0IHRoZSBzdWJz ZXF1ZW50IGFjdGlvbnMgY2FuIGJlIGRlc2NyaWJlZC4gKEUuZy4sDQpkb2VzIHRoZSBwcmlvciBj b25maWd1cmUgcmVtYWluIGluIGVmZmVjdD8pDQoNClRoZSBkZXRhaWxzIG9mIGhvdyB0aGlzIGlz IGNvbW11bmljYXRlZCBiZWxvbmcgaW4gdGhlIHNvbHV0aW9uLg0KDQotLQ0KDQotLQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg IE93bmVyOg0KIG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPG1haWx0bzptYXJ5LmlldGYuYmFy bmVzQGdtYWlsLmNvbT4gICAgICAgICB8ICBtYXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNvbTxtYWls dG86bWFyay5kdWNrd29ydGhAcG9seWNvbS5jb20+DQogICAgVHlwZTogIHRhc2sgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQpQcmlvcml0eTogIG1ham9yICAgICAgICAg ICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgZnJhbWV3b3JrICAgICAgICAg ICAgICAgIHwgICAgIFZlcnNpb246DQpTZXZlcml0eTogIC0gICAgICAgICAgICAgICAgICAgICAg ICB8ICBSZXNvbHV0aW9uOg0KS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv d2cvY2x1ZS90cmFjL3RpY2tldC8yMCNjb21tZW50OjE+DQpjbHVlIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvd2cvY2x1ZS8+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpjbHVlQGlldGYub3JnPG1haWx0bzpjbHVl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1l bnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocyku ICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBy ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv ZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg== --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9353CRPMBOXPRD07pol_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello Lia= ng,

 

A Media Consumer in an MCU might want to = receive different encodings of the same capture simultaneously.  For e= xample it could receive a high resolution and a low resolution video encodi= ng, and distribute one or the other to a different endpoint Media Consumer = depending on the capabilities of that other consumer and bandwidth availabi= lity.

 

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Be= half Of wang.liang12@zte.com.cn
Sent: Monday, July 08, 2013 1= 1:36 PM
To: clue@ietf.org
Cc: clue@ietf.org; clue-bounc= es@ietf.org
Subject: [clue] about encoding a single Media Capture= into multiple different Capture Encodings simultaniously and mapping<= /o:p>

 


hi there,

framework secti= on 8 descibes one requirement:
   
   If there ar= e multiple Individual Encodings in the group, then the
   Cons= umer can configure the Provider, via a Configure message, to
  &= nbsp;encode a single Media Capture into multiple different Capture
   Encodings at the same time, subject to the Max Capture En= codings
   constraint, with each capture encoding following th= e constraints of
   a different Individual Encoding.
&n= bsp;in what situation the consumer needs the same media capture in differen= t individual encodings simultaniously?

and about the mapping is that= better if we use an additional demultiplexID which is from captureID-encod= ingID.
because in the dynamic mapping method like RTP head extention if = we use multiplexID we only need one RTP extention.
But if we use two f= ields(captureID-encodingID) it will take two extentions.
the consumer ca= n configure the demultiplexID in the configure message.


= Thank yo= u and Best regards,
Liang



clue-request@ietf.org
=B7=A2=BC=FE=C8=CB:  clue-bounces@ietf.org

2013/07/09 02:58 =

=C7=EB=B4=F0=B8=B4 =B8=F8
clue@ietf.org

<= td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>

=D6=F7=CC=E2

<= span lang=3DZH-CN style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB<= /o:p>

clue@ietf.org

=B3=AD=CB=CD

clue Digest, Vol 32, Issue= 4

 <= /o:p>




If you have received this digest w= ithout all the individual message
attachments you will need to = update your digest options in your list
subscription.  To = do so, go to

https://www.ietf.org/mailman/listinfo/clue

Cl= ick the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this = option
globally for all the list digests you receive at this po= int.



Send clue mailing list submissions to
=                 clue@ietf.org

To subscribe or unsubsc= ribe via the World Wide Web, visit
        =         https://www.ietf.org/mailman/listinfo/clue
or, via = email, send a message with subject or body 'help' to
  &nb= sp;             clue-request@ietf.org

You can reach the per= son managing the list at
          &nb= sp;     clue-owner@ietf.or= g

When replying, please edit your Subject line so it is= more specific
than "Re: Contents of clue digest..."<= /tt>
Today's Topics:

  1. Re: hi there, questio= n about the static mapping in
     draft'http://= tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5'
     (Roni Even)
  2. Re: hi there, questi= on about the static mapping in
     draft'http:/= /tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5'
     (Paul Kyzivat)
  3. Adopting draft-p= resta-clue-data-model-schema as a WG document
    &nb= sp;(Mary Barnes)
  4.  #32: Definitions of Roles (clu= e issue tracker)
  5.  #33: Security for Framework do= cument (clue issue tracker)
  6. Re: #20: Action item vii:=  Rejecting Configure
     (clue issue trac= ker)



----- Message from Roni Even <roni.even@m= ail01.huawei.com> on Mon, 8 Jul 2013 09:18:04 +0000 -----

= To:

"wang.liang12@zte.com.cn" <wang.liang12@zte.com.cn= >, "jonathan@vidyo.com" <jonathan@vidyo.com>

cc:<= /b>

&quo= t;clue@ietf.org" <clue@ietf.org>

Subject= :

Re= : [clue] hi there, question about <= span dir=3DLTR>the static mapping in draft'http://tools.ietf.org/html/draft= -ietf-clue-rtp-mapping-00#section-4.5= '

 


Hi,
The questi= on is what is mapped, is it mapping of a specific SSRC and m-line to the advertisement ,it will = need to be mapped to = captureID.
Roni

<= p class=3DMsoNormal dir=3DRTL style=3D'margin-bottom:12.0pt;text-align:righ= t;direction:rtl;unicode-bidi:embed'>
From= : wang.lian= g12@zte.com.cn [wang.liang12@zte.com.cn]
Sent:<= span lang=3DAR-SA style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> Monday, July 08, 2013 12:10 PM
<= b>To: jonathan= @vidyo.com; Roni Even
<= span dir=3DLTR style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'= >Subject:<= /span> hi there, question about the static mapping in dra= ft'http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5'


Hi there,

I noticed that in the clu= e-rtp-mapping draft. you described a static mapping<= /span>method and also gave the example quoted= below:

     m=3Dvideo 49200 RTP/AVP = 99
    &= nbsp;a=3Dextmap:1 urn:ietf:params:rtp-hdrex:clue-capture-id / for su= pport
    =  of dynamic mapping
=      a=3Drtpmap:99 H264/90000
     a=3Dmax-send-ssrc:{*:6}
     a=3Dma= x-recv-ssrc:{*:4}
     a=3Dssrc:11111 Cap= tureID:1
  &nbs= p;  a=3Dssrc:22222 CaptureID:2= =
     a=3Dssrc:33333 Cap= tureID:3
  &nbs= p;  a=3Dssrc:44444 CaptureID:4= =
     a=3Dssrc:55555 Cap= tureID:5
  &nbs= p;  a=3Dssrc:66666 CaptureID:6=

we can see the static mapping here is = between the ssrc and CaptureID but not related whit the capture-encoding-ID.
when the co= nsumer wants to select one CaptureID=  but use different indivisual encoding it can't di= stinguish the streams from this kind of mapping.
for example, the provider supports two= different indivisual encodings(ENC0= , ENC1) with different bitrate, picture si= ze and processed pixels rate in encoding group0(EG0<= span dir=3DRTL>).
The provide associate the media ca= pture VC0 with EG0. The consumer wants the VC0 using both ENC0 and ENC1 simultaneously.
<= span dir=3DLTR style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"= '>in this case can we use the static mapping like this? Do we have other meathod to support= this case?
<= span lang=3DAR-SA style=3D'font-size:10.0pt;font-family:"Calibri","sans-ser= if"'>
m=3Dvideo 49200 RTP/AVP 99= =
a=3Drtpmap:99 H264/90000<= span style=3D'font-family:"Times","serif"'> <= span lang=3DAR-SA style=3D'font-size:10.0pt;font-family:"Calibri","sans-ser= if"'>
...
     a=3Dssrc:11111 CaptureID:1 EncodingID:ENC0
     a=3Dssrc:22222 C= aptureID:1 EncodingID:ENC1


Thank you and Best regards,
Liang=
<= br>

--------------------------------------= ------------------
ZTE Information Security Notice: The information contain= ed in this mail (and any attachm= ent transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s= ).  If you<= /span> are not an intended recipient, any disclosure, reproduction, distrib= ution or other dissemination or use of the in= formation contained is strictly prohibited.  If you have received this m= ail in error, please delete it and notify us = immediately.

<= br>
----- Message from Paul= Kyzivat <pkyzivat@alum.mit.edu= > on Mon, 08 Jul 2= 013 10:52:27 -0400 -----

<= span dir=3DLTR>To:

clue@ietf.org

Subject<= span dir=3DRTL>:

Re: [clue] hi there, question about the static mapping in draft'http://= tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00#section-4.5'<= /p>

 


= Roni,

On 7/8/13 5:18 AM, Roni Even wrote= :
> = Hi,
>
= >= m-line to the advertisement ,it will need = to be mapped to captureID.

Thi= s draft hasn't been updated recently, and it isn't clear if it will<= /tt>
be consistent with whatever gets decided about bundlin= g in MMUSIC. But <= span dir=3DLTR>I
thought it was long settled th= at we need to map *capture-encodings* to= <= /span>
RTP - = that the same capture map be configured more than once, to
different encoding, and each then needs to be correlated to the= proper
ssrc in RTP=
encoding, since at any point in time tha= t encoding will have been <= /tt>
configured to at most= one capture. (So, if you know the encoding you can
look up what capture has been configured to it, and so discover the<= /span> capture-encoding= .)

= If we go with Rob's proposal to represent encodings as m-li= nes in SDP, =
then the RTP mapping= can just be to a label/ID associated with that m-line.

ISTM its time to update this draft.
<= br>                <= tt>Thanks,
        &nb= sp;       Paul

> Roni
>
&= gt; -----------------------------------------------------------------------= -
> *From:* wang.liang12@zte.com.cn= [wang.liang12@zte.com.cn]
> *Sent:* Monday, July 08, 2013 12:10 PM
> *To:* jonathan@vidyo.com; Roni Even
> *Subject:* hi there, quest= ion about the static mapping in
> <= /span>draft'http://tools.ietf.org/html/draft-ietf-= clue-rtp-mapping-00#section-4.5'
>
>
> = Hi there= ,
>
> I noticed that in the clu= e-rtp-mapping draft. you described a static<= br>> mapping method and also gave the= example quoted below= :
><= br>>        m=3Dv= ideo 49200 RTP/AVP 99
>   &nbs= p;    a=3Dextmap:1 urn:ietf:param= s:rtp-hdrex:clue-capture-id<= /span> / for support
>        of dynamic mapping
>   =      a=3Drtpmap:99 H264/9000= 0
>        a=3Dmax-send-ssrc:{*:6}
> &n= bsp;      a=3Dmax-recv-ssrc:= {*:4}
>        a=3Dssrc:11111 CaptureID:1
= >        a=3Dssrc:22= 222 CaptureID:2
>     &nb= sp;  a=3Dssrc:33333 CaptureID:3=
>        = a=3Dssrc:44444 CaptureID:4
>        a= =3Dssrc:55555 CaptureID:5
>   =      a=3Dssrc:66666 CaptureI= D:6
>
> we can see the static mappin= g here is between the ssrc and CaptureID= <= /span> but> not related whit the capture-enco= ding-ID.<= span lang=3DAR-SA>
> when the cons= umer wants to select one CaptureID  but use different
> indiv= isual encoding it can't distinguish the streams from this kind<= span dir=3DRTL> of=
> mapping.
> for example, the provider= supports two different indivisual
>= ; encodings(ENC0, ENC1) with different bitr= ate, picture size and processed
> <= /span>pixels rate in encoding group0(EG0).
> The provide associate the med= ia capture VC0 with EG0. The consumer wants> the VC0 using both ENC0 and ENC1 s= imultaneously.=
> in this= case can we use the static mapping like this? Do we have other=
> meathod to s= upport this case?
>
> m=3Dvideo 49200 RTP/AVP 99
>   a=3D= rtpmap:99 H264/90000
> ...
>        a=3Dssrc:11111 CaptureID:1 EncodingID:ENC0
>        a=3Dssrc:22222 CaptureID:1 EncodingID:ENC1
>
>=
> Thank you an= d Best regards,
> Liang<= /span>
>>
>
> --------------------------------------------------------<= /span>
> Z= TE Information Security Notice: The information contained in this mail (and a= ny attachment transmitted herewith) is privileged and confidential and is int= ended for the exclusive use of the addressee(s<= /span> are = not an intended recipient, any disclosure, reproduction, distribution or othe= r dissemination or use of the information contained is strictly= prohibited.  = If you have received this mail in error, please delete it and= notify us immediately.
>=
>
>
>
> ____________= ___________________________________
&g= t; clue mailing list
> clue@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/clue
&= gt;



----- Message from Mary Barnes <mary.ietf.barnes@gmail.com> on Mon, 8 Jul 2013 13:36:26 -0500 -----

To<= span dir=3DRTL>:

CLUE= <clue@ietf.org>=

Subject:<= span dir=3DLTR>

[= clue] Adopting draft-presta-clue-data-model-schema= as a WG document<= /span>

&= nbsp;


Hi all= ,

As was discussed at the virtual interim on June 25th, there is a=
proposal for = the WG to approve the adoption of
= draft-presta-clue-data-model-schema as a CLUE WG docume= nt:
http://datatracker.ietf.o= rg/doc/draft-presta-clue-data-model-schema/

Please respond "Yes= "No" as to whether you believe the document
should be adopted no l= ater than Sunday July 14th, 2013, so the authors
have time to submit as a WG document bef= ore the deadline, noting that
= there is a single deadline for IETF-87 (July 15th, 24:00 UT= C).

If you have specific commen= ts on the document, PLEASE post those in aseparate thread with an appropriate title to f= acilitate tracking.

Thanks,
Mary.


= Note: we are working on the minutes from the virtual interi= m and will
pos= t within the next 24 hours.

=

----- Message from "clue issue tracker" <trac+clu= e@trac.tools.ietf.org<= span dir=3DRTL>> on Mon, 08 Jul 2013 = 18:51:20 -0000 -----

To:=

Christian.Groves@nteczone= .com, mary.ietf.barnes@gmail.com

cc:

clue@ietf.org

Subject:

[clue] #32: Definitions of Roles<= o:p>

 


#32: Definitions of Ro= les

There = are a number of places where the term "Role" is defined.   = We need
<= /span>to figure out which are most appropriate for CLUE= .   = Note, this has= also
been discussed on DISPATCH WG mailing list: http://www.ietf.org/mail-
= archive/web/clue/current/msg02527.html


Note: Component= will be changed to data-model once that's a WG document.

= -------------------------------= ------+-------------------------------------=
Reporter<= tt>:                =           |      <= span dir=3DLTR>Owner:=
 mary.ietf.barnes@gmail.com=        = |  Christian.Groves@nteczone.com
= :  ta= sk     &nbs= p;               |     = Status:  new
Priority:  critical=      =           |  Milestone:  <= /span>milestone1Component:  charter=         &nbs= p;        |    Version:  1.0<= /span>
Severity:  Candidate WG Document    |   Keywor= ds:
-------------------------------------+-----------------= --------------------

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

<= o:p>



----- Message from= "= clue issue tracker" <trac+clue@trac.tools.ietf.org> = on Mon, 08 Jul 2013 18:54:58 -0000 ----- =

To= mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com<= /span>

cc<= span dir=3DRTL>:

clue@ietf.org

Subject:=

[clue= ] #33: Security for Framework document

 


#33: Security for Framework document

The security considerations for the framework need = to be documented.
Note, that the co= ntent should be based on the security threats identified
in the requirements document (TB= D) as well as any additional security
threats related to the overall framework itself.

--
--------------= -----------------------+-------------------------------------
Reporter:           &nb= sp;               |      = Owner:
 mary.ietf.barnes@g= mail.com   &= nbsp;     |  mark.duckworth@polycom.com
    Type:  task  =                   |   &n= bsp; Status<= span dir=3DRTL>:  new
Priority:  critical   &= nbsp;             |  Milestone:
Component:  framework                |    = ;Version= :
Severity: &nbs= p;Active WG Document       |   Keywords:
----------------------------= ---------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/clue/trac/ti= cket/33>
clue <http://tools.ietf.org/wg/clue/>

<= br>
----- Message from "clue issue tracker" <trac+clue@trac.tools.ietf.org&g= t; on Mon, 08 Jul 2013 18:58:26 -0000 -----

To= :<= /o:p>

mark.duckworth@polycom.com,= mary.ietf.barnes@gmail.com

cc:=

clue@ietf.org

Su= bject:

Re: [clue] #20: Action item vii: Rejecting= Configure

 


#20: Action= item vii:  Rejecting Configure

Changes (by mary.ietf.barnes@gmail.com):

*= owner:  Andy Pepperell =3D> mark.duckworth@polyc= om.com
* priority: &nbs= p;minor<= tt> =3D> major


Old description<= /span>:

> Action item vii f= rom 19-20 Sept. 2012 interim= .
>
> Andy: Add text to Framewo= rk for rejecting Configure

New description:

Action item vii from 19-20 Sept. 2012 interim.

<= tt>Andy: Add text to Framework for rejecting Configure

As discussed a= t virtual interim on May 21st, this needs to be mentioned= in
the framework, so that the sub= sequent actions can be described. (E.g.,
does the prior configure remain in effect?)

= The details of how this is communicated belong in the s= olution.<= span lang=3DAR-SA>

--

--=
------------------------------------= -+-------------------------------------
<= /span>Reporter:                 &nb= sp;         |       Owner:
 mary.ietf.barnes@gmail.com         | =  = mark.duckworth@polycom.com
  =   Type<= span dir=3DRTL>:  task         &= nbsp;           |      = Status:  new
Priority<= span dir=3DRTL>:  major<= /tt>         =            |   Milestone:
Component<= /tt>:  framework =                |     Version<= span lang=3DAR-SA style=3D'font-family:"Times New Roman","serif"'>:
Severity:  -=                     &nbs= p;  |  Resolution:
<= /span>Keywords:                 &nb= sp;         |
= ----= ---------------------------------+-------------------------------------

Ticket URL: <htt= p://tools.ietf.org/wg/clue/trac/ticket/20#comment:1>
clue <http://tools.ietf.org/wg/clue/>


_______= ________________________________________
= clue mailing list=
clue@ietf.o= rg
https://www.ietf.org/mailma= n/listinfo/clue

 

= 
 
--------------------------------------------------------=

ZTE Information Sec=
urity Notice: The information contained in this mail (and any attachment tr=
ansmitted herewith) is privileged and confidential and is intended for the =
exclusive use of the addressee(s).  If you are not an intended recipie=
nt, any disclosure, reproduction, distribution or other dissemination or us=
e of the information contained is strictly prohibited.  If you have re=
ceived this mail in error, please delete it and notify us immediately.=

 =

 = 

 
----------------------------------------------------=
----
ZTE Information=
 Security Notice: The information contained in this mail (and any attachmen=
t transmitted herewith) is privileged and confidential and is intended for =
the exclusive use of the addressee(s).  If you are not an intended rec=
ipient, any disclosure, reproduction, distribution or other dissemination o=
r use of the information contained is strictly prohibited.  If you hav=
e received this mail in error, please delete it and notify us immediately.<=
o:p>
 

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9353CRPMBOXPRD07pol_-- From trac+clue@trac.tools.ietf.org Wed Jul 10 12:59:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3249421F9DE2 for ; Wed, 10 Jul 2013 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFZ6L-DlFhJt for ; Wed, 10 Jul 2013 12:59:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 897C021F99BB for ; Wed, 10 Jul 2013 12:59:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:34436 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ux0Y3-00053P-TP; Wed, 10 Jul 2013 21:59:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: christian.groves@nteczone.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Wed, 10 Jul 2013 19:59:35 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/clue/trac/ticket/25#comment:2 Message-ID: <083.3d6c90e3c54eae6cbbc3673265ed4660@trac.tools.ietf.org> References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: christian.groves@nteczone.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:59:46 -0000 #25: Advertisement: Complete "all" or "delta" Changes (by mary.ietf.barnes@gmail.com): * component: framework => charter Old description: > Issue a from 19-20 Sept. 2012 interim > > Need to decide whether advertisement is complete information "all" or > just a "delta" [Note: current framework is "all"] > > Issue was discussed again at May 21, 2013 interim: > http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- > interim-2013-clue-1 > General sense that this is a solution issue. However, Christian doesn't > necessarily agree. Action: Christian/Roni figure out if and where this > should be addressed in FW. New description: Issue a from 19-20 Sept. 2012 interim Need to decide whether advertisement is complete information "all" or just a "delta" [Note: current framework is "all"] Issue was discussed again at May 21, 2013 interim: http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- interim-2013-clue-1 Agreement that this decision must be part of the signaling solution. However, Christian believes that the approach decided should also be documented in the framework. Action: Christian/Roni figure out if and where this should be addressed in FW. WG: make the fundamental solution for the signaling solution document. -- -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | christian.groves@nteczone.com Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: charter | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Wed Jul 10 12:59:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1E21F9E5A for ; Wed, 10 Jul 2013 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlFb-RYLLCww for ; Wed, 10 Jul 2013 12:59:52 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57E21F99BB for ; Wed, 10 Jul 2013 12:59:52 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so4006003qeb.31 for ; Wed, 10 Jul 2013 12:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JqZ9MpmzSq9rwM+ZS5Z8dJeREbSQ1hWuobJB8uoN4o0=; b=TCvsVuZv550hx7oB0GCITxcMXNOard4ErOvsvGd3jLV8la1SdsjVZTDXkb6252vvCz edhkBYuFFTr9ROFAaqyuUkFU56ufn7w8frA8D72YbqKzYqM7rDiey8p0099vVxB7yJuN 2imyGoE+ymqqYu2NnQNHQWGmRP+mE0z4A1KmMK3XtLKdcvQ3njK9biTaTpJuSvg1EN1g L4sgWFHXUZVgR9znwSSkz8N4CsKSCAnPN9hmUgS+pQJ2CFjU1AvrIYUU+PZKCCMTUKco PInnwAz7Hxgp2LR7BEVbaaI7ALl/P7/JNfCN06lq4e78Sg+8F9ZmsS/Yw18XjPS8aKDG FyEw== MIME-Version: 1.0 X-Received: by 10.224.147.145 with SMTP id l17mr17162958qav.3.1373486391029; Wed, 10 Jul 2013 12:59:51 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 10 Jul 2013 12:59:50 -0700 (PDT) In-Reply-To: <51DB8087.1080507@nteczone.com> References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> <083.5e956f464c27fe371fc79aa878979600@trac.tools.ietf.org> <51DB388B.4030103@alum.mit.edu> <51DB8087.1080507@nteczone.com> Date: Wed, 10 Jul 2013 14:59:50 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 19:59:53 -0000 Then the debate is still whether we need something in the framework. Personally, I think that's an implementation/solution detail and really an optimization and not a fundamental requirement for realization of the FW in a solution. I don't think anyone's debating that this would be documented and detailed in the solution document. I can open a separate issue, but I personally don't think that's necessary as long as the text in the issue is correct - I've updated the text slightly. If you don't think this captures the current state properly, then post alternative text for that issue. Mary. On Mon, Jul 8, 2013 at 10:16 PM, Christian Groves wrote: > Hello Mary and Paul, > > I agree that the details need to be worked out in the signalling document. > My comment was more related to that the framework should contain a short > summary of what ever is worked out in the signalling document. It should be > possible for someone to read the framework document and have an overview of > how CLUE is used (including whether an all or delta approach is used). > > We can't add the summary until we figure out what we'll use in the > signalling document. > > Regards, Christian > > > On 9/07/2013 10:20 AM, Mary Barnes wrote: >> >> This issue is because Christian does not think it is just a signaling >> issue. Per the text in the ticket: >> " General sense that this is a solution issue. However, Christian >> doesn't necessarily agree. Action: Christian/Roni?figure out if and >> where this should be addressed in FW." >> >> Once we get consensus that it's not a FW issue, we can close and then >> open a new issue or just update this one. >> >> Mary. >> >> On Mon, Jul 8, 2013 at 5:09 PM, Paul Kyzivat >> wrote: >>> >>> (as individual) >>> >>> IMO this should be an issue for signaling, not the framework. >>> I consider it a level of detail below what the framework needs to >>> mention. >>> >>> Of course we don't yet have a *wg* signaling draft to target this to. >>> >>> Thanks, >>> Paul >>> >>> >>> On 7/8/13 3:05 PM, clue issue tracker wrote: >>>> >>>> #25: Advertisement: Complete "all" or "delta" >>>> >>>> Changes (by mary.ietf.barnes@gmail.com): >>>> >>>> * owner: draft-ietf-clue-framework@tools.ietf.org => >>>> christian.groves@nteczone.com >>>> * severity: - => Active WG Document >>>> >>>> >>>> Old description: >>>> >>>>> Issue a from 19-20 Sept. 2012 interim >>>>> >>>>> Need to decide whether advertisement is complete information "all" or >>>>> just a "delta" [Note: current framework is "all"] >>>> >>>> >>>> New description: >>>> >>>> Issue a from 19-20 Sept. 2012 interim >>>> >>>> Need to decide whether advertisement is complete information "all" or >>>> just >>>> a "delta" [Note: current framework is "all"] >>>> >>>> Issue was discussed again at May 21, 2013 interim: >>>> >>>> http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- >>>> interim-2013-clue-1 >>>> General sense that this is a solution issue. However, Christian >>>> doesn't >>>> necessarily agree. Action: Christian/Roni figure out if and where >>>> this >>>> should be addressed in FW. >>>> >>>> -- >>>> >>>> Comment: >>>> >>>> Ticket update to reflect new assignee and discussion from May 21st, >>>> 2013 >>>> interim. >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Jul 10 14:22:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080BB11E8124 for ; Wed, 10 Jul 2013 14:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkD+X1PjVNHo for ; Wed, 10 Jul 2013 14:22:44 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FE21F9DB2 for ; Wed, 10 Jul 2013 14:22:43 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id ybLc1l00316LCl054lNiyW; Wed, 10 Jul 2013 21:22:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ylNi1l00l3ZTu2S3SlNiTJ; Wed, 10 Jul 2013 21:22:42 +0000 Message-ID: <51DDD0A1.50703@alum.mit.edu> Date: Wed, 10 Jul 2013 17:22:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <13C8B6E2-329E-49EB-B66B-C08E61A7171E@unina.it> In-Reply-To: <13C8B6E2-329E-49EB-B66B-C08E61A7171E@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373491362; bh=eanhEPQE9AB/HK6qSiYAvPKsBpy6B4Key2hQUOkyvMI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CxZCmPSnFxYhcXuFWe60mHAkZl31S1bMab84SVHE+oVDcLIOi5u4pLywpNFehKDeP j+FDGK02zVw4S9FaKoaZy2fFv6K9uw8XaDg8dymy8HoL1ipfHUpZG0HZbdXcQcJGjG FgKRUic2ZjpHzcx5XjDBZAu7qFwqvY4IYUY0x/62uayCbdknL3TPeAKMvimtj0xgF8 jgGc/VYnFL+LdlcUQErxKgaJNL5QcxDmw10UiPqYAuHiUqTcz2xlx2cr0Stq0Yz9Ya 3VezltZNQSDq6bGJ8e3hQZGPX7ZhLeDo8FzTLSKEbwU7dr8YlF0j9dbMyOUANoaWqC A6oByMOV61kfw== Subject: Re: [clue] Protocol draft attempt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 21:22:54 -0000 (as individual) Simon & Paula, Thanks for doing this! I have some questions about it: You have separate state machines for MP and MC, and note that typically a node will be both. Are you assuming the messages for both will flow over the same data channel? (I assume so.) If so, then I guess there must be a low level demux that sorts out the incoming messages and directs them to either the MP or MC state machine. And if it becomes necessary to add any other messages it will be necessary to ensure that the same message type can't be received by both the MC and the MP. You propose that RE-ADV contain a reason. While I understand 'refresh' as a reason, don't the other reasons you mention duplicate the response code that would presumably have been sent first? If the reason is because there was something incorrect in the prior ADV, is there any reason to expect that it will get better when retried? I guess we at least ought to recognize that some things can't be fixed by RE-ADV, and have a more extreme transition. (Perhaps to reinitialize the data channel.) Re both state machines: obviously we need to think about timeouts. ISTM that however we set the timeout value, it can result from either a transport level problem or an application level problem. Presumably transport level problems will be detected by the transport itself, and we may have no control over the timeout level for that. If its like TCP, then it is probably longer than we would want to wait, so we may get a timeout at application level that reflects a transport problem, and that can't be distinguished from an application level problem. If its a transport problem, then there is no point in retrying, since the reliable transport will have done what it can and an application level retry will be behind that. Even if we knew we had an application level problem, is it worthwhile to retry it over the same data channel? I see that you call for every ADV to get a response. Were you thinking of a tight timeout here, or a loose one. In MC state machine: I think it will be easy to get into an infinite loop between ADV RECEIVED and TRYING when the CONF is not acceptable. We need to find a way to break that loop. Again, I'm not sure how ofter a retry at this level will be helpful. I think there is a missing transition: if in TRYING due to having sent a CONF from IN CALL, then it is possible to receive another ADV before the response to the CONF. This is also the case where the subsequent response to the CONF might be an error. But then the fix is to send a CONF to the *new* ADV, rather than the old one. In MP state machine: If in WAIT FOR CONF and take the "change tp settings" transition, will end up back in WAIT FOR CONF. But now there will be *two* CONFs coming, one for each ADV sent. Assuming the messages are properly coded, then it will be possible to detect that one is for the wrong ADV. I guess this is covered by the "send error response" transition from CONF RECEIVED to WAIT FOR CONF. But, as above, having this singe error transition opens possibility of an infinite loop. Can fix this one with a separate transition from CONF RECEIVED to itself when the received CONF is for and old ADV. Thanks, Paul On 7/10/13 1:19 PM, Simon Pietro Romano wrote: > Hello guys, > > as you probably noticed, we have just submitted a first attempt at > defining a state machine for both the CLUE Media Producer and CLUE Media > Consumer entities. > > http://www.ietf.org/id/draft-presta-clue-protocol-00.txt > > Please have a look at it and treat it like no more than a first stone in > the lake of discussion! > > Cheers, > > Simon From roberta.presta@unina.it Thu Jul 11 08:14:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29821F9005 for ; Thu, 11 Jul 2013 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvSXyZnxOP7z for ; Thu, 11 Jul 2013 08:14:13 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 50DCA21F88D2 for ; Thu, 11 Jul 2013 08:14:12 -0700 (PDT) Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6BFDofr032174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 17:14:06 +0200 Message-ID: <51DECBAE.2070307@unina.it> Date: Thu, 11 Jul 2013 17:13:50 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <13C8B6E2-329E-49EB-B66B-C08E61A7171E@unina.it> <51DDD0A1.50703@alum.mit.edu> In-Reply-To: <51DDD0A1.50703@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130711-1, 11/07/2013), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] Protocol draft attempt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 15:14:18 -0000 Hi Paul, please see below. Il 10/07/2013 23:22, Paul Kyzivat ha scritto: > (as individual) > > Simon & Paula, > > Thanks for doing this! I have some questions about it: > > You have separate state machines for MP and MC, and note that > typically a node will be both. Are you assuming the messages for both > will flow over the same data channel? (I assume so.) Yes, we assume the messages flowing over the same data channel. > If so, then I guess there must be a low level demux that sorts out the > incoming messages and directs them to either the MP or MC state > machine. And if it becomes necessary to add any other messages it will > be necessary to ensure that the same message type can't be received by > both the MC and the MP. > Exactly. > You propose that RE-ADV contain a reason. > While I understand 'refresh' as a reason, don't the other reasons you > mention duplicate the response code that would presumably have been > sent first? > If the reason is because there was something incorrect in the prior > ADV, is there any reason to expect that it will get better when retried? > I guess we at least ought to recognize that some things can't be fixed > by RE-ADV, and have a more extreme transition. (Perhaps to > reinitialize the data channel.) > Probably it is better to keep semantically apart the request of a refresh from the notification of advertisement errors. However, something could be automatically modified (both in the ADV and in the CONF) when the rejection reason is understood - for example a not supported option/extension/version could be omitted or changed, or a malformed and optional XML part of the message could be removed. About response codes/reason phrases, even if there is overlapping, we have started to consider separately errors delivered to the MP and errors delivered to the MC. > Re both state machines: > > obviously we need to think about timeouts. > ISTM that however we set the timeout value, it can result from either > a transport level problem or an application level problem. > Presumably transport level problems will be detected by the transport > itself, and we may have no control over the timeout level for that. > If its like TCP, then it is probably longer than we would want to > wait, so we may get a timeout at application level that reflects a > transport problem, and that can't be distinguished from an application > level problem. > > If its a transport problem, then there is no point in retrying, since > the reliable transport will have done what it can and an application > level retry will be behind that. > > Even if we knew we had an application level problem, is it worthwhile > to retry it over the same data channel? > Undoubtely timeouts are needed, they are a common application-level solution exploited even when the underlying transport channel is reliable. Clearly the timeout settings should take into account the possible transport-level timers. > I see that you call for every ADV to get a response. Were you thinking > of a tight timeout here, or a loose one. > When an ADV is sent, the MP waits for a message coming from the MC, hopefully a CONF (WAIT FOR CONF). However, other events can happen like a change in the tp settings of a refresh request coming from the MC. These events triggers a new ADV updating the previous one and resetting the timer. If nothing happens and the timeout expires, and there are less than N exceeded timeouts, then a new ADV is sent and the previous one is considered expired. I am not sure of having understood your question :) > In MC state machine: > > I think it will be easy to get into an infinite loop between ADV > RECEIVED and TRYING when the CONF is not acceptable. We need to find a > way to break that loop. Again, I'm not sure how ofter a retry at this > level will be helpful. You are right, there is a possible loop. It has to be managed with a retry counter mechanism. > > I think there is a missing transition: if in TRYING due to having sent > a CONF from IN CALL, then it is possible to receive another ADV before > the response to the CONF. This is also the case where the subsequent > response to the CONF might be an error. But then the fix is to send a > CONF to the *new* ADV, rather than the old one. > Yes, there is a missing transition and you provide the solution. When in TRYING, if a new ADV arrives (ADV-2), the MC moves to the ADV RECEIVED state. Here, if arrives the response to the CONF-1 before the CONF-2 is issued, there should be a self-transition that keeps the MC into the ADV RECEIVED state preparing the CONF-2 command (i.e., ignoring the -error- response to CONF-1 coming from the MP). > In MP state machine: > > If in WAIT FOR CONF and take the "change tp settings" transition, will > end up back in WAIT FOR CONF. But now there will be *two* CONFs > coming, one for each ADV sent. Assuming the messages are properly > coded, then it will be possible to detect that one is for the wrong > ADV. I guess this is covered by the "send error response" transition > from CONF RECEIVED to WAIT FOR CONF. You guess right, maybe it needs to be clarified both in the text and in the diagram. > But, as above, having this singe error transition opens possibility of > an infinite loop. Can fix this one with a separate transition from > CONF RECEIVED to itself when the received CONF is for and old ADV. > There is the possibility of an infinite loop between WAIT FOR CONF and CONF RECEIVED if the CONF keeps to be rejected. This problem could be solved with a retry counter too. Cheers, Roberta > Thanks, > Paul > > On 7/10/13 1:19 PM, Simon Pietro Romano wrote: >> Hello guys, >> >> as you probably noticed, we have just submitted a first attempt at >> defining a state machine for both the CLUE Media Producer and CLUE Media >> Consumer entities. >> >> http://www.ietf.org/id/draft-presta-clue-protocol-00.txt >> >> Please have a look at it and treat it like no more than a first stone in >> the lake of discussion! >> >> Cheers, >> >> Simon > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Thu Jul 11 10:01:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17C21F9956 for ; Thu, 11 Jul 2013 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=2.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQN8uWjxHuVa for ; Thu, 11 Jul 2013 10:01:03 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF921F9970 for ; Thu, 11 Jul 2013 10:01:03 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 11 Jul 2013 10:00:59 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 10:00:58 -0700 Thread-Topic: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt Thread-Index: Ac59OIh/pZGat8dRRsi8m3TAVqYBdgBHlzjA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC97D4@CRPMBOXPRD07.polycom.com> References: <51DD0213.8000202@nteczone.com> In-Reply-To: <51DD0213.8000202@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:01:07 -0000 SSB0aGluayB0aGUgdXNlIGNhc2UgZG9jdW1lbnQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MuDQoNCkkg aGF2ZSBjb21tZW50cyBvbiBhIGZldyBvZiBDaHJpc3RpYW4ncyBjb21tZW50cy4NCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBDaHJpc3RpYW4gR3Jv dmVzDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMCwgMjAxMyAyOjQxIEFNDQo+IFRvOiBjbHVl QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gV0dMQzogaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLWNsdWUtDQo+IHRlbGVwcmVzZW5jZS11c2UtY2FzZXMtMDUudHh0DQoN Cj4gU2VjdGlvbiAyIExhc3QgcGFyYWdyYXBoOiAic3BhdGlhbCBwb3NpdGlvbiBvZiB0aGUgc3Bl YWtlciIuLi4gU2hvdWxkIHRoaXMgYmUNCj4gIm1pY3JvcGhvbmUiPyBTcGVha2VyIGlzIGEgcGVy c29uLCBsb3Vkc3BlYWtlciBpcyB0aGUgZGV2aWNlLg0KPiBTaG91bGQgY2hlY2sgdGhlIGRyYWZ0 IHRvIHNlZSB0aGF0ICJsb3Vkc3BlYWtlciIgaXMgdXNlZCB3aGVuIGEgZGV2aWNlIGlzDQo+IG1l YW50Lg0KW0R1Y2t3b3J0aCwgTWFya10gSSB0aGluayBpdCB3YXMgbWVhbnQgdG8gYmUgcG9zaXRp b24gb2YgdGhlIHBlcnNvbiB0YWxraW5nLCBidXQgSSdtIG5vdCBzdXJlIHRoYXQgaXMgcmVhbGx5 IHdoYXQgd2Ugd2FudCB0byBzYXkuICBUaGUgaGlnaGVyIGxldmVsIHBvaW50IGlzIHRvIHNwYXRp YWxseSBhbGlnbiB0aGUgYXVkaW8gYW5kIHZpZGVvIHdpdGggZWFjaCBvdGhlciwgSSB0aG91Z2h0 IHdhcyB3aGF0IHRoaXMgd2FzIG1lYW50IHRvIGJlIGFib3V0LiAgTWF5YmUgcmVwbGFjZSBpdCB3 aXRoICJzcGF0aWFsIGFsaWdubWVudCBvZiBhdWRpbyB3aXRoIHZpZGVvIi4NCg0KPiBTZWN0aW9u IDIgTGFzdCBwYXJhZ3JhcGg6IFdoYXQgaXMgbWVhbnQgYnkgInNpbmdsZS1ub2RlIiB2aWRlbyBj b25mZXJlbmNpbmcNCj4gdW5pdD8gTm9kZSBpc24ndCB1c2VkIGFueXdoZXJlIGVsc2UgaW4gdGhl IGRyYWZ0Lg0KW0R1Y2t3b3J0aCwgTWFya10gTWF5YmUgdXNlICJzaW5nbGUgc3RyZWFtIiBpbnN0 ZWFkPyAgKENMVUUgaXMgImNvbnRyb2xsaW5nIF9tdWx0aXBsZV8gc3RyZWFtcyBmb3IgdGVsZXBy ZXNlbmNlIikNCg0KPiBTZWN0aW9uIDMuMiA0dGggcGFyYTogIiwgb3IgcHV0IHVwIHRoZSBkYXRl IiBJcyB0aGlzIG5lZWRlZD8gUHV0dGluZyB1cCBhIGRhdGUNCj4gd291bGRuJ3QgbWFpbnRhaW4g ZnVsbCBzaXplLg0KW0R1Y2t3b3J0aCwgTWFya10gSXQgc2VlbXMgb2theSB0byBtZS4gIFRoZSBl eGFtcGxlIGlzIHVzaW5nIG9uZSBmdWxsIGRpc3BsYXkgZm9yIG9uZSBmdWxsIGNhbWVyYSBpbWFn ZSwgd2l0aCBhIGRhdGUgb3IgYW55dGhpbmcgZWxzZSBvbiBvdGhlciBkaXNwbGF5cyB0aGF0IGFy ZSBub3QgdXNlZCBmb3IgdmlkZW8uDQoNCk1hcmsNCg== From Mark.Duckworth@polycom.com Thu Jul 11 10:07:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5D621F9C17 for ; Thu, 11 Jul 2013 10:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HfjGK6wfC84 for ; Thu, 11 Jul 2013 10:07:13 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3667E21F9C01 for ; Thu, 11 Jul 2013 10:07:13 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 11 Jul 2013 10:07:12 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 10:07:11 -0700 Thread-Topic: [clue] Adopting draft-presta-clue-data-model-schema as a WG document Thread-Index: Ac58U8sXHXPZ1q3qTT66CwrfZfOJ1ACBPYNg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC97DD@CRPMBOXPRD07.polycom.com> References: <51DB8252.2050105@nteczone.com> In-Reply-To: <51DB8252.2050105@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Adopting draft-presta-clue-data-model-schema as a WG document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:07:17 -0000 YES, and I agree the data model and framework documents need to be made con= sistent. I intend to follow up on Ticket #35: "Ensure Framework and Data model termi= nology is consistent". This could result in changes to both documents. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Monday, July 08, 2013 11:24 PM > To: clue@ietf.org > Subject: Re: [clue] Adopting draft-presta-clue-data-model-schema as a WG > document >=20 > Hello Mary, >=20 > YES but there are things (e.g. micPattern, aspect ratio) in the data mode= l that > are not described in the framework. I'd support it as a WG draft that ali= gns > with the framework. >=20 > Regards, Christian >=20 > On 9/07/2013 4:36 AM, Mary Barnes wrote: > > Hi all, > > > > As was discussed at the virtual interim on June 25th, there is a > > proposal for the WG to approve the adoption of > > draft-presta-clue-data-model-schema as a CLUE WG document: > > http://datatracker.ietf.org/doc/draft-presta-clue-data-model-schema/ > > > > Please respond "Yes" or "No" as to whether you believe the document > > should be adopted no later than Sunday July 14th, 2013, so the authors > > have time to submit as a WG document before the deadline, noting that > > there is a single deadline for IETF-87 (July 15th, 24:00 UTC). > > > > If you have specific comments on the document, PLEASE post those in a > > separate thread with an appropriate title to facilitate tracking. > > > > Thanks, > > Mary. > > > > > > Note: we are working on the minutes from the virtual interim and will > > post within the next 24 hours. > > _______________________________________________ > > 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@alum.mit.edu Thu Jul 11 10:10:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A218921F8168 for ; Thu, 11 Jul 2013 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj+RtuTSYEsd for ; Thu, 11 Jul 2013 10:10:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3102F21F9C17 for ; Thu, 11 Jul 2013 10:10:35 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta08.westchester.pa.mail.comcast.net with comcast id z0uc1l0070ldTLk585Ab7t; Thu, 11 Jul 2013 17:10:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id z5Ab1l0033ZTu2S015Absh; Thu, 11 Jul 2013 17:10:35 +0000 Message-ID: <51DEE70A.80206@alum.mit.edu> Date: Thu, 11 Jul 2013 13:10:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373562635; bh=9h9DaL5qTqMKn/GK/z0lKk/jyDYtZ1qgRokEMwx3BwI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cmiFTS8Pa3SdovGFmASTpakiz6amZXGRUDlJB6BXQX/qgxAnUMk2fqZ1tea0qP0+e fZYm6ShNAy1CgFY+WT3BV1sER7Rszsue5Tqe5oQOp3ZX+msRnH/HQ6ovjuhaX1Fl/Y uqQsOa9d7b5lnCMolC4i8WV6CwqFdFmHPE/p/NbhTcw+Y6lWxVnBoPsBoXNBYYXE1i jOZCaouefKX89YkpWr9jR+Srazwt8rb1+XaTW9fGXDrfvLDxptfoYL/yYEefmYPzhT OKQOFezzGw7CYJHmBpNgkB58bVwCflR7uNl1fHINkjWN6yzwj2GHHgTcnPP4nqXx7G i9Oag5TTHZICg== Cc: CLUE Subject: Re: [clue] Adopting draft-presta-clue-data-model-schema as a WG document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:10:45 -0000 On 7/8/13 2:36 PM, Mary Barnes wrote: > Please respond "Yes" or "No" as to whether you believe the document > should be adopted YES. (speaking as an individual.) Thanks, Paul From mary.ietf.barnes@gmail.com Thu Jul 11 12:46:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382521F968B for ; Thu, 11 Jul 2013 12:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESJPdVC7ik5n for ; Thu, 11 Jul 2013 12:46:45 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A3AE921F967F for ; Thu, 11 Jul 2013 12:46:45 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so4747183qeb.1 for ; Thu, 11 Jul 2013 12:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CXZx1gO1zH8mFyW2/sd0Z3HaFEq66DRJTur39cq1unk=; b=RANflVuCuxHNf4JoHoF9Z4QPe+au8ZLSZiiLSNwzO+bJ853eMEpVAyQ/LG3YzyfmGt kayu9u7SEcP3PZGXUqJgsswUEIFPPTsUutbfM/sEa83WXyWD+bgUikhkcxR0Dxm55oeJ 6OGAWMhh+zYOEr2lNAbwzfle0Kl4T9zT4qhwGym1mcZq+sBmJCxC93p5Z9ugerZNg8UM BD8DHwm9s8szUKlZYGyE6k7Jd8u1BQHM+ZPhydF4fWygBfG2aGILg5gzxXgYHITqWTNj 5c49oGzg+ynlI50EwCquxzYxbJ9ELKKw+Naj5mI8dG4ZhpwbH40tegxqIlb8JBF5ILS3 Ka0g== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr31403329qeb.6.1373572005046; Thu, 11 Jul 2013 12:46:45 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 11 Jul 2013 12:46:45 -0700 (PDT) Date: Thu, 11 Jul 2013 14:46:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 19:46:46 -0000 Please note the final deadline for drafts for IETF-87. Note that there is only a single draft deadline for this meeting so -00 drafts can be submitted up to that point. The chairs are discussing how to arrange the agenda and the obvious items are: - Use cases if there are any issues from WGLC requiring discussion - Framework. Ideally, we can get closure on open issues and agree those that can be resolved by the solution. Note, we won't progress this document until the solution is done so we can always iterate back in cases where we need additional text or changes in the framework. - Roles: draft-groves-clue-role-clarifications - Data model. We may not need any time for this. - Signaling: -- draft-kyzivat-clue-signaling -- draft-presta-clue-protocol If folks have additional items (drafts in particular) that they believe require discussion please let us know. Also, if you have proposals for any of the open issues in the signaling document, we would love to discuss those, in particular it would be great to have updates on the items for which folks volunteered at the interim: http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 Note that I also have the action item to post the open topics and issues for which we may have consensus to the list before the meeting. We will produce a more detailed agenda (with time allocations) no later than next Wednesday. Thanks, Mary and Paul From Mark.Duckworth@polycom.com Thu Jul 11 12:57:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3224521F92BB for ; Thu, 11 Jul 2013 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ieVA-F093qM for ; Thu, 11 Jul 2013 12:57:06 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 81C8221F9EB8 for ; Thu, 11 Jul 2013 12:57:00 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 11 Jul 2013 12:56:33 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 12:56:32 -0700 Thread-Topic: Ticket #20 rejecting configure Thread-Index: Ac5+a9/eBfhFxQvtT9KCXpq74SPXmA== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC993C@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC993CCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Ticket #20 rejecting configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 19:57:11 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC993CCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the description of ticket #20: Add text to Framework for rejecting Configure As discussed at virtual interim on May 21st, this needs to be mentioned in the framework, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. I propose adding a new paragraph to section 9 of the framework. =3D=3D=3D Begin new proposed paragraph =3D=3D=3D A Provider can reject a Configure message for various reasons. For example= , it could be inconsistent with the most recent Advertisement, or the Provi= der may be unable to honor the Configure message because conditions have re= cently changed and the Provider is about to send a new Advertisement. What= ever the reason, the Provider acknowledges receipt of the message and indic= ates to the Consumer that it is rejecting it. The Provider's behavior rega= rding its transmitted capture encodings should not be affected by a rejecte= d Configure message. =3D=3D=3D End new proposed paragraph =3D=3D=3D Any comments or suggestions? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC993CCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the desc= ription of ticket #20:

  Add text t= o Framework for rejecting Configure

&nb= sp; As discussed at virtual interim on May 21st, this needs to be ment= ioned

  in the framework, so that t= he subsequent actions can be described.

=   (E.g., does the prior configure remain in effect?)

  The details of how this is communicated belo= ng in the solution.

 

I propose adding a new paragraph to section 9 of the = framework.

=3D=3D=3D Begin new proposed = paragraph =3D=3D=3D

A Provider can rejec= t a Configure message for various reasons.  For example, it could be i= nconsistent with the most recent Advertisement, or the Provider may be unab= le to honor the Configure message because conditions have recently changed = and the Provider is about to send a new Advertisement.  Whatever the r= eason, the Provider acknowledges receipt of the message and indicates to th= e Consumer that it is rejecting it.  The Provider’s behavior reg= arding its transmitted capture encodings should not be affected by a reject= ed Configure message.

=3D=3D=3D End new = proposed paragraph =3D=3D=3D

 =

Any comments or suggestions?

<= p class=3DMsoNormal> 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC993CCRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Thu Jul 11 13:05:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6221F9D9D for ; Thu, 11 Jul 2013 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pHTOfZg6d2s for ; Thu, 11 Jul 2013 13:05:32 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3A21F9D59 for ; Thu, 11 Jul 2013 13:05:31 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 11 Jul 2013 13:05:03 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 13:05:00 -0700 Thread-Topic: comments on description of RTP topologies Thread-Index: Ac5pBpyrxLMMPtycTZe47c4dFhAReQVarDPg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9946@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60146DF92@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60146DF92@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9946CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] comments on description of RTP topologies X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 20:05:37 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9946CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anybody answer my questions below? In particular, we aren't aiming for= CLUE to support Topo-Video-switch-MCU, correct? Is anybody else interested in clarifying the rtp-mapping document, to more = explicitly use the same terminology for topologies from draft-ietf-avtcore-= rtp-topologies-update? (I assume this avtcore document will become an RFC) Thanks, Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Friday, June 14, 2013 10:35 AM To: clue@ietf.org Subject: [clue] comments on description of RTP topologies This is regarding section 3. RTP topologies for CLUE, in draft-ietf-clue-rt= p-mapping-00. I'm having difficulty relating the topologies described here to the termino= logy described in draft-ietf-avtcore-rtp-topologies-update-00. There doesn= 't seem to be a clean mapping, so I'd like to clarify this and make it clea= ner, using the same terminology. >From the beginning of section 3: "For telepresence, the relevant topologies include point-to-point, as well = as media mixers, media- switching mixers, and source-projection mixers." So for these four categories, I would like to understand how they map to th= e topologies described in draft-ietf-avtcore-rtp-topologies-update. The fo= llowing list describes how I think the two documents relate. Do I understa= nd this correctly? Can we make this more explicit in the CLUE document, to= list the CLUE topologies directly using terminology from the rtp-topologie= s-update document, so we don't have to map it to a new set of CLUE terminol= ogy? 1. point-to-point. This includes: a. Topo-Point-to-Point b. Topo-PtP-Translator - not sure if this is meant to be included or n= ot? c. Back to back RTP sessions - not sure if this is meant to be includ= ed or not? 2. media mixers. This includes: a. Topo-RTCP-terminating-MCU b. Topo-Mixer, Media Mixing variety (3.6.1 of rtp-topologies-update) 3. media switching mixers. This includes: a. Topo-Mixer, Media Switching variety (3.6.2 of rtp-topologies-updat= e) 4. source projection mixers. This includes: a. Source Projecting Middlebox (3.7 of rtp-topologies-update) We should also add De-composite Endpoint (3.10 of rtp-topologies-update), a= s we agreed in the June 2012 interim meeting. I believe we also agreed CLUE is not attempting to support Topo-Video-switc= h-MCU, so I suggest we remove reference to this one. The document refers t= o this as if CLUE supports it, which I think is not the case. I have a related question in avtcore, asking if source projection is intend= ed to be a variety of Topo-Mixer. Mark Duckworth --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9946CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can anybody answer my questions below?  In particular, w= e aren’t aiming for CLUE to support Topo-Video-switch-MCU, correct?

 

= Is anybody else interested in clarifying the rtp-mapping document, to more = explicitly use the same terminology for topologies from draft-ietf-avtcore-= rtp-topologies-update?  (I assume this avtcore document will become an= RFC)

 

Thanks,
Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Friday, June 14, 2013 10:= 35 AM
To: clue@ietf.org
Subject: [clue] comments on des= cription of RTP topologies

 

This is regarding section 3= . RTP topologies for CLUE, in draft-ietf-clue-rtp-mapping-00.

 

I’m h= aving difficulty relating the topologies described here to the terminology = described in draft-ietf-avtcore-rtp-topologies-update-00.  There doesn= ’t seem to be a clean mapping, so I’d like to clarify this and = make it cleaner, using the same terminology.

 

From the beginning of sectio= n 3:

“F= or telepresence, the relevant topologies include point-to-point, as well as= media mixers, media- switching mixers, and source-projection mixers.”= ;

 

So for these four categories, I would like to understand how they map t= o the topologies described in draft-ietf-avtcore-rtp-topologies-update.&nbs= p; The following list describes how I think the two documents relate. = Do I understand this correctly?  Can we make this more explicit in th= e CLUE document, to list the CLUE topologies directly using terminology fro= m the rtp-topologies-update document, so we don’t have to map it to a= new set of CLUE terminology?

 = ;

1.     &nb= sp; point-to-point.  This includes:=

a.   &nbs= p;   Topo-Point-to-Point

= b.    &nbs= p; Topo-PtP-Translator – not sure if this is = meant to be included or not?

c.       Back to back RTP sessions – not sure if this is meant to be includ= ed or not?

2.   &= nbsp;   media mixers.  This includes= :

a. &nbs= p;     Topo-RTCP-terminating-MC= U

b. &nbs= p;    Topo-Mixer, Media Mixing varie= ty (3.6.1 of rtp-topologies-update)

3.       media sw= itching mixers.  This includes:

= a.       Topo-Mixer, Media Switching variety (3.6.2 of rtp-topologies-upd= ate)

4.    &= nbsp;  source projection mixers. This includes= :

a. &nbs= p;     Source Projecting Middle= box (3.7 of rtp-topologies-update)

=  

We should also add De-composite Endpoi= nt (3.10 of rtp-topologies-update), as we agreed in the June 2012 interim m= eeting.

 

I believe we also agreed CLUE is not attempting to support Topo-V= ideo-switch-MCU, so I suggest we remove reference to this one.  The do= cument refers to this as if CLUE supports it, which I think is not the case= .

 

I have a related question in avtcore, asking if source projection is in= tended to be a variety of Topo-Mixer.

 

Mark Duckworth

=
= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9946CRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Thu Jul 11 13:20:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082511E8114 for ; Thu, 11 Jul 2013 13:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-MokO2Nuh81 for ; Thu, 11 Jul 2013 13:20:24 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B221B11E8122 for ; Thu, 11 Jul 2013 13:20:23 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 11 Jul 2013 13:20:23 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 13:20:21 -0700 Thread-Topic: Consumer should always respond to Advertisement with a Configure Thread-Index: Ac5+coQI1oNCmU49QPGZO3nUrQO94Q== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9962@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9962CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Consumer should always respond to Advertisement with a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 20:20:32 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9962CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The framework has these contradicting statements in section 9, and a note a= sking for input: Each Advertisement is acknowledged by a corresponding Configure. The Consumer need not send a new Configure message to the Provider when it receives a new Advertisement from the Provider unless the contents of the new Advertisement cause the Consumer's current Configure message to become invalid. Edt. Note: The editors solicit input from the working group as to whether or not a Consumer must respond to every Advertisement with a new Configure message. I propose we say the Consumer must send a Configure message to acknowledge = an Advertisement, and remove the paragraph about "The Consumer need not sen= d a new Configure ...". This seems to be consistent with the Media Provide= r state machine in draft-presta-clue-protocol-00, which says the Provider e= xpects to receive a Configure after sending an Advertisement. Any comments or suggestions? Thanks, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9962CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The framework ha= s these contradicting statements in section 9, and a note asking for input:=

  Each Advertisement is acknowledg= ed by a corresponding Configure.

&n= bsp;

  The Consumer need not send a new = Configure message to the Provider

 = when it receives a new Advertisement from the Provider unless the

  contents of the new Advertisement cause t= he Consumer’s current

  Confi= gure message to become invalid.

&nb= sp;

  Edt. Note: The editors solicit inp= ut from the working group as to

  w= hether or not a Consumer must respond to every Advertisement with

  a new Configure message.

 

I propose we sa= y the Consumer must send a Configure message to acknowledge an Advertisemen= t, and remove the paragraph about “The Consumer need not send a new C= onfigure …”.  This seems to be consistent with the Media P= rovider state machine in draft-presta-clue-protocol-00, which says the Prov= ider expects to receive a Configure after sending an Advertisement.

 

Any c= omments or suggestions?

 

Thanks,

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9962CRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Thu Jul 11 13:50:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68EC21E805F for ; Thu, 11 Jul 2013 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp1TE4HfuWrD for ; Thu, 11 Jul 2013 13:50:14 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id C55AC21F9FC3 for ; Thu, 11 Jul 2013 13:50:05 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 11 Jul 2013 13:50:05 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Jul 2013 13:50:03 -0700 Thread-Topic: Questions on Tickets #19 and #26 - site switching Thread-Index: Ac5+dzRLhFvf5ZpxQYOiW0/PHVxZcw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC999C@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC999CCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Questions on Tickets #19 and #26 - site switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 20:50:19 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC999CCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just looked more closely at these tickets. I think Tickets #19 and #26 a= re really both about the same thing, but I'm not sure how to address it. #= 19 asks for Jonathan to start a discussion. #26 says: Site Switching: there is an issue when you have multiple captures and do = site switching. It needs to be consistent. May need real-time updates for spatial informa= tion, time synchronization, etc. - e.g., RTCP, XCON notifications. I think my draft-duckworth-clue-switching-example discusses different aspec= ts of switching. If Jonathan or anybody else can help explain more about the Ticket #26 issu= es, and how we should address it in the framework, I'll be happy to add it! Thanks, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC999CCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just looked mo= re closely at these tickets.  I think Tickets #19 and #26 are really b= oth about the same thing, but I’m not sure how to address it.  #= 19 asks for Jonathan to start a discussion.  #26 says:

<= p class=3DMsoNormal>  Site Switching: there is an issue when you have = multiple captures and do site switching.

  It needs to be consistent. May need real-time updates for spatial i= nformation, time

  synchronization,= etc. - e.g., RTCP, XCON notifications.

=  

I think my draft-duckworth-clue-s= witching-example discusses different aspects of switching.

 

If Jonathan or= anybody else can help explain more about the Ticket #26 issues, and how we= should address it in the framework, I’ll be happy to add it!

 

Thank= s,
Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC999CCRPMBOXPRD07pol_-- From espeberg@cisco.com Fri Jul 12 04:40:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2596711E80F9 for ; Fri, 12 Jul 2013 04:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Bf5kLdT7Hkf for ; Fri, 12 Jul 2013 04:40:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1011E80F8 for ; Fri, 12 Jul 2013 04:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4633; q=dns/txt; s=iport; t=1373629225; x=1374838825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QXbc6Od2rTLluwHBdmiihVjgHiReaOW+psLJ8WR2ewc=; b=V60dW9edN05tK24IS8w3GuwYelFjWFWrG3Iw49ePIsK5nxXi6kV19H3f tTbrAs0SYgsQAYTwZuQs5jw/YLjnUcEzIUd0rcgaW/a+D7YF75xHwi+vb Q3mpRyjnj800VRtC/yg5hQuDmJ8X5+E1SSj54MJ6oPKDW57ZvPfrLcJ16 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKXq31GtJV2d/2dsb2JhbABQCoMGNE/BUYEJFnSCIwEBAQMBAQEBNzQJAgUHBAIBCBEDAQEBAQoUCQcnCxQIAQgCBAENBQgBiAAGDLcNjiWBCwYrBwIEgwVsA5QFhQCQJIFZgTmCKA X-IronPort-AV: E=Sophos;i="4.89,652,1367971200"; d="scan'208";a="234016677" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 12 Jul 2013 11:40:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6CBeMiu006904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 11:40:22 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.134]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 06:40:22 -0500 From: "Espen Berger (espeberg)" To: Jonathan Lennox , Christian Groves Thread-Topic: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt Thread-Index: AQHOfNL9DsLSIehVSUWwEBhmB0GRcJlg6fBg Date: Fri, 12 Jul 2013 11:40:22 +0000 Message-ID: References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:40:30 -0000 I like the application token draft and find it very useful that its indepen= dent of CLUE to be reusable in other use cases as well. =20 I think CLUE capture ID should build on the application-id . We should avoi= d having both application-id and capture-id in the signaling, that sounds l= ike doubling of information. The app-id could mean a concrete capture with = a given set of encoding values, which we have referred to as capture encodi= ngs. =20 Regards=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jon= athan Lennox Sent: 9. juli 2013 20:34 To: Christian Groves Cc: clue@ietf.org Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mm= usic-application-token-00.txt On Jul 8, 2013, at 11:37 PM, Christian Groves wrote: > Hello Roni, >=20 > How would you envisage using this for CLUE? Would a "CLUE capture ID"=20 > attribute need to be defined? > i.e. a=3DappID:2 CLUECapID:1 >=20 > or something else? >=20 > Regards, Christian Not to speak for Roni, but as his co-author, my vague idea is that we'd bin= d appIDs to m-lines (either one per m-line, or multiple per m-line, dependi= ng on whether MMUSIC goes with Plan A or Plan B); then the CLUE channel wou= ld associate appIDs to either encodings or capture encodings (depending on = decisions in this group). > On 29/06/2013 2:31 AM, Mary Barnes wrote: >> ---------- Forwarded message ---------- >> From: Roni Even >> Date: Fri, Jun 28, 2013 at 10:54 AM >> Subject: [MMUSIC] FW: New Version Notification for=20 >> draft-even-mmusic-application-token-00.txt >> To: "mmusic@ietf.org" >>=20 >>=20 >> Hi, >> We have submitted this document that defines a mechanism to provide=20 >> the mapping between the >> SSRCs of RTP streams and the application semantics by defining=20 >> extensions to RTP and RTCP messages. >>=20 >> It defines a new SDP attribute, RTCP SDES message and RTP header=20 >> extension for this puropose. The document explains how it can be used=20 >> with the different multiplexing proposal (Plan A, Plan B and no plan). >>=20 >> It can be used also in CLUE to map SSRCs to Clue media capture. >>=20 >> Please review and send comments >> Thanks >> Roni Even >>=20 >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, June 28, 2013 6:27 PM >> To: Jonathan Lennox; Qin Wu; Roni Even >> Subject: New Version Notification for=20 >> draft-even-mmusic-application-token-00.txt >>=20 >> A new version of I-D, draft-even-mmusic-application-token-00.txt >> has been successfully submitted by Roni Even and posted to the IETF=20 >> repository. >>=20 >> Filename: draft-even-mmusic-application-token >> Revision: 00 >> Title: The Session Description Protocol (SDP) Application >> Token Attribute >> Creation date: 2013-06-28 >> Group: Individual Submission >> Number of pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-tok >> en-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >> Htmlized: >> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>=20 >>=20 >> Abstract: >> The RTP fixed header includes the payload type number and the SSRC >> values of the RTP stream. RTP defines how you de-multiplex streams >> within an RTP session, but in some use cases applications need >> further identifiers in order to identify the application semantics >> associated with particular streams within the session. >>=20 >> This document defines a mechanism to provide the mapping between the >> SSRCs of RTP streams and the application semantics by defining >> extensions to RTP and RTCP messages. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> 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 -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From rohanse2@cisco.com Fri Jul 12 10:21:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B021F9E88 for ; Fri, 12 Jul 2013 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS9T9jhVW9sZ for ; Fri, 12 Jul 2013 10:21:35 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id DB09D21F9A72 for ; Fri, 12 Jul 2013 10:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1957; q=dns/txt; s=iport; t=1373649695; x=1374859295; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4+asypGMI65QRouXC6gG9IfRM+EpFWknLhOc+T/bfyk=; b=YPJsieWELQyJEOTJu/SjF/pFXU13t6STPzrK2sZVsouMOPWg0GmLV2AH EJjQ+Tx0cLWFARxHKqFXf5BtSc+GAH3ERJvoPPQEglKpiwvuTunLhVZu7 UnB3HRf0jZJ/Wm9i1JRZoMRVt1JWTg+9gzPuau9Ick3hlCnGet0eRnMwB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQIAIc44FGQ/khL/2dsb2JhbABagwY0riWTe4EMFnSCIwEBAQQBAQE1NgoRCxgJFg8JAwIBAgEVMBMGAgEBBRKHdAy3co9oFoNhA5dchiOLKoMTOw X-IronPort-AV: E=Sophos;i="4.89,654,1367971200"; d="scan'208";a="15185894" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 12 Jul 2013 17:21:33 +0000 Received: from [10.47.196.239] ([10.47.196.239]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6CHLVYX023738 for ; Fri, 12 Jul 2013 17:21:32 GMT Message-ID: <51E03B33.3060200@cisco.com> Date: Fri, 12 Jul 2013 18:21:55 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 17:21:43 -0000 I've been adding to Paul's signalling document sections, and will make sure I get an XML version of it to him to look over before the start of Monday (will finish it over the weekend since I wasn't able to get it all done today). Rob On 11/07/2013 20:46, Mary Barnes wrote: > Please note the final deadline for drafts for IETF-87. Note that > there is only a single draft deadline for this meeting so -00 drafts > can be submitted up to that point. > > The chairs are discussing how to arrange the agenda and the obvious items are: > - Use cases if there are any issues from WGLC requiring discussion > - Framework. Ideally, we can get closure on open issues and agree > those that can be resolved by the solution. Note, we won't progress > this document until the solution is done so we can always iterate back > in cases where we need additional text or changes in the framework. > - Roles: draft-groves-clue-role-clarifications > - Data model. We may not need any time for this. > - Signaling: > -- draft-kyzivat-clue-signaling > -- draft-presta-clue-protocol > > If folks have additional items (drafts in particular) that they > believe require discussion please let us know. Also, if you have > proposals for any of the open issues in the signaling document, we > would love to discuss those, in particular it would be great to have > updates on the items for which folks volunteered at the interim: > http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 > > Note that I also have the action item to post the open topics and > issues for which we may have consensus to the list before the meeting. > > We will produce a more detailed agenda (with time allocations) no > later than next Wednesday. > > Thanks, > Mary and Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From rohanse2@cisco.com Fri Jul 12 10:22:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872B721F9A72 for ; Fri, 12 Jul 2013 10:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7diMBECjYHU for ; Fri, 12 Jul 2013 10:22:41 -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 9063C21E80AC for ; Fri, 12 Jul 2013 10:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2127; q=dns/txt; s=iport; t=1373649757; x=1374859357; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=euhiTz9YCqEeSL7iuFMq9swO90e/eNiD7r2drdnk3HE=; b=gH3SRFsGQHir4YBTAp2f64KzYM3Hx7LX5b6c+kYOJQaQxMUmAUmppUTH pP2MZPeT8/0DvbCLH4/8GwUdJ3ERBCrMI/PcM26+/+c7WXAQ06h4lDj6b rfm1dXWtk8hV5fEs5otJxvXGXM1bLivkeLar8b/aq9NydrC8AVdlwqXYu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQIAJA64FGQ/khL/2dsb2JhbABagwY0riWTe4EMFnSCIwEBAQQBAQE1NgoRCxgJFg8JAwIBAgEVMBMGAgEBBRKHdAy3ao9oFoNhA5dchiOLKoMTOw X-IronPort-AV: E=Sophos;i="4.89,654,1367971200"; d="scan'208";a="156593731" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2013 17:22:36 +0000 Received: from [10.47.196.239] ([10.47.196.239]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6CHMYgS024186 for ; Fri, 12 Jul 2013 17:22:34 GMT Message-ID: <51E03B72.8010309@cisco.com> Date: Fri, 12 Jul 2013 18:22:58 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51E03B33.3060200@cisco.com> In-Reply-To: <51E03B33.3060200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 17:22:45 -0000 Forgot to specify, I've been filling out sections 4 and 5. Rob On 12/07/2013 18:21, Robert Hansen wrote: > I've been adding to Paul's signalling document sections, and will make > sure I get an XML version of it to him to look over before the start of > Monday (will finish it over the weekend since I wasn't able to get it > all done today). > > Rob > > On 11/07/2013 20:46, Mary Barnes wrote: >> Please note the final deadline for drafts for IETF-87. Note that >> there is only a single draft deadline for this meeting so -00 drafts >> can be submitted up to that point. >> >> The chairs are discussing how to arrange the agenda and the obvious >> items are: >> - Use cases if there are any issues from WGLC requiring discussion >> - Framework. Ideally, we can get closure on open issues and agree >> those that can be resolved by the solution. Note, we won't progress >> this document until the solution is done so we can always iterate back >> in cases where we need additional text or changes in the framework. >> - Roles: draft-groves-clue-role-clarifications >> - Data model. We may not need any time for this. >> - Signaling: >> -- draft-kyzivat-clue-signaling >> -- draft-presta-clue-protocol >> >> If folks have additional items (drafts in particular) that they >> believe require discussion please let us know. Also, if you have >> proposals for any of the open issues in the signaling document, we >> would love to discuss those, in particular it would be great to have >> updates on the items for which folks volunteered at the interim: >> http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 >> >> >> Note that I also have the action item to post the open topics and >> issues for which we may have consensus to the list before the meeting. >> >> We will produce a more detailed agenda (with time allocations) no >> later than next Wednesday. >> >> Thanks, >> Mary and Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From pkyzivat@alum.mit.edu Fri Jul 12 11:22:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F6611E816D for ; Fri, 12 Jul 2013 11:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-hh-DUfyLZz for ; Fri, 12 Jul 2013 11:22:44 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id CE58911E815F for ; Fri, 12 Jul 2013 11:22:39 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id zPpH1l0021uE5Es59WNf9j; Fri, 12 Jul 2013 18:22:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id zWNf1l0083ZTu2S3cWNf2W; Fri, 12 Jul 2013 18:22:39 +0000 Message-ID: <51E0496E.502@alum.mit.edu> Date: Fri, 12 Jul 2013 14:22:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51E03B33.3060200@cisco.com> <51E03B72.8010309@cisco.com> In-Reply-To: <51E03B72.8010309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373653359; bh=qdAfj2WlG6OaDaosYRFjHcrEs64+bWIPd3jzCsGFoQI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F/Z0pIVXmHKuQnTHRCAgjDn6pC9xM3/shUSWtmND96gn70VMvq9sAYiNMiwsg4xjM vfSeqMU9rsoxb+UT4N5f3cT+IozQivzb8un02aiEy8Of8dOcwW5qeWV4TXeb2eJrEQ ZEFnIcEg5JExf/Z3zQVcTvjdaPe2cS/WZV85cM8UWBn0VN4pB/IKyo5Dpy8IkAQpLe b3Yjpj/oi7PadtZWW7YRWlvgZJuhm/nE7bjjZ/CaTM+5OqcX+1nr4e+c271nFyx1hN 4YmFKZV0tw9JZwr65ov81n78Q09yXiZgLublW5jYbI6DhFb1nbjZGJjnQzqzM4QLiI Px5TdFvyXC1cQ== Subject: Re: [clue] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 18:22:49 -0000 On 7/12/13 1:22 PM, Robert Hansen wrote: > Forgot to specify, I've been filling out sections 4 and 5. The text there was yours to start with. Unless you do something crazy, you might as well just submit the new version. This is all "work in progress" stuff at this point. Thanks, Paul > Rob > > On 12/07/2013 18:21, Robert Hansen wrote: >> I've been adding to Paul's signalling document sections, and will make >> sure I get an XML version of it to him to look over before the start of >> Monday (will finish it over the weekend since I wasn't able to get it >> all done today). >> >> Rob >> >> On 11/07/2013 20:46, Mary Barnes wrote: >>> Please note the final deadline for drafts for IETF-87. Note that >>> there is only a single draft deadline for this meeting so -00 drafts >>> can be submitted up to that point. >>> >>> The chairs are discussing how to arrange the agenda and the obvious >>> items are: >>> - Use cases if there are any issues from WGLC requiring discussion >>> - Framework. Ideally, we can get closure on open issues and agree >>> those that can be resolved by the solution. Note, we won't progress >>> this document until the solution is done so we can always iterate back >>> in cases where we need additional text or changes in the framework. >>> - Roles: draft-groves-clue-role-clarifications >>> - Data model. We may not need any time for this. >>> - Signaling: >>> -- draft-kyzivat-clue-signaling >>> -- draft-presta-clue-protocol >>> >>> If folks have additional items (drafts in particular) that they >>> believe require discussion please let us know. Also, if you have >>> proposals for any of the open issues in the signaling document, we >>> would love to discuss those, in particular it would be great to have >>> updates on the items for which folks volunteered at the interim: >>> http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-interim-2013-clue-2 >>> >>> >>> >>> Note that I also have the action item to post the open topics and >>> issues for which we may have consensus to the list before the meeting. >>> >>> We will produce a more detailed agenda (with time allocations) no >>> later than next Wednesday. >>> >>> Thanks, >>> Mary and 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 Fri Jul 12 11:35:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B4711E815F for ; Fri, 12 Jul 2013 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6tJ6f+tgOIA for ; Fri, 12 Jul 2013 11:35:04 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8216E21F9E2C for ; Fri, 12 Jul 2013 11:34:57 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 12 Jul 2013 11:34:57 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 12 Jul 2013 11:34:55 -0700 Thread-Topic: comments on data model Thread-Index: Ac5/LUtDHSTheKY3QyK5mUJj9Kv0nA== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9D52@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9D52CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] comments on data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 18:35:09 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9D52CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a few minor comments on the data model draft: 1 - section 10.2 "each media capture must be associated with one and only c= apture scene" should be "each media capture must be associated with one and= only <> capture scene" 2 - "definible" should be "definable" in several places 3 - should the simultaneousSetType include a mediaType element, similar to = how a sceneEntryType includes a mediaType? I think so, to make it clear th= at a simultaneous set includes media captures of only a particular media ty= pe. I will have a separate list of comments about consistency of data model and= framework. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9D52CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a few minor= comments on the data model draft:

=  

1 – section 10.2 “each med= ia capture must be associated with one and only capture scene” should= be “each media capture must be associated with one and only <<= one>> capture scene”

&n= bsp;

2 – “definible" should = be “definable” in several places

 

3 – should the simulta= neousSetType include a mediaType element, similar to how a sceneEntryType i= ncludes a mediaType?  I think so, to make it clear that a simultaneous= set includes media captures of only a particular media type.

 

I will have= a separate list of comments about consistency of data model and framework.=

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9D52CRPMBOXPRD07pol_-- From SPennock@qnx.com Fri Jul 12 11:55:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E1D11E80D9 for ; Fri, 12 Jul 2013 11:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-AIfC2T+-V3 for ; Fri, 12 Jul 2013 11:54:57 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 225CE11E8168 for ; Fri, 12 Jul 2013 11:54:55 -0700 (PDT) Received: from mx10.qnx.com ([209.226.137.110]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUeBQ/keA//rEnqJsCLgiOKLO54TN8u5w@postini.com; Fri, 12 Jul 2013 11:54:56 PDT Received: by mx10.qnx.com (Postfix, from userid 500) id B38BB211A3; Fri, 12 Jul 2013 14:54:53 -0400 (EDT) Received: from exhts.ott.qnx.com (exch2 [10.222.2.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx10.qnx.com (Postfix) with ESMTPS id 4F710211A2; Fri, 12 Jul 2013 14:54:53 -0400 (EDT) Received: from EXMBX4.ott.qnx.com ([fe80::bd7a:5d16:2362:5d20]) by EXCH2.ott.qnx.com ([fe80::f994:121e:2768:99e8%17]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 14:54:06 -0400 From: Scott Pennock To: Robert Hansen , "clue@ietf.org" Thread-Topic: [clue] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC Thread-Index: AQHOfyRT63tLyAV3w02BShjAr1nKnJlhja0AgAAZdAA= Date: Fri, 12 Jul 2013 18:54:05 +0000 Message-ID: <20130712185404.8630423.79379.4519@qnx.com> References: <51E03B33.3060200@cisco.com> <51E03B72.8010309@cisco.com> In-Reply-To: <51E03B72.8010309@cisco.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201307121854048630423793794519qnxcom_" MIME-Version: 1.0 Subject: Re: [clue] Reminder: Final draft deadline is Monday, July 15th at 24:00 UTC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 18:55:02 -0000 --_000_201307121854048630423793794519qnxcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bbgs Sent from my BlackBerry 10 smartphone. From: Robert Hansen Sent: Friday, July 12, 2013 1:22 he. DPM To: clue@ietf.org Subject: Re: [clue] Reminder: Final draft deadline is Monday, July 15th at = 24:00 UTC Forgot to specify, I've been filling out sections 4 and 5.$j Rob On 12/07/2013 18:21, Robert Hansen wrote: > I've been adding to Paul's signalling document sections, and will make > sure I get an XML version of it to him to look over before the start of > Monday (will finish it over the weekend since I wasn't able to get it > all done today). > > Rob > c > On 11/07/2013 20:46, Mary Barnes wrote: >> Please note the final deadline for drafts for IETF-87. Note that >> there is only a single draft deadline for this meeting so -00 drafts >> can be submitted up to that point. >> >> The chairs are discussing how to arrange the agenda and the obvious >> items are: >> - Use cases if there are any issues from WGLC requiring discussion >> - Framework. Ideally, we can get closure on open issues and agree >> those that can be resolved by the solution. Note, we won't progress >> this document until the solution is done so we can always iterate back >> in cases where we need additional text or changes in the framework. >> - Roles: draft-groves-clue-role-clarifications >> - Data model. We may not need any time for this. >> - Signaling: >> -- draft-kyzivat-clue-signaling >> -- draft-presta-clue-protocol >> >> If folks have additional items (drafts in particular) that they >> believe require discussion please let us know. Also, if you have >> proposals for any of the open issues in the signaling document, we >> would love to discuss those, in particular it would be great to have >> updates on the items for which folks volunteered at the interim: >> http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/minutes-= interim-2013-clue-2 >> >> >> Note that I also have the action item to post the open topics and >> issues for which we may have consensus to the list before the meeting. >> >> We will produce a more detailed agenda (with time allocations) no >> later than next Wednesday. >> >> Thanks, >> Mary and 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 --_000_201307121854048630423793794519qnxcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1F76399B7C1962419E1D388766F6CDD1@qnx.com> Content-Transfer-Encoding: quoted-printable
Bbgs 

Sent from my BlackBerry 10 smartphone.

From: Robert Hansen 
Sent: Friday, July 12, 2013 1:22 he. DPM
To: clue@ietf.org 
Subject: Re: [clue] Reminder: Final draft deadline is Monday, J= uly 15th at 24:00 UTC

Forgot to specify, I've been fillin= g out sections 4 and 5.$j

Rob

On 12/07/2013 18:21, Robert Hansen wrote:
> I've been adding to Paul's signalling document sections, and will make=
> sure I get an XML version of it to him to look over before the start o= f
> Monday (will finish it over the weekend since I wasn't able to get it<= br> > all done today).
>
> Rob
> c
> On 11/07/2013 20:46, Mary Barnes wrote:
>> Please note the final deadline for drafts for IETF-87. Note that >> there is only a single draft deadline for this meeting so -00 draf= ts
>> can be submitted up to that point.
>>
>> The chairs are discussing how to arrange the agenda and the obviou= s
>> items are:
>> - Use cases if there are any issues from WGLC requiring discussion=
>> - Framework. Ideally, we can get closure on open issues and agree<= br> >> those that can be resolved by the solution. Note, we won't progres= s
>> this document until the solution is done so we can always iterate = back
>> in cases where we need additional text or changes in the framework= .
>> - Roles: draft-groves-clue-role-clarifications
>> - Data model. We may not need any time for this.
>> - Signaling:
>> -- draft-kyzivat-clue-signaling
>> -- draft-presta-clue-protocol
>>
>> If folks have additional items (drafts in particular) that they >> believe require discussion please let us know. Also, if you have >> proposals for any of the open issues in the signaling document, we=
>> would love to discuss those, in particular it would be great to ha= ve
>> updates on the items for which folks volunteered at the interim: >> http://www.ietf.org/proceedings/interim/2013/06/25/clue/minutes/mi= nutes-interim-2013-clue-2
>>
>>
>> Note that I also have the action item to post the open topics and<= br> >> issues for which we may have consensus to the list before the meet= ing.
>>
>> We will produce a more detailed agenda (with time allocations) no<= br> >> later than next Wednesday.
>>
>> Thanks,
>> Mary and 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
--_000_201307121854048630423793794519qnxcom_-- From Mark.Duckworth@polycom.com Fri Jul 12 12:55:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED2921F9F6A for ; Fri, 12 Jul 2013 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnoNocylM+U4 for ; Fri, 12 Jul 2013 12:55:44 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3E721F9F49 for ; Fri, 12 Jul 2013 12:55:39 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 12 Jul 2013 12:55:39 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 12 Jul 2013 12:55:37 -0700 Thread-Topic: Ticket #35 consistency of data model and framework Thread-Index: Ac5/Ls21C7yMS/XQScKAkpB+Aoa0jQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9DD0CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 19:55:48 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9DD0CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the list of things I found to be inconsistent. 1 - data model section 3 "simultaneous capture sets" should be "simultaneou= s <> sets" 2 - data model section 10 a media capture can include many spatialInformati= on elements. There was some discussion of this back in November. http://w= ww.ietf.org/mail-archive/web/clue/current/msg02113.html. I propose we remo= ve the maxOccurs=3D"unbounded" and have just a single spatialInformation, w= hich is consistent with the framework. 3 - data model section 10.6. The framework includes a description attribut= e only for a Capture Scene, while the data model includes it also for captu= re scene entries and media captures. I don't recall why there is the diffe= rence. Did the group decide we should add a description attribute to captu= re scene entries and media captures? 4 - data model section 10.9 should replace content element with the present= ation element, as described in framework section 6.1.1. 5 - both data model and framework should add new information about role att= ributes/elements after discussing draft-groves-clue-role-clarifications. 6 - data model section 10.x add a "view" element as described in framework = section 6.1.1 7 - data model section 10.11 rename the "dynamic" element to something like= "captureMobility" and update description as described in the framework for= the "Mobility of Capture" attribute. 8 - data model section 11.2 has a micPattern element, which is not in the f= ramework. Did the group decide to add this as an attribute of an audio cap= ture? I don't remember such a decision. 9 - data model section 12.1 has a nativeAspectRatio element, which is not i= n the framework. Did the group decide to add this as an attribute of a vid= eo capture? I don't remember such a decision. 10 - data model section 14.1 the sceneSpace element should be removed. We = already decided to remove the "area of scene" attribute in the framework. 11 - data model section 22 should captureEncodingType also include addition= al elements to specify the specific values of the parameters bandwidth, wid= th, height, etc? Framework section 9 says "Each Capture Encoding refers to= one Media Capture, one Individual Encoding, and includes the encoding para= meter values." Refer to conversation http://www.ietf.org/mail-archive/web/= clue/current/msg02526.html Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9DD0CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the list= of things I found to be inconsistent.

<= o:p> 

1 – data model section 3 = 220;simultaneous capture sets” should be “simultaneous <<= transmission>> sets”

&n= bsp;

2 – data model section 10 a media = capture can include many spatialInformation elements.  There was some = discussion of this back in November.  http://www.ietf.org/mail-archiv= e/web/clue/current/msg02113.html.  I propose we remove the maxOccu= rs=3D”unbounded” and have just a single spatialInformation, whi= ch is consistent with the framework.

 

3 – data model section 10.6.&n= bsp; The framework includes a description attribute only for a Capture Scen= e, while the data model includes it also for capture scene entries and medi= a captures.  I don’t recall why there is the difference.  D= id the group decide we should add a description attribute to capture scene = entries and media captures?

 <= /o:p>

4 – data model section 10.9 should repl= ace content element with the presentation element, as described in framewor= k section 6.1.1.

 

5 – both data model and framework should add new i= nformation about role attributes/elements after discussing draft-groves-clu= e-role-clarifications.

 =

6 – data model section 10.x add a “vie= w” element as described in framework section 6.1.1

 

7 – data m= odel section 10.11 rename the “dynamic” element to something li= ke “captureMobility” and update description as described in the= framework for the “Mobility of Capture” attribute.<= /p>

 

8 –= data model section 11.2 has a micPattern element, which is not in the fram= ework.  Did the group decide to add this as an attribute of an audio c= apture?  I don’t remember such a decision.

 

9 - data model sect= ion 12.1 has a nativeAspectRatio element, which is not in the framework.&nb= sp; Did the group decide to add this as an attribute of a video capture?&nb= sp; I don’t remember such a decision.

 

10 – data model section= 14.1 the sceneSpace element should be removed.  We already decided to= remove the “area of scene” attribute in the framework.

 

11 &#= 8211; data model section 22 should captureEncodingType also include additio= nal elements to specify the specific values of the parameters bandwidth, wi= dth, height, etc?  Framework section 9 says “Each Capture Encodi= ng refers to one Media Capture, one Individual Encoding, and includes the e= ncoding parameter values.”  Refer to conversation http://www.ie= tf.org/mail-archive/web/clue/current/msg02526.html

 

Regards,

Mark

&nbs= p;

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9DD0CRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Fri Jul 12 13:44:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8345A21F9E98 for ; Fri, 12 Jul 2013 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mtWJYiWvGNX for ; Fri, 12 Jul 2013 13:44:11 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7226321F9EA7 for ; Fri, 12 Jul 2013 13:44:11 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 12 Jul 2013 13:44:10 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 12 Jul 2013 13:44:08 -0700 Thread-Topic: data model priority element Thread-Index: Ac5/QFKcu0q6TIeqS/OjyHvKNHVhSw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E1DCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 20:44:16 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E1DCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable About section 10.7 in the data model. I think this needs more information to make it useful. Should there be an allowed range? Maybe make it unsigned, with a max value= ? Need to specify if a larger number means higher or lower priority. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E1DCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

About section 10= .7 <priority> in the data model.

I= think this needs more information to make it useful.

Should there be an allowed range?  Maybe make it unsigne= d, with a max value?

Need to specify if = a larger number means higher or lower priority.

 

Mark

= = --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E1DCRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Fri Jul 12 13:54:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE8F21F9F36 for ; Fri, 12 Jul 2013 13:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAwYCDhQDkhE for ; Fri, 12 Jul 2013 13:54:47 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8A121F9F54 for ; Fri, 12 Jul 2013 13:54:46 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 12 Jul 2013 13:54:37 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 12 Jul 2013 13:54:35 -0700 Thread-Topic: data model for specifying attribute value in Configure message Thread-Index: Ac5/QQneKcEia88sSnyxBmsUDOKojw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E2ACRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 20:54:51 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E2ACRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the data model is intended to support building a Configure message = by using a list of captureEncoding elements. If so, there also needs to be= a way to add parameter values of items where the Provider has offered a ch= oice. >From the framework: For each Media Capture in the message, the Consumer may also specify the value of any attributes for which the Provider has offered a choice, for example the value for the Scene-switch-policy attribute. Currently, I think Scene-switch-policy is the only attribute in this catego= ry. Does it make sense to add an element to do this into the captureEncodingTyp= e? This is similar to item 11 in my other list of comments http://www.ietf= .org/mail-archive/web/clue/current/msg02666.html. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E2ACRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the data= model is intended to support building a Configure message by using a list = of captureEncoding elements.  If so, there also needs to be a way to a= dd parameter values of items where the Provider has offered a choice.<= /o:p>

 

Fro= m the framework:

  For each Media C= apture in the message, the Consumer may also

  specify the value of any attributes for which the Provider has<= o:p>

  offered a choice, for example the= value for the Scene-switch-policy

 = ; attribute.

 

Currently, I think Scene-switch-policy is the only attribute= in this category.

 

=

Does it make sense to add an element to do this into t= he captureEncodingType?  This is similar to item 11 in my other list o= f comments http://www.ietf.org/mail-archive/web/clue/current/msg02666.html= .

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601BC9E2ACRPMBOXPRD07pol_-- From pkyzivat@alum.mit.edu Fri Jul 12 14:00:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0721F9F86 for ; Fri, 12 Jul 2013 14:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-uuiG92RmEQ for ; Fri, 12 Jul 2013 14:00:01 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2F621F9F87 for ; Fri, 12 Jul 2013 13:59:59 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id zWx01l0080EZKEL59Yzy5v; Fri, 12 Jul 2013 20:59:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id zYzy1l00i3ZTu2S3MYzyEl; Fri, 12 Jul 2013 20:59:58 +0000 Message-ID: <51E06E4D.1010801@alum.mit.edu> Date: Fri, 12 Jul 2013 16:59:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373662798; bh=QLxq4uTcJUzTMryhlWa8xPD4lOHPI48mVh8Bdnf73v8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZGoSqqDLBq9qkyk8Lbffh36j0W0qyPHxEKoGcoVMntg0VJax43kcmmYhiVBB4GC2q K303mxW/tWq22HS8acPOZUddCxPymcDZyYps38SnEqqPUr9ZL99fLTASYr4/VUfe43 rZ/7erR/fS4sGqDf81zWNeZW5T3kqjRUaM0XBxH2lV8UW4Qty2927K+51upSNriUd7 9tLuq/11bZ3UgLUQ4Ma301P/EFVX4zE2LlWO9n0TaidDXtdG7+lemGbWqw22Sz4sY1 QD7w4BNYD3q34Z9IV3BPPgkP5BRU79bSU1UaOv+fD1NrJSb3gztOGSo5AmTfLewGFf /UDhsHrBlyYCg== Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:00:06 -0000 On 7/12/13 7:40 AM, Espen Berger (espeberg) wrote: > I like the application token draft and find it very useful that its independent of CLUE to be reusable in other use cases as well. > > I think CLUE capture ID should build on the application-id . We should avoid having both application-id and capture-id in the signaling, that sounds like doubling of information. The app-id could mean a concrete capture with a given set of encoding values, which we have referred to as capture encodings. I have to keep saying this: This needs to be the id of a capture-encoding, not of a capture, because there can be multiple encodings of a capture. It can potentially be just an encoding ID, because an encoding can only be mapped to one capture at a time, so that given an encoding id you can look up the corresponding capture id (based on currently active configuration.) Thanks, Paul > Regards > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox > Sent: 9. juli 2013 20:34 > To: Christian Groves > Cc: clue@ietf.org > Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt > > > On Jul 8, 2013, at 11:37 PM, Christian Groves wrote: > >> Hello Roni, >> >> How would you envisage using this for CLUE? Would a "CLUE capture ID" >> attribute need to be defined? >> i.e. a=appID:2 CLUECapID:1 >> >> or something else? >> >> Regards, Christian > > Not to speak for Roni, but as his co-author, my vague idea is that we'd bind appIDs to m-lines (either one per m-line, or multiple per m-line, depending on whether MMUSIC goes with Plan A or Plan B); then the CLUE channel would associate appIDs to either encodings or capture encodings (depending on decisions in this group). > > >> On 29/06/2013 2:31 AM, Mary Barnes wrote: >>> ---------- Forwarded message ---------- >>> From: Roni Even >>> Date: Fri, Jun 28, 2013 at 10:54 AM >>> Subject: [MMUSIC] FW: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> To: "mmusic@ietf.org" >>> >>> >>> Hi, >>> We have submitted this document that defines a mechanism to provide >>> the mapping between the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> It defines a new SDP attribute, RTCP SDES message and RTP header >>> extension for this puropose. The document explains how it can be used >>> with the different multiplexing proposal (Plan A, Plan B and no plan). >>> >>> It can be used also in CLUE to map SSRCs to Clue media capture. >>> >>> Please review and send comments >>> Thanks >>> Roni Even >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Friday, June 28, 2013 6:27 PM >>> To: Jonathan Lennox; Qin Wu; Roni Even >>> Subject: New Version Notification for >>> draft-even-mmusic-application-token-00.txt >>> >>> A new version of I-D, draft-even-mmusic-application-token-00.txt >>> has been successfully submitted by Roni Even and posted to the IETF >>> repository. >>> >>> Filename: draft-even-mmusic-application-token >>> Revision: 00 >>> Title: The Session Description Protocol (SDP) Application >>> Token Attribute >>> Creation date: 2013-06-28 >>> Group: Individual Submission >>> Number of pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-tok >>> en-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >>> Htmlized: >>> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>> >>> >>> Abstract: >>> The RTP fixed header includes the payload type number and the SSRC >>> values of the RTP stream. RTP defines how you de-multiplex streams >>> within an RTP session, but in some use cases applications need >>> further identifiers in order to identify the application semantics >>> associated with particular streams within the session. >>> >>> This document defines a mechanism to provide the mapping between the >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Jul 12 14:08:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74F921F9EB8 for ; Fri, 12 Jul 2013 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzyZhX8uB7Wa for ; Fri, 12 Jul 2013 14:08:49 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D53B021F9D9C for ; Fri, 12 Jul 2013 14:08:48 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id zZ3j1l00A0Fqzac51Z8n02; Fri, 12 Jul 2013 21:08:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id zZ8n1l00v3ZTu2S3UZ8nAA; Fri, 12 Jul 2013 21:08:47 +0000 Message-ID: <51E0705E.4040305@alum.mit.edu> Date: Fri, 12 Jul 2013 17:08:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373663327; bh=WpWX8G8wYmkWrhK/0km1QkmL4BaJUBh37k8yiSt6+Z8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TD43Zd7CiUye8WjM/IhpWFB1RrSvvQ3bLqkXhB69iqEnbuoAP4uXbjm7yUqSArqf+ oEGWLPQ9NRap1D7B3H3kPcF6Eg1lERYnfbg+fA11uvToLhvZ1Vj0RmeFfn/cbWIqYM XPGBOrDdCzplXUY/L7oJMBLKqUD2Gavvos7MzCXpq32MUQB4WQjkoC140Fx4exbapJ Hz4lD3hZIp3ois/w5nZGeS+DudfH+Xy6BU+dYZC9PJxdttTwFHck5AvGnZfSB6/n+2 1U7SWTRWpQB3BZhf/cz3KvtyYJUEG6K97WEgmEaY1S34tkUfgKGdiD7EtADq+xvBtL rPKDqIMh7EMQQ== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 21:08:53 -0000 I've brought this up before, but I'll try again: As currently conceived, this mechanism has problems. Specifically, these attributes apply to captures, not capture-encodings. Suppose I configure two different encodings of the same capture, and supply different attributes to each. (E.g. one with site switching and one with scene switching.) At that point, what is the meaning of the capture? I have two encodings which may be showing entirely different content. IMO this is nonsense. So I think there is a problem with attributes that can be specified in the configure. There are a variety of possible solutions. The simplest is simply to disallow them. Thanks, Paul On 7/12/13 4:54 PM, Duckworth, Mark wrote: > I think the data model is intended to support building a Configure > message by using a list of captureEncoding elements. If so, there also > needs to be a way to add parameter values of items where the Provider > has offered a choice. > > From the framework: > > For each Media Capture in the message, the Consumer may also > > specify the value of any attributes for which the Provider has > > offered a choice, for example the value for the Scene-switch-policy > > attribute. > > Currently, I think Scene-switch-policy is the only attribute in this > category. > > Does it make sense to add an element to do this into the > captureEncodingType? This is similar to item 11 in my other list of > comments http://www.ietf.org/mail-archive/web/clue/current/msg02666.html. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Jul 12 14:17:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B7421F9E94 for ; Fri, 12 Jul 2013 14:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaMnEjy3GY7P for ; Fri, 12 Jul 2013 14:17:15 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0A21F9E6C for ; Fri, 12 Jul 2013 14:17:14 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id zU6v1l00A1ap0As53ZHECG; Fri, 12 Jul 2013 21:17:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id zZHE1l0083ZTu2S3iZHE2e; Fri, 12 Jul 2013 21:17:14 +0000 Message-ID: <51E07259.9000109@alum.mit.edu> Date: Fri, 12 Jul 2013 17:17:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373663834; bh=s2TlIsxJgX3kaolwbHaP4IfQzjD8uI2qI57s4gKkbAw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PH3vFiSqaYhAYXKD8mAvXhaDalyW7RWPaP8+AOJbVCIfwahz18XCEVybjlIDCWLoY PgFip7biCNlOC89XpzfagPcDg7vsjNQHwrjyTEfgRGdYyB+wRWw/SK1WNRoaJZXqL3 e7lRoGdQCJ05yUscvLQPA4Uj1tHP4JYgEmnosu43oPb3CWODhK14LkyEmgogL9c+m6 3Zn0L28UEOaw9fGq+xKI17+eKCq+0sSgYNsvJnNRO1Dq/LfJf0MhM3A++EaxGehfKO hP4hjRDfVNctOwxwsr7XoaPqKo9tH0Su8s46Mm1WH+qZvw0/WFZFfG+mmzz2n0jnbZ VlwtBiS7V1Rwg== Subject: Re: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 21:17:21 -0000 On 7/12/13 4:44 PM, Duckworth, Mark wrote: > About section 10.7 in the data model. > > I think this needs more information to make it useful. > > Should there be an allowed range? Maybe make it unsigned, with a max value? We need enough so that a data type can be selected to hold it. But the max value can be large. Signed or unsigned, 16 or 32 bits, would be fine with me. Its hardly worth specifying anything smaller. > Need to specify if a larger number means higher or lower priority. I agree we need to specify the sense of the ordering. I vote for bigger is higher priority. Thanks, Paul From pkyzivat@alum.mit.edu Fri Jul 12 14:22:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273B21F9F6F for ; Fri, 12 Jul 2013 14:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.183 X-Spam-Level: X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNUhuulu6-US for ; Fri, 12 Jul 2013 14:22:52 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 1924421F9A71 for ; Fri, 12 Jul 2013 14:22:43 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id zR9t1l0021ei1Bg5CZNjbE; Fri, 12 Jul 2013 21:22:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id zZNj1l00K3ZTu2S3kZNjEZ; Fri, 12 Jul 2013 21:22:43 +0000 Message-ID: <51E073A2.10500@alum.mit.edu> Date: Fri, 12 Jul 2013 17:22:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373664163; bh=Ne6DuClkP+SDuULpFbjo12qEavmGICazuBxBs7i39Pc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F5vz87ubuAOWdgufvUCVCBJGOIIUDievcf+6bzd5X+zT9UlSkBqDQGOyYIN2xAJYN 5eaV095oQT5LsDFgEREEZUHnAIciBaXetQBIAHk4RlsjPgSuhpK7T2wRhjJENt0101 K+2QElMyUUjOHkHaiZB+/tYNeRfhKQasNoWNd/C/Wsm+Lb9jrPDN0AUKGrMlpqQPWu q2bYe374SOaxE97ROvcXqCzblqlBvzQ9Nk3EvILz9znKDOuhnDzRMGfkp8CCOC0CNY XOnrJPjr8AYS11AfxtZt9lsQUg1CPHMBUbZBEE5gvhmCMIe644XIPDxq6mxcsmlkeT aYpmLi9csd5NA== Subject: Re: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 21:22:58 -0000 On 7/12/13 3:55 PM, Duckworth, Mark wrote: > 3 data model section 10.6. The framework includes a description > attribute only for a Capture Scene, while the data model includes it > also for capture scene entries and media captures. I don抰 recall why > there is the difference. Did the group decide we should add a > description attribute to capture scene entries and media captures? I thought we did for captures. Don't recall that for CSEs. But this could be helpful for both. Thanks, Paul (as individual) From Mark.Duckworth@polycom.com Fri Jul 12 14:44:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D621F9F6F for ; Fri, 12 Jul 2013 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lrroQYN50qj for ; Fri, 12 Jul 2013 14:44:49 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78111E8111 for ; Fri, 12 Jul 2013 14:44:48 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 12 Jul 2013 14:44:48 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 12 Jul 2013 14:44:46 -0700 Thread-Topic: [clue] data model for specifying attribute value in Configure message Thread-Index: Ac5/RAgjZm0gd1M/QwmOWfTX9qmYnQAA/b3w Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> In-Reply-To: <51E0705E.4040305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 21:44:53 -0000 Paul, I agree it doesn't make sense to include different values of the attr= ibute for the same capture. This is related to the statement in the framew= ork in section 6.2.2 "The Consumer must choose the same value for all the M= edia Captures in the Capture Scene Entry." So for me, the question is shou= ld we devise an XML schema for this such that it is impossible for the Cons= umer to construct an inconsistent message? Or is it okay to have a schema = with potentially redundant information, thus enabling the possibility for t= he values to be inconsistent? My proposal allows the inconsistency, and I = agree it would be better to avoid the redundancy and possibility of inconsi= stency. I could make another proposal along those lines later. Are you saying there are also other problems with attributes that can be sp= ecified in the Configure message? What about specifying the encoding param= eters, we agreed on that before didn't we? That is very similar to specify= ing attribute values. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, July 12, 2013 5:09 PM > To: clue@ietf.org > Subject: Re: [clue] data model for specifying attribute value in Configur= e > message >=20 > I've brought this up before, but I'll try again: >=20 > As currently conceived, this mechanism has problems. >=20 > Specifically, these attributes apply to captures, not capture-encodings. >=20 > Suppose I configure two different encodings of the same capture, and supp= ly > different attributes to each. (E.g. one with site switching and one with = scene > switching.) >=20 > At that point, what is the meaning of the capture? I have two encodings > which may be showing entirely different content. IMO this is nonsense. >=20 > So I think there is a problem with attributes that can be specified in th= e > configure. There are a variety of possible solutions. The simplest is sim= ply to > disallow them. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 7/12/13 4:54 PM, Duckworth, Mark wrote: > > I think the data model is intended to support building a Configure > > message by using a list of captureEncoding elements. If so, there > > also needs to be a way to add parameter values of items where the > > Provider has offered a choice. > > > > From the framework: > > > > For each Media Capture in the message, the Consumer may also > > > > specify the value of any attributes for which the Provider has > > > > offered a choice, for example the value for the Scene-switch-policy > > > > attribute. > > > > Currently, I think Scene-switch-policy is the only attribute in this > > category. > > > > Does it make sense to add an element to do this into the > > captureEncodingType? This is similar to item 11 in my other list of > > comments http://www.ietf.org/mail- > archive/web/clue/current/msg02666.html. > > > > Mark > > > > > > > > _______________________________________________ > > 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@alum.mit.edu Fri Jul 12 15:02:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81CA21F9DC6 for ; Fri, 12 Jul 2013 15:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1O5IAysHAUL for ; Fri, 12 Jul 2013 15:02:31 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id B723A21F9B60 for ; Fri, 12 Jul 2013 15:02:30 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id zZju1l0021YDfWL5Ba2V3t; Fri, 12 Jul 2013 22:02:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id za2V1l01M3ZTu2S3ga2VWM; Fri, 12 Jul 2013 22:02:29 +0000 Message-ID: <51E07CF4.70504@alum.mit.edu> Date: Fri, 12 Jul 2013 18:02:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9962@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9962@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373666549; bh=F7yjk15o4zHOAgdniG5oPiKArdbUaFzKyEyXIaCsA64=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cK7IkUEw3SoDdravpqt26f7pm1hm/c00hxcG/ahUvaG8l+xanMgzJkWz8eLaPrLHG nBhKQHjLPQPD1+VMPX02cf6rmYefSzCK5ByLcyfMb5prCYizlDQf95wWYQbhgKbFOm j54zJgmGYxYiL+FzuWZbpvtVntmetl6KqGHgUWeLRF3wC6UEWHW5WFyOnmpl5Hv4nw CXRPjbUeFRWDkemNtVxOGJc/GEdwe/8/k6nEqArxKrOOgvZ3V74mT6s5vrIevW8Rtw waWJwRkBXYXiPllKLPuUBT5AFCgkigQ0DnW6XbBD27NuxTH7jp9qpX9vzjKYxJMRKo khpFvbH4uYSDQ== Subject: Re: [clue] Consumer should always respond to Advertisement with a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 22:02:36 -0000 On 7/11/13 4:20 PM, Duckworth, Mark wrote: > I propose we say the Consumer must send a Configure message to > acknowledge an Advertisement, and remove the paragraph about 揟he > Consumer need not send a new Configure 厰. This seems to be consistent > with the Media Provider state machine in draft-presta-clue-protocol-00, > which says the Provider expects to receive a Configure after sending an > Advertisement. This decision has tight coupling with working out the protocol aspects of the signaling. I'd prefer to have this loose in the fw for now. I think it is becoming clear that we probably need some sort of ack/nak for the Advertisement. But whether the Config *is* an ack is a signaling issue. And we probably don't want to send a Config for an Advertisement that has problems. Hopefully will have this figured out before long. Thanks, Paul From Mark.Duckworth@polycom.com Fri Jul 12 16:31:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0BF21F90DC for ; Fri, 12 Jul 2013 16:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIQzlUl2n23R for ; Fri, 12 Jul 2013 16:31:16 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15721F90CD for ; Fri, 12 Jul 2013 16:31:16 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 12 Jul 2013 16:31:15 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 12 Jul 2013 16:31:13 -0700 Thread-Topic: [clue] Consumer should always respond to Advertisement with a Configure Thread-Index: Ac5/S4iYFCMG7DxbQCSmE1WEQTjGZAAC/qmQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9EC0@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9962@CRPMBOXPRD07.polycom.com> <51E07CF4.70504@alum.mit.edu> In-Reply-To: <51E07CF4.70504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Consumer should always respond to Advertisement with a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 23:31:20 -0000 Hi Paul, That's okay with me. I will remove the contradiction in the framework, and= change the note to reflect this. Thinking again, maybe it doesn't make sense to require a Configure within s= ome time limit. The Consumer application might want to ask the human user = for input before constructing a Configure message. That could take "foreve= r". Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, July 12, 2013 6:02 PM > To: clue@ietf.org > Subject: Re: [clue] Consumer should always respond to Advertisement with = a > Configure >=20 > On 7/11/13 4:20 PM, Duckworth, Mark wrote: >=20 > > I propose we say the Consumer must send a Configure message to > > acknowledge an Advertisement, and remove the paragraph about "The > > Consumer need not send a new Configure ...". This seems to be > > consistent with the Media Provider state machine in > > draft-presta-clue-protocol-00, which says the Provider expects to > > receive a Configure after sending an Advertisement. >=20 > This decision has tight coupling with working out the protocol aspects of= the > signaling. I'd prefer to have this loose in the fw for now. >=20 > I think it is becoming clear that we probably need some sort of ack/nak f= or > the Advertisement. But whether the Config *is* an ack is a signaling issu= e. > And we probably don't want to send a Config for an Advertisement that has > problems. >=20 > Hopefully will have this figured out before long. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri Jul 12 16:33:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF68421F9F4C for ; Fri, 12 Jul 2013 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCy+e+HD9F2z for ; Fri, 12 Jul 2013 16:33:55 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03321F918F for ; Fri, 12 Jul 2013 16:33:55 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 12 Jul 2013 16:33:53 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 12 Jul 2013 16:33:51 -0700 Thread-Topic: [clue] data model priority element Thread-Index: Ac5/RTS8KLmUXcZSRWON/jHb1BxnHwAEsLfQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9EC1@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> <51E07259.9000109@alum.mit.edu> In-Reply-To: <51E07259.9000109@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 23:33:59 -0000 I'm not sure what an "xs:integer" really means. Does it already have an up= per bound? I just don't want to allow arbitrarily large numbers. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, July 12, 2013 5:17 PM > To: clue@ietf.org > Subject: Re: [clue] data model priority element >=20 > On 7/12/13 4:44 PM, Duckworth, Mark wrote: > > About section 10.7 in the data model. > > > > I think this needs more information to make it useful. > > > > Should there be an allowed range? Maybe make it unsigned, with a max > value? >=20 > We need enough so that a data type can be selected to hold it. But the ma= x > value can be large. Signed or unsigned, 16 or 32 bits, would be fine with= me. > Its hardly worth specifying anything smaller. >=20 > > Need to specify if a larger number means higher or lower priority. >=20 > I agree we need to specify the sense of the ordering. I vote for bigger i= s > higher priority. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri Jul 12 16:55:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1557321E805D for ; Fri, 12 Jul 2013 16:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kbo6b3RuJrU for ; Fri, 12 Jul 2013 16:55:44 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF1221E804B for ; Fri, 12 Jul 2013 16:55:43 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 12 Jul 2013 16:55:43 -0700 From: "Duckworth, Mark" To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" Date: Fri, 12 Jul 2013 16:55:40 -0700 Thread-Topic: [clue] data model priority element Thread-Index: Ac5/RTS8KLmUXcZSRWON/jHb1BxnHwAEsLfQAAC7uzA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9ECC@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> <51E07259.9000109@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9EC1@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9EC1@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 23:55:48 -0000 I think I found the answer. http://www.w3.org/TR/xmlschema-2/ I suggest we use something like "xs:unsignedInt" rather than the unbounded = "xs:integer". There are also a few other elements using the unbounded "xs:integer" type. = I think we should change those also to one of the bounded types. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Friday, July 12, 2013 7:34 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] data model priority element >=20 > I'm not sure what an "xs:integer" really means. Does it already have an > upper bound? I just don't want to allow arbitrarily large numbers. >=20 > Mark >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Friday, July 12, 2013 5:17 PM > > To: clue@ietf.org > > Subject: Re: [clue] data model priority element > > > > On 7/12/13 4:44 PM, Duckworth, Mark wrote: > > > About section 10.7 in the data model. > > > > > > I think this needs more information to make it useful. > > > > > > Should there be an allowed range? Maybe make it unsigned, with a > > > max > > value? > > > > We need enough so that a data type can be selected to hold it. But the > > max value can be large. Signed or unsigned, 16 or 32 bits, would be fin= e > with me. > > Its hardly worth specifying anything smaller. > > > > > Need to specify if a larger number means higher or lower priority. > > > > I agree we need to specify the sense of the ordering. I vote for > > bigger is higher priority. > > > > 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 jmpolk@cisco.com Fri Jul 12 18:04:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0932B21F9ED1 for ; Fri, 12 Jul 2013 18:04:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5aaiNSYWQKV for ; Fri, 12 Jul 2013 18:04:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38121F9ECD for ; Fri, 12 Jul 2013 18:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2428; q=dns/txt; s=iport; t=1373677461; x=1374887061; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=WYlkXKzWwz8WWpYv8so86ngNTb9AzxUYjIRkX8zqriA=; b=ENOm99d0QOmJlfX9ztQ25Lc8PPv5G50Tcg+Ek003ujiMZgUSojI+zWcn QxPMksdT9KPiiDZe9jZEiL5Qcf9zQ4fNe2QqslwB4ZeCfSshuROI9CrPG hVLbr+3Wk4myjzhgYFT8z9tz6dssSJKbhclPRh1ImH1DpGQ2NYzjaS2M6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAGOm4FGtJXG+/2dsb2JhbABaDoJ4NMIogQ4WdIIjAQEBBAEBATUCNBcEBwQRBAEBAQkVCQcPCg4fCQgGARKIDwy3Bo9qBoNxA4knoAKCVFwe X-IronPort-AV: E=Sophos;i="4.89,656,1367971200"; d="scan'208";a="234300008" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 13 Jul 2013 01:04:21 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6D14K0n020316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jul 2013 01:04:20 GMT Message-Id: <201307130104.r6D14K0n020316@rcdn-core2-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jul 2013 20:04:19 -0500 To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" From: James Polk In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9ECC@CRPMBOXPRD07.poly com.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> <51E07259.9000109@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9EC1@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D601BC9ECC@CRPMBOXPRD07.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2013 01:04:32 -0000 with the US debt north of $17 trillion, I'm sure no one will consider 4 billion an "...arbitrarily large number..."... ...really, they won't ;-) -j At 06:55 PM 7/12/2013, Duckworth, Mark wrote: >I think I found the answer. >http://www.w3.org/TR/xmlschema-2/ > >I suggest we use something like "xs:unsignedInt" rather than the >unbounded "xs:integer". > >There are also a few other elements using the unbounded "xs:integer" >type. I think we should change those also to one of the bounded types. > >Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Duckworth, Mark > > Sent: Friday, July 12, 2013 7:34 PM > > To: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] data model priority element > > > > I'm not sure what an "xs:integer" really means. Does it already have an > > upper bound? I just don't want to allow arbitrarily large numbers. > > > > Mark > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > > Of Paul Kyzivat > > > Sent: Friday, July 12, 2013 5:17 PM > > > To: clue@ietf.org > > > Subject: Re: [clue] data model priority element > > > > > > On 7/12/13 4:44 PM, Duckworth, Mark wrote: > > > > About section 10.7 in the data model. > > > > > > > > I think this needs more information to make it useful. > > > > > > > > Should there be an allowed range? Maybe make it unsigned, with a > > > > max > > > value? > > > > > > We need enough so that a data type can be selected to hold it. But the > > > max value can be large. Signed or unsigned, 16 or 32 bits, would be fine > > with me. > > > Its hardly worth specifying anything smaller. > > > > > > > Need to specify if a larger number means higher or lower priority. > > > > > > I agree we need to specify the sense of the ordering. I vote for > > > bigger is higher priority. > > > > > > 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 Sun Jul 14 16:56:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC21421F8BB7 for ; Sun, 14 Jul 2013 16:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90kh6z31PSjS for ; Sun, 14 Jul 2013 16:56:47 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1238521F8E79 for ; Sun, 14 Jul 2013 16:56:45 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Sun, 14 Jul 2013 16:56:44 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sun, 14 Jul 2013 16:56:43 -0700 Thread-Topic: [clue] Ticket #35 consistency of data model and framework Thread-Index: Ac5/Rf/z2X+A5rCzRfWcCE7CvCGnRgBp6oiA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601BC9F2C@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> <51E073A2.10500@alum.mit.edu> In-Reply-To: <51E073A2.10500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2013 23:56:51 -0000 I will add the description attribute to Media Capture and Capture Scene Ent= ry in the framework, to make this consistent with the data model. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, July 12, 2013 5:23 PM > To: clue@ietf.org > Subject: Re: [clue] Ticket #35 consistency of data model and framework >=20 > On 7/12/13 3:55 PM, Duckworth, Mark wrote: >=20 > > 3 - data model section 10.6. The framework includes a description > > attribute only for a Capture Scene, while the data model includes it > > also for capture scene entries and media captures. I don't recall why > > there is the difference. Did the group decide we should add a > > description attribute to capture scene entries and media captures? >=20 > I thought we did for captures. Don't recall that for CSEs. >=20 > But this could be helpful for both. >=20 > Thanks, > Paul (as individual) >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From internet-drafts@ietf.org Sun Jul 14 18:48:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEBF21F9D71; Sun, 14 Jul 2013 18:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F13v7QOBxm6C; Sun, 14 Jul 2013 18:48:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BBB21F9C53; Sun, 14 Jul 2013 18:48:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715014840.2079.89990.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 18:48:40 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-11.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:48:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-11.txt Pages : 48 Date : 2013-07-14 Abstract: This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stewe@stewe.org Sun Jul 14 18:50:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB6421F9D8A for ; Sun, 14 Jul 2013 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bor-V3SB57MM for ; Sun, 14 Jul 2013 18:50:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 968F421F9D66 for ; Sun, 14 Jul 2013 18:50:24 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB192.namprd07.prod.outlook.com (10.242.167.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 15 Jul 2013 01:50:21 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.146]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.123]) with mapi id 15.00.0731.000; Mon, 15 Jul 2013 01:50:21 +0000 From: Stephan Wenger To: "CLUE (clue@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-clue-framework-11.txt Thread-Index: AQHOgP1xOTkQM6/qs0qtjx3Y2Rubk5lk+PlA Date: Mon, 15 Jul 2013 01:50:20 +0000 Message-ID: <7dbda5f903234e638486ed9e5655dec6@CO1PR07MB191.namprd07.prod.outlook.com> References: <20130715014840.2079.39468.idtracker@ietfa.amsl.com> In-Reply-To: <20130715014840.2079.39468.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 09086FB5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377424004)(189002)(199002)(53754006)(77982001)(33646001)(63696002)(66066001)(76482001)(74876001)(47446002)(83072001)(59766001)(74502001)(49866001)(46102001)(65816001)(56816003)(50986001)(31966008)(80022001)(76786001)(54316002)(76576001)(47736001)(74662001)(74366001)(51856001)(56776001)(16406001)(77096001)(79102001)(74316001)(4396001)(15202345003)(74706001)(81542001)(54356001)(53806001)(69226001)(76796001)(47976001)(81342001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB192; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [clue] FW: New Version Notification for draft-ietf-clue-framework-11.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:50:29 -0000 SGkgYWxsLA0KVmVyc2lvbiAxMSBvZiB0aGUgZnJhbWV3b3JrIEktRCBoYXMganVzdCBiZWVuIHBv c3RlZC4gIE1hcmsgYW5kIEFuZHkgYXJlIHRvIHByYWlzZSBmb3IgaW1wcm92ZW1lbnRzLCBJJ20g dG8gYmxhbWUgZm9yIGZvcm1hdHRpbmcgaXNzdWVzIChpZiBhbnkpLg0KU3RlcGhhbg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMTQgSnVseSwgMjAxMyAx ODo0OQ0KVG86IEFuZHJldyBQZXBwZXJlbGw7IFN0ZXBoYW4gV2VuZ2VyOyBNYXJrIER1Y2t3b3J0 aA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWNsdWUt ZnJhbWV3b3JrLTExLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWNs dWUtZnJhbWV3b3JrLTExLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1h cmsgRHVja3dvcnRoIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrDQpSZXZpc2lvbjoJIDExDQpUaXRsZToJCSBG cmFtZXdvcmsgZm9yIFRlbGVwcmVzZW5jZSBNdWx0aS1TdHJlYW1zDQpDcmVhdGlvbiBkYXRlOgkg MjAxMy0wNy0xNQ0KR3JvdXA6CQkgY2x1ZQ0KTnVtYmVyIG9mIHBhZ2VzOiA0OA0KVVJMOiAgICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNs dWUtZnJhbWV3b3JrLTExLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmsNCkh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29yay0xMQ0K RGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWNsdWUtZnJhbWV3b3JrLTExDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBvZmZl cnMgYSBmcmFtZXdvcmsgZm9yIGEgcHJvdG9jb2wgdGhhdCBlbmFibGVzDQogICBkZXZpY2VzIGlu IGEgdGVsZXByZXNlbmNlIGNvbmZlcmVuY2UgdG8gaW50ZXJvcGVyYXRlIGJ5IHNwZWNpZnlpbmcN CiAgIHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gbXVsdGlwbGUgbWVkaWEgc3RyZWFtcy4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From Christian.Groves@nteczone.com Sun Jul 14 19:29:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA0821F9AE6 for ; Sun, 14 Jul 2013 19:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVLxDBq76fcJ for ; Sun, 14 Jul 2013 19:29:41 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02321F99D3 for ; Sun, 14 Jul 2013 19:29:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABhd41F20S8S/2dsb2JhbAANTYM6wh6BIoMXAQEBAQMBAQEvAQUbGxsLGAklDwIWMBMGAgEBBYgTo2aRUY4yCoEvg3gDrE2BXw Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 11:59:39 +0930 Message-ID: <51E35E92.403@nteczone.com> Date: Mon, 15 Jul 2013 12:29:38 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 02:29:42 -0000 Hello Mark, Please see my comments below. Regards, Christian On 13/07/2013 5:55 AM, Duckworth, Mark wrote: > > Here is the list of things I found to be inconsistent. > > 1 data model section 3 搒imultaneous capture sets should be > 搒imultaneous <> sets > > 2 data model section 10 a media capture can include many > spatialInformation elements. There was some discussion of this back in > November. > http://www.ietf.org/mail-archive/web/clue/current/msg02113.html. I > propose we remove the maxOccurs=攗nbounded and have just a single > spatialInformation, which is consistent with the framework. > [CNG] OK > > 3 data model section 10.6. The framework includes a description > attribute only for a Capture Scene, while the data model includes it > also for capture scene entries and media captures. I don抰 recall why > there is the difference. Did the group decide we should add a > description attribute to capture scene entries and media captures? > [CNG] I can't recall this either. I thought the idea was to describe the captures through attributes rather than a free text field. > > 4 data model section 10.9 should replace content element with the > presentation element, as described in framework section 6.1.1. > > 5 both data model and framework should add new information about > role attributes/elements after discussing > draft-groves-clue-role-clarifications. > > 6 data model section 10.x add a 搗iew element as described in > framework section 6.1.1 > > 7 data model section 10.11 rename the 揹ynamic element to something > like 揷aptureMobility and update description as described in the > framework for the 揗obility of Capture attribute. > > 8 data model section 11.2 has a micPattern element, which is not in > the framework. Did the group decide to add this as an attribute of an > audio capture? I don抰 remember such a decision. > [CNG] Not that I'm aware of. > > 9 - data model section 12.1 has a nativeAspectRatio element, which is > not in the framework. Did the group decide to add this as an attribute > of a video capture? I don抰 remember such a decision. > [CNG] Not that I'm aware of. > > 10 data model section 14.1 the sceneSpace element should be removed. > We already decided to remove the 揳rea of scene attribute in the > framework. > > 11 data model section 22 should captureEncodingType also include > additional elements to specify the specific values of the parameters > bandwidth, width, height, etc? Framework section 9 says 揈ach Capture > Encoding refers to one Media Capture, one Individual Encoding, and > includes the encoding parameter values. Refer to conversation > http://www.ietf.org/mail-archive/web/clue/current/msg02526.html > [CNG] Isn't that covered by section 16 ? The structure in 22 provides a pointer to the encoding through the encoding ID? > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Sun Jul 14 19:45:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7921F9C53 for ; Sun, 14 Jul 2013 19:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSfjvtwscLs5 for ; Sun, 14 Jul 2013 19:45:40 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 002C821F9B38 for ; Sun, 14 Jul 2013 19:45:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAP1h41F20S8S/2dsb2JhbAANTYM6wh6BI4MXAQEBAQMBAQE1GxsKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiBijZpFUj2sGEINiA6xN Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 12:15:03 +0930 Message-ID: <51E3622B.1070502@nteczone.com> Date: Mon, 15 Jul 2013 12:44:59 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E1D@CRPMBOXPRD07.polycom.com> <51E07259.9000109@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9EC1@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D601BC9ECC@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9ECC@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] data model priority element X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 02:45:42 -0000 Hello Mark, I'm OK with the bounded type. With regards to the priority values I tend to think of a line analogy when considering priority, i.e. if your number 1 in line you get in before number 256. However I'm easy so long as its defined. It may also pay to specify a special value say "0" which is a default "not subject to priority". Regards, Christian On 13/07/2013 9:55 AM, Duckworth, Mark wrote: > I think I found the answer. > http://www.w3.org/TR/xmlschema-2/ > > I suggest we use something like "xs:unsignedInt" rather than the unbounded "xs:integer". > > There are also a few other elements using the unbounded "xs:integer" type. I think we should change those also to one of the bounded types. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Duckworth, Mark >> Sent: Friday, July 12, 2013 7:34 PM >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] data model priority element >> >> I'm not sure what an "xs:integer" really means. Does it already have an >> upper bound? I just don't want to allow arbitrarily large numbers. >> >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Friday, July 12, 2013 5:17 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] data model priority element >>> >>> On 7/12/13 4:44 PM, Duckworth, Mark wrote: >>>> About section 10.7 in the data model. >>>> >>>> I think this needs more information to make it useful. >>>> >>>> Should there be an allowed range? Maybe make it unsigned, with a >>>> max >>> value? >>> >>> We need enough so that a data type can be selected to hold it. But the >>> max value can be large. Signed or unsigned, 16 or 32 bits, would be fine >> with me. >>> Its hardly worth specifying anything smaller. >>> >>>> Need to specify if a larger number means higher or lower priority. >>> I agree we need to specify the sense of the ordering. I vote for >>> bigger is higher priority. >>> >>> 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 Christian.Groves@nteczone.com Sun Jul 14 19:47:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BDB21F9C2E for ; Sun, 14 Jul 2013 19:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id penPb7WDvJoS for ; Sun, 14 Jul 2013 19:47:56 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 6115221F9A30 for ; Sun, 14 Jul 2013 19:47:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAP1h41F20S8S/2dsb2JhbAANTYM6wh6BI4MXAQEBAQMBAQE1GxsKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiBijZpFQBI4tgT4GEINiA6xNgVc Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 12:17:55 +0930 Message-ID: <51E362D8.1080807@nteczone.com> Date: Mon, 15 Jul 2013 12:47:52 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9962@CRPMBOXPRD07.polycom.com> <51E07CF4.70504@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9EC0@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9EC0@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Consumer should always respond to Advertisement with a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 02:47:57 -0000 Hello Mark, I'd agree with Paul. I think we do need an ACK of the advertisement, but whether that's an Configure message with CaptureEncoding et al. is another thing. Regards, Christian On 13/07/2013 9:31 AM, Duckworth, Mark wrote: > Hi Paul, > That's okay with me. I will remove the contradiction in the framework, and change the note to reflect this. > > Thinking again, maybe it doesn't make sense to require a Configure within some time limit. The Consumer application might want to ask the human user for input before constructing a Configure message. That could take "forever". > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Friday, July 12, 2013 6:02 PM >> To: clue@ietf.org >> Subject: Re: [clue] Consumer should always respond to Advertisement with a >> Configure >> >> On 7/11/13 4:20 PM, Duckworth, Mark wrote: >> >>> I propose we say the Consumer must send a Configure message to >>> acknowledge an Advertisement, and remove the paragraph about "The >>> Consumer need not send a new Configure ...". This seems to be >>> consistent with the Media Provider state machine in >>> draft-presta-clue-protocol-00, which says the Provider expects to >>> receive a Configure after sending an Advertisement. >> This decision has tight coupling with working out the protocol aspects of the >> signaling. I'd prefer to have this loose in the fw for now. >> >> I think it is becoming clear that we probably need some sort of ack/nak for >> the Advertisement. But whether the Config *is* an ack is a signaling issue. >> And we probably don't want to send a Config for an Advertisement that has >> problems. >> >> Hopefully will have this figured out before long. >> >> 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 Christian.Groves@nteczone.com Sun Jul 14 20:06:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3F821F90FD for ; Sun, 14 Jul 2013 20:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPTxNhMXWMPQ for ; Sun, 14 Jul 2013 20:06:18 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9621F8FF8 for ; Sun, 14 Jul 2013 20:06:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwBAIBm41F20S8S/2dsb2JhbAANTYM6ScFVgSODFwEBAQECAQEBATUbGxcECxEEAQEBCR4HDwIWHwkIEwYCAQEFEodvDQWjaJFTjjKBOQaDcgOkBohHgV8 Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 12:36:16 +0930 Message-ID: <51E36725.80002@nteczone.com> Date: Mon, 15 Jul 2013 13:06:13 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 03:06:19 -0000 Hello Mark, I don't think the rule regarding CSE helps. The configure only lists the CaptureID/EncodingID, no CSE or SceneID. The trouble with having parameters in the Configure is that effectively a CaptureID no longer lists a unique capture. You could in theory have a CaptureID with different sets of attributes. An Advertisement could offer a CaptureID with multiple values and a set of encodings. A consumer could in theory return the same CaptureID multiple times with different values and the same encoding ID. This would lead to the same CaptureEncoding which would cause referencing issues. Regards, Christian On 13/07/2013 7:44 AM, Duckworth, Mark wrote: > Paul, I agree it doesn't make sense to include different values of the attribute for the same capture. This is related to the statement in the framework in section 6.2.2 "The Consumer must choose the same value for all the Media Captures in the Capture Scene Entry." So for me, the question is should we devise an XML schema for this such that it is impossible for the Consumer to construct an inconsistent message? Or is it okay to have a schema with potentially redundant information, thus enabling the possibility for the values to be inconsistent? My proposal allows the inconsistency, and I agree it would be better to avoid the redundancy and possibility of inconsistency. I could make another proposal along those lines later. > > Are you saying there are also other problems with attributes that can be specified in the Configure message? What about specifying the encoding parameters, we agreed on that before didn't we? That is very similar to specifying attribute values. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Friday, July 12, 2013 5:09 PM >> To: clue@ietf.org >> Subject: Re: [clue] data model for specifying attribute value in Configure >> message >> >> I've brought this up before, but I'll try again: >> >> As currently conceived, this mechanism has problems. >> >> Specifically, these attributes apply to captures, not capture-encodings. >> >> Suppose I configure two different encodings of the same capture, and supply >> different attributes to each. (E.g. one with site switching and one with scene >> switching.) >> >> At that point, what is the meaning of the capture? I have two encodings >> which may be showing entirely different content. IMO this is nonsense. >> >> So I think there is a problem with attributes that can be specified in the >> configure. There are a variety of possible solutions. The simplest is simply to >> disallow them. >> >> Thanks, >> Paul >> >> >> >> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>> I think the data model is intended to support building a Configure >>> message by using a list of captureEncoding elements. If so, there >>> also needs to be a way to add parameter values of items where the >>> Provider has offered a choice. >>> >>> From the framework: >>> >>> For each Media Capture in the message, the Consumer may also >>> >>> specify the value of any attributes for which the Provider has >>> >>> offered a choice, for example the value for the Scene-switch-policy >>> >>> attribute. >>> >>> Currently, I think Scene-switch-policy is the only attribute in this >>> category. >>> >>> Does it make sense to add an element to do this into the >>> captureEncodingType? This is similar to item 11 in my other list of >>> comments http://www.ietf.org/mail- >> archive/web/clue/current/msg02666.html. >>> Mark >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Jul 14 20:19:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B27A21F9D65 for ; Sun, 14 Jul 2013 20:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl4pvmEqz+0v for ; Sun, 14 Jul 2013 20:19:33 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5021F9D50 for ; Sun, 14 Jul 2013 20:19:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAAdp41F20S8S/2dsb2JhbAANTYM6wh6BJIMXAQEBAQMBAQEvAQUbGwoRCxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgYo2iRUASOF4FUg3gDrE0 Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 12:49:30 +0930 Message-ID: <51E36A40.5040404@nteczone.com> Date: Mon, 15 Jul 2013 13:19:28 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60146DF92@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D601BC9946@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9946@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] comments on description of RTP topologies X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 03:19:33 -0000 Hello Mark, I would agree it would be good to be consistent with the topology terminology between draft-ietf-clue-rtp-mapping and draft-ietf-avtcore-rtp-topologies-update. With regards for CLUE support of Topo-Video-switch-MCU is this a real issue? The Advertisement/Configures could describe such a scenario where the consumer sees a switched view. The actual RTP would be described by SDP? Regards, Christian On 12/07/2013 6:05 AM, Duckworth, Mark wrote: > > Can anybody answer my questions below? In particular, we aren抰 aiming > for CLUE to support Topo-Video-switch-MCU, correct? > > Is anybody else interested in clarifying the rtp-mapping document, to > more explicitly use the same terminology for topologies from > draft-ietf-avtcore-rtp-topologies-update? (I assume this avtcore > document will become an RFC) > > Thanks, > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Duckworth, Mark > *Sent:* Friday, June 14, 2013 10:35 AM > *To:* clue@ietf.org > *Subject:* [clue] comments on description of RTP topologies > > This is regarding section 3. RTP topologies for CLUE, in > draft-ietf-clue-rtp-mapping-00. > > I抦 having difficulty relating the topologies described here to the > terminology described in draft-ietf-avtcore-rtp-topologies-update-00. > There doesn抰 seem to be a clean mapping, so I抎 like to clarify this > and make it cleaner, using the same terminology. > > From the beginning of section 3: > > 揊or telepresence, the relevant topologies include point-to-point, as > well as media mixers, media- switching mixers, and source-projection > mixers. > > So for these four categories, I would like to understand how they map > to the topologies described in > draft-ietf-avtcore-rtp-topologies-update. The following list describes > how I think the two documents relate. Do I understand this correctly? > Can we make this more explicit in the CLUE document, to list the CLUE > topologies directly using terminology from the rtp-topologies-update > document, so we don抰 have to map it to a new set of CLUE terminology? > > 1.point-to-point. This includes: > > a.Topo-Point-to-Point > > b.Topo-PtP-Translator not sure if this is meant to be included or not? > > c.Back to back RTP sessions not sure if this is meant to be included > or not? > > 2.media mixers. This includes: > > a.Topo-RTCP-terminating-MCU > > b.Topo-Mixer, Media Mixing variety (3.6.1 of rtp-topologies-update) > > 3.media switching mixers. This includes: > > a.Topo-Mixer, Media Switching variety (3.6.2 of rtp-topologies-update) > > 4.source projection mixers. This includes: > > a.Source Projecting Middlebox (3.7 of rtp-topologies-update) > > We should also add De-composite Endpoint (3.10 of > rtp-topologies-update), as we agreed in the June 2012 interim meeting. > > I believe we also agreed CLUE is not attempting to support > Topo-Video-switch-MCU, so I suggest we remove reference to this one. > The document refers to this as if CLUE supports it, which I think is > not the case. > > I have a related question in avtcore, asking if source projection is > intended to be a variety of Topo-Mixer. > > Mark Duckworth > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Mon Jul 15 01:01:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93221F8F67 for ; Mon, 15 Jul 2013 01:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REg3HVNl7YTr for ; Mon, 15 Jul 2013 01:01:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB1521F8C4C for ; Mon, 15 Jul 2013 01:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5953; q=dns/txt; s=iport; t=1373875262; x=1375084862; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+fEJsVbSEuFuspgq3v8Vm4XQxYrmu4eHMia6M7L2USQ=; b=A2+yf1Gxpm2JAduSzUAfqJRHJkUTey9n0FniiiU9L/Iy+V/Ny9nId5NM xeT/wEmnAq4ifWaTQHW5+VchYPOj1cF6uwnxYaETDJUPvpggPzFHoSp3v dQ4a0i38cGALoVyI4SHYJLYAnJd9ASN68p848B9k7RkUKWNCYYcXCaSM4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJSr41GtJV2c/2dsb2JhbABQCg6CeDRPwVCBCxZ0giMBAQEDAQEBATc0CQcHBAIBCA4DAwEBAQEKFAkHJwsUCAEIAgQBEggBiAEGDLUSjiiBCwYyAgSDBW0DlAWFAJAkgVl7PoIo X-IronPort-AV: E=Sophos;i="4.89,667,1367971200"; d="scan'208";a="234840104" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 08:01:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6F80x1l017093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 08:00:59 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.134]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 03:00:59 -0500 From: "Espen Berger (espeberg)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt Thread-Index: AQHOf0LZo48zvxMzAU2WsQZMA3jIDpllYmNA Date: Mon, 15 Jul 2013 08:00:58 +0000 Message-ID: References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51DB8583.40709@nteczone.com> <51E06E4D.1010801@alum.mit.edu> In-Reply-To: <51E06E4D.1010801@alum.mit.edu> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.164.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:01:09 -0000 Agree.=20 As a receiver of a specific application-id I can map an ID back to a captur= e with a set of encoding attributes. In the CLUE framework I think that is = named a capture encoding.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: 12. juli 2013 23:00 To: clue@ietf.org Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mm= usic-application-token-00.txt On 7/12/13 7:40 AM, Espen Berger (espeberg) wrote: > I like the application token draft and find it very useful that its indep= endent of CLUE to be reusable in other use cases as well. > > I think CLUE capture ID should build on the application-id . We should av= oid having both application-id and capture-id in the signaling, that sounds= like doubling of information. The app-id could mean a concrete capture wit= h a given set of encoding values, which we have referred to as capture enco= dings. I have to keep saying this: This needs to be the id of a capture-encoding, not of a capture, because th= ere can be multiple encodings of a capture. It can potentially be just an encoding ID, because an encoding can only be = mapped to one capture at a time, so that given an encoding id you can look = up the corresponding capture id (based on currently active configuration.) Thanks, Paul > Regards > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Jonathan Lennox > Sent: 9. juli 2013 20:34 > To: Christian Groves > Cc: clue@ietf.org > Subject: Re: [clue] [MMUSIC] FW: New Version Notification for=20 > draft-even-mmusic-application-token-00.txt > > > On Jul 8, 2013, at 11:37 PM, Christian Groves wrote: > >> Hello Roni, >> >> How would you envisage using this for CLUE? Would a "CLUE capture ID" >> attribute need to be defined? >> i.e. a=3DappID:2 CLUECapID:1 >> >> or something else? >> >> Regards, Christian > > Not to speak for Roni, but as his co-author, my vague idea is that we'd b= ind appIDs to m-lines (either one per m-line, or multiple per m-line, depen= ding on whether MMUSIC goes with Plan A or Plan B); then the CLUE channel w= ould associate appIDs to either encodings or capture encodings (depending o= n decisions in this group). > > >> On 29/06/2013 2:31 AM, Mary Barnes wrote: >>> ---------- Forwarded message ---------- >>> From: Roni Even >>> Date: Fri, Jun 28, 2013 at 10:54 AM >>> Subject: [MMUSIC] FW: New Version Notification for=20 >>> draft-even-mmusic-application-token-00.txt >>> To: "mmusic@ietf.org" >>> >>> >>> Hi, >>> We have submitted this document that defines a mechanism to provide=20 >>> the mapping between the >>> SSRCs of RTP streams and the application semantics by defining=20 >>> extensions to RTP and RTCP messages. >>> >>> It defines a new SDP attribute, RTCP SDES message and RTP header=20 >>> extension for this puropose. The document explains how it can be=20 >>> used with the different multiplexing proposal (Plan A, Plan B and no pl= an). >>> >>> It can be used also in CLUE to map SSRCs to Clue media capture. >>> >>> Please review and send comments >>> Thanks >>> Roni Even >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Friday, June 28, 2013 6:27 PM >>> To: Jonathan Lennox; Qin Wu; Roni Even >>> Subject: New Version Notification for=20 >>> draft-even-mmusic-application-token-00.txt >>> >>> A new version of I-D, draft-even-mmusic-application-token-00.txt >>> has been successfully submitted by Roni Even and posted to the IETF=20 >>> repository. >>> >>> Filename: draft-even-mmusic-application-token >>> Revision: 00 >>> Title: The Session Description Protocol (SDP) Application >>> Token Attribute >>> Creation date: 2013-06-28 >>> Group: Individual Submission >>> Number of pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-to >>> k >>> en-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token >>> Htmlized: >>> http://tools.ietf.org/html/draft-even-mmusic-application-token-00 >>> >>> >>> Abstract: >>> The RTP fixed header includes the payload type number and the SSRC >>> values of the RTP stream. RTP defines how you de-multiplex streams >>> within an RTP session, but in some use cases applications need >>> further identifiers in order to identify the application semantics >>> associated with particular streams within the session. >>> >>> This document defines a mechanism to provide the mapping between th= e >>> SSRCs of RTP streams and the application semantics by defining >>> extensions to RTP and RTCP messages. >>> >>> >>> >>> >>> The IETF Secretariat >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Jul 15 10:06:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A56D21E80E6 for ; Mon, 15 Jul 2013 10:06:03 -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=[AWL=-0.661, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9EXXOEQhrOZ for ; Mon, 15 Jul 2013 10:05:58 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0321E80CD for ; Mon, 15 Jul 2013 10:05:52 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id 0cxE1m0091vXlb857h5skZ; Mon, 15 Jul 2013 17:05:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 0h5s1m00E3ZTu2S3dh5sXa; Mon, 15 Jul 2013 17:05:52 +0000 Message-ID: <51E42BEF.4070906@alum.mit.edu> Date: Mon, 15 Jul 2013 13:05:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE References: <20130715150851.5667.52201.idtracker@ietfa.amsl.com> In-Reply-To: <20130715150851.5667.52201.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373907952; bh=D0AvS/BDPnwVnO608OqN+9SaUFtXJiJAgcZ6SIPty3k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=stY/L98usgURl917VaFurwSniXbmVZHSAVbS/Upr64jSujfH5sulcM1DW7+LYm+bU Yl5HopqWo3TYYhQH0gp6+dyK84p+E5sDVwwX/ZKHB4I4zX+SopyilqMA+V9B1j+x7K JKZl8iGZzEFt8sMq//WhuL23uNJowVzmr2aMT4Ld12HJMjlvftQDArVRSQZRcYZO9P 5L08aK0/AAFG1xOBcvb0T2y0+qgak9oQhYhVzKj5XXf1EirnwRvRCsy/NjiMf7wt2Z aOyDSSJhlTUWiO+nPJTlkMGaNxWESfQhb0CTq5ksIIQzhWP6rbsHA5MxUq6Pp7duOJ w5U56pujq4H+A== Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-signaling-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:06:03 -0000 This was actually submitted by Rob. (Thanks Rob!) I do have some comments on the new changes. Please don't think I'm being critical. I am thrilled that we have something with enough substance to debug. Section 4.1 says: The presence of an active m-line for the CLUE channel in an SDP offer is an indication that the offer that the sender is CLUE-capable and hence can understand CLUE-specific syntax. We have to sort out if this is sufficient. It depends on whether the SDP for offering the CLUE channel is itself sufficient to distinguish it from an SCTP session for something else. Hopefully it will be. But as long as we are using the grouping framework with CLUE semantic, we can use *that* as a reliable indicator of clue capability. Then presence of the clue channel m-line in the CLUE group clearly indicates what it is, and acceptance of it indicates intent to use CLUE. Section 4.2 says: A receiver who wishes to receive a CLUE stream via this encoding requires a matching "a=recvonly" "m" line. As well as the normal restrictions defined in [RFC3264] media MUST NOT be sent on this stream until the sender has received a valid CLUE Configure message specifying the capture to be used for this stream. This may need some qualification. If ICE is to be used, then it needs to be sent prior to the config. (But that isn't technically *media*.) And even in the absence of ICE, NAT traversal may require that *something* be sent at all times to keep the nat binding open. Section 3.7 and 4.2 say: An a=label will be used to link encodings to the advertisements and configures. But section 4.4 says that the grouping framework will be used to mark the m-lines that are clue-controlled. This seems like a redundancy/conflict to me. IMO the grouping framework (with a=mid) is the right thing to use if there is a need to specify a certain form of grouping. And if doing that, then the a=mid is probably ok to use for application level reference as well. OTOH, if there is no need for grouping, then IMO a=label would be preferred. In this case, the question is whether we need the grouping. Is there a need to identify those m-lines controlled by clue, without reference to an advertisement? Or is it sufficient to use the advertisement to identify those m-lines that are controlled by CLUE. I'm not sure. One advantage of using the grouping is that it is a much more specific indication that CLUE is in use than the presence of the clue channel. And I suppose it can prevent premature decisions about what to do with m-lines, before an advertisement referencing them is received. So maybe, on balance, there is advantage to using grouping. And if so, then I think we can just use the mid values to reference the specific m-lines from clue messages. Section 5.2: Generally, implementations that receive messages for which they have incomplete information SHOULD wait until they have the corresponding information they lack before sending messages to make changes related to that information. For instance, an implementation that receives a new SDP offer with three new "a=sendonly" CLUE "m" lines that has not received the corresponding CLUE Advertisement providing the capture information for those streams SHOULD NOT include corresponding "a=recvonly" lines in its answer, but instead should make a new SDP offer when and if a new Advertisement arrives with captures relevant to those encodings. The above is a bit incomplete/confusing. When the offer is received, *some* answer must be sent. What should it be? The options are: - accept the m-line, a=recvonly - accept the m-line, a=inactive - reject the m-line (port=0) Do we really care which one is used? IMO we don't care. If we are to say anything, it might be that *if* the answerer chooses not to accept the m-line with a=recvonly, *then* it will need to send an offer to change this if it later decides to configure that encoding. Section 6: What prevents Bob from sending an INVITE to Alice right after sending ADV 2? (And thus glaring with the one from Alice?) 200 OK 2 says: "(+2 recvonly)". I find this confusing. The answer can't change the number of m-lines from what was in the offer. Presumably this is intended to mean that it is accepting two of the added three m-lines. But its easy to misconstrue. I think it might be better to just leave this off and leave it to text to explain. "MEDIA 3" says: "2 video A->B, 1 video B->A". This seems to be counting the sendrecv video in one direction but not the other. It looks to me like it should be "3 video A->B, 1 video B->A". (And so MEDIA 3 should mention *3* videos in each direction. At some point, either that first sendrecv m-line should be included as a clue-controlled m-line, as an encoding (for both sides?) or else it ought to be rejected or put into inactive state. The answer to INVITE 2 doesn't have an a=mid for the rejected m-line. I think 5888 requires that it have one. (This shows up elsewhere too.) The delay in sending a Configure, until an offer is received that defines the encodings in the Adv, may be in conflict with the proposal that every Adv should receive a Conf quite soon. *Maybe* the offer will be received soon "enough" to send a prompt configure. But its really hard to ensure that. This could lead to complex interactions between state machines for SIP O/A and CLUE and their respective timers. So I think we should assume that each Adv will receive an immediate Conf, even if it doesn't request anything. Thanks, Paul (as individual) On 7/15/13 11:08 AM, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-kyzivat-clue-signaling-04.txt > has been successfully submitted by Paul Kyzivat and posted to the > IETF repository. > > Filename: draft-kyzivat-clue-signaling > Revision: 04 > Title: CLUE Signaling > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 33 > URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-04.txt > Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-04 > > Abstract: > This document specifies how signaling is conducted in the course of > CLUE sessions. This includes how SIP/SDP signaling is applied to > CLUE sessions as well as defining a CLUE-specific signaling protocol > that complements SIP/SDP and supports negotiation of CLUE application > level data. > > > > > The IETF Secretariat > > From internet-drafts@ietf.org Mon Jul 15 11:28:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472C011E81C7; Mon, 15 Jul 2013 11:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYzOXBWDw0nV; Mon, 15 Jul 2013 11:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BDB11E8149; Mon, 15 Jul 2013 11:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715182837.20459.92496.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:28:37 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:28:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : An XML Schema for the CLUE data model Author(s) : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-00.txt Pages : 45 Date : 2013-07-15 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From roberta.presta@unina.it Mon Jul 15 12:42:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86B111E8129 for ; Mon, 15 Jul 2013 12:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpxtXcUEs2Pq for ; Mon, 15 Jul 2013 12:42:42 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id A7E7D11E81E8 for ; Mon, 15 Jul 2013 12:42:38 -0700 (PDT) Received: from [127.0.0.1] (2-237-80-133.ip237.fastwebnet.it [2.237.80.133]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6FJgZGu009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 21:42:36 +0200 Message-ID: <51E450AC.1080102@unina.it> Date: Mon, 15 Jul 2013 21:42:36 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> Content-Type: multipart/alternative; boundary="------------000204080702050207020605" X-Antivirus: avast! (VPS 130715-0, 15/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 19:42:47 -0000 This is a multi-part message in MIME format. --------------000204080702050207020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Mark, some data model updates are listed below. Thank you, Roberta Il 12/07/2013 21:55, Duckworth, Mark ha scritto: > > Here is the list of things I found to be inconsistent. > > 1 ?? data model section 3 ??simultaneous capture sets?? should be > ??simultaneous <> sets?? > Ok. > > 2 ?? data model section 10 a media capture can include many > spatialInformation elements. There was some discussion of this back > in November. > http://www.ietf.org/mail-archive/web/clue/current/msg02113.html. I > propose we remove the maxOccurs=??unbounded?? and have just a single > spatialInformation, which is consistent with the framework. > Ok. > > 3 ?? data model section 10.6. The framework includes a description > attribute only for a Capture Scene, while the data model includes it > also for capture scene entries and media captures. I don??t recall > why there is the difference. Did the group decide we should add a > description attribute to capture scene entries and media captures? > We left the description element in capture scene and capture scene entry. It can be useful in the design, development and testing phases. It appears as an optional field, however. > > 4 ?? data model section 10.9 should replace content element with the > presentation element, as described in framework section 6.1.1. > We have removed the content attribute but we have not modeled yet the presentation attribute by using XML Schema.. > > 5 ?? both data model and framework should add new information about > role attributes/elements after discussing > draft-groves-clue-role-clarifications. > ToDo. > > 6 ?? data model section 10.x add a ??view?? element as described in > framework section 6.1.1 > ToDo. > > 7 ?? data model section 10.11 rename the ??dynamic?? element to > something like ??captureMobility?? and update description as > described in the framework for the ??Mobility of Capture?? attribute. > Ok. We have add both an optional element under the definition of the media capture type and the definition of an enumeration type named "mobilityType". > > 8 ?? data model section 11.2 has a micPattern element, which is not > in the framework. Did the group decide to add this as an attribute of > an audio capture? I don??t remember such a decision. > Removed - this was an example of an (optional) audio-specific media capture attribute that we discussed on the mailing list in a very old thread with John Leslie (24-10-2012). > > 9 - data model section 12.1 has a nativeAspectRatio element, which is > not in the framework. Did the group decide to add this as an attribute > of a video capture? I don??t remember such a decision. > Removed - It was a media capture attribute proposed in the Romanow's data model draft that we classified as a video-specific attribute. > > 10 ?? data model section 14.1 the sceneSpace element should be > removed. We already decided to remove the ??area of scene?? > attribute in the framework. > Ok. > > 11 ?? data model section 22 should captureEncodingType also include > additional elements to specify the specific values of the parameters > bandwidth, width, height, etc? Framework section 9 says ??Each > Capture Encoding refers to one Media Capture, one Individual Encoding, > and includes the encoding parameter values.?? Refer to conversation > http://www.ietf.org/mail-archive/web/clue/current/msg02526.html > Yes, given what is stated in the framework document, the captureEncodingType should contain both capture parameters, such as the selected switching policy, and encoding parameters, such as the bandwitdh. We provide a possible solution that needs to be further discussed with references to the considerations made in http://www.ietf.org/mail-archive/web/clue/current/msg02526.html. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------000204080702050207020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Mark,

some data model updates are listed below.
Thank you,

Roberta

Il 12/07/2013 21:55, Duckworth, Mark ha scritto:

Here is the list of things I found to be inconsistent.

 

1 – data model section 3 “simultaneous capture sets” should be “simultaneous <<transmission>> sets”

Ok.

 

2 – data model section 10 a media capture can include many spatialInformation elements.  There was some discussion of this back in November.  http://www.ietf.org/mail-archive/web/clue/current/msg02113.html.  I propose we remove the maxOccurs=”unbounded” and have just a single spatialInformation, which is consistent with the framework.

Ok.

 

3 – data model section 10.6.  The framework includes a description attribute only for a Capture Scene, while the data model includes it also for capture scene entries and media captures.  I don’t recall why there is the difference.  Did the group decide we should add a description attribute to capture scene entries and media captures?

We left the description element in capture scene and capture scene entry.
It can be useful in the design, development and testing phases.
It appears as an optional field, however.

 

4 – data model section 10.9 should replace content element with the presentation element, as described in framework section 6.1.1.

 

We have removed the content attribute but we have not modeled yet the presentation attribute by using XML Schema..

5 – both data model and framework should add new information about role attributes/elements after discussing draft-groves-clue-role-clarifications.

 

ToDo.

6 – data model section 10.x add a “view” element as described in framework section 6.1.1

 

ToDo.

7 – data model section 10.11 rename the “dynamic” element to something like “captureMobility” and update description as described in the framework for the “Mobility of Capture” attribute.

 

Ok. We have add both an optional <mobility> element under the definition of the media capture type and the definition of an enumeration type named "mobilityType".

8 – data model section 11.2 has a micPattern element, which is not in the framework.  Did the group decide to add this as an attribute of an audio capture?  I don’t remember such a decision.

Removed - this was an example of an (optional) audio-specific media capture attribute that we discussed on the mailing list in a very old thread with John Leslie (24-10-2012).

 

9 - data model section 12.1 has a nativeAspectRatio element, which is not in the framework.  Did the group decide to add this as an attribute of a video capture?  I don’t remember such a decision.

Removed - It was a media capture attribute proposed in the Romanow's data model draft that we classified as a video-specific attribute.

 

10 – data model section 14.1 the sceneSpace element should be removed.  We already decided to remove the “area of scene” attribute in the framework.

Ok.

 

11 – data model section 22 should captureEncodingType also include additional elements to specify the specific values of the parameters bandwidth, width, height, etc?  Framework section 9 says “Each Capture Encoding refers to one Media Capture, one Individual Encoding, and includes the encoding parameter values.”  Refer to conversation http://www.ietf.org/mail-archive/web/clue/current/msg02526.html

 

Yes, given what is stated in the framework document, the captureEncodingType should contain both capture parameters, such as the selected switching policy, and encoding parameters, such as the bandwitdh. We provide a possible solution that needs to be further discussed with references to the considerations made in
http://www.ietf.org/mail-archive/web/clue/current/msg02526.html.

Regards,

Mark

 

 



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

--------------000204080702050207020605-- From pkyzivat@alum.mit.edu Mon Jul 15 14:57:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109F621E816A for ; Mon, 15 Jul 2013 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X57RFdvKf7Qt for ; Mon, 15 Jul 2013 14:57:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id F1AD221E80FD for ; Mon, 15 Jul 2013 14:57:24 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id 0iHx1m0080xGWP855lxQdj; Mon, 15 Jul 2013 21:57:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 0lxQ1m00D3ZTu2S3YlxQ6S; Mon, 15 Jul 2013 21:57:24 +0000 Message-ID: <51E47043.9010503@alum.mit.edu> Date: Mon, 15 Jul 2013 17:57:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130715182837.20459.92496.idtracker@ietfa.amsl.com> In-Reply-To: <20130715182837.20459.92496.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373925444; bh=bBvYN1SRRytkQakhbhL2qxa+exghvVAkIPUMqOUOqgw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I2gAJB9f/+bLKYPF94hG/QvRrWaCLryciiqZeqWY0BKJj6EDNa2CCx2UzBjaSOMFO RAfegZzq9d4/ee7vDnh1cRDrSKg6A4F4iaU2kQ75vrH6SAPXSQfHC1e7osp5LWmEAw tJou1akiUGeEN+ndxAScOeSYK3JPKplm8U+YOIXecu+b2O5imxN/WCvhU5ZSGZxBly wTJTONNxTtpg2z665FxWecSBtIkbT7KLTAzPKQbsJFAp/YycoL9k1slswwun5bgtTM I3kEp5r1y5eOwULOOnkBpk/begJkU97W7sl9NM+GaAS95gxUYBNWNGANRUPIpm6Xjh hlsiFvjHaD3aQ== Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:57:44 -0000 Re Priority: What does "not subject to priority" mean? I can't conceive of how it can mean anything. With the new coding, priority zero is the highest priority. Isn't that good enough? Thanks, Paul On 7/15/13 2:28 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : An XML Schema for the CLUE data model > Author(s) : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-data-model-schema-00.txt > Pages : 45 > Date : 2013-07-15 > > Abstract: > This document provides an XML schema file for the definition of CLUE > data model types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Mon Jul 15 16:19:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3CE11E8258 for ; Mon, 15 Jul 2013 16:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNbTdeW4s59h for ; Mon, 15 Jul 2013 16:19:10 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id EF55C11E820E for ; Mon, 15 Jul 2013 16:19:09 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 15 Jul 2013 16:19:09 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 15 Jul 2013 16:19:08 -0700 Thread-Topic: New Version Notification for draft-duckworth-clue-switching-example-01.txt Thread-Index: Ac6BsXEsv+RcSMMtQBW07i/cmL7Jpg== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D29D86@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-duckworth-clue-switching-example-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:19:14 -0000 SSBhcG9sb2dpemUgZm9yIG5vdCB5ZXQgc3RhcnRpbmcgZW1haWwgZGlzY3Vzc2lvbnMgYmFzZWQg b24gaXNzdWVzIHdlIGRpc2N1c3NlZCBhdCB0aGUgbGFzdCBpbnRlcmltIG1lZXRpbmcuICBJIHVw ZGF0ZWQgdGhlIGRyYWZ0IHRob3VnaCwgYmFzZWQgb24gb3VyIGRpc2N1c3Npb24gYW5kIHdpdGgg c29tZSBtb3JlIGluZm9ybWF0aW9uIGZyb20gdGhlIG9sZCBkcmFmdHMgb24gc3dpdGNoaW5nIGFu ZCBjb25zdW1lciBsYXlvdXQgZnJvbSB0aGUgU3RvY2tob2xtIGludGVyaW0uDQoNCkkgd2lsbCB0 cnkgdG8gc3RhcnQgc29tZSBtb3JlIGVtYWlsIGRpc2N1c3Npb24gaW4gdGhlIG5leHQgY291cGxl IG9mIGRheXMuDQoNCk1hcmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBNb25kYXksIEp1bHkgMTUsIDIwMTMgNzoxNSBQTQ0KVG86IER1Y2t3b3J0aCwgTWFy aw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdWNrd29ydGgt Y2x1ZS1zd2l0Y2hpbmctZXhhbXBsZS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtZHVja3dvcnRoLWNsdWUtc3dpdGNoaW5nLWV4YW1wbGUtMDEudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hcmsgRHVja3dvcnRoIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1kdWNrd29ydGgtY2x1ZS1zd2l0 Y2hpbmctZXhhbXBsZQ0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgQ0xVRSBTd2l0Y2hpbmcgTWl4 ZXIgRXhhbXBsZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMTUNCkdyb3VwOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMQ0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kdWNrd29ydGgtY2x1ZS1zd2l0 Y2hpbmctZXhhbXBsZS0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kdWNrd29ydGgtY2x1ZS1zd2l0Y2hpbmctZXhhbXBsZQ0KSHRt bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdWNrd29ydGgt Y2x1ZS1zd2l0Y2hpbmctZXhhbXBsZS0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kdWNrd29ydGgtY2x1ZS1zd2l0Y2hpbmctZXhhbXBs ZS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gZXhhbXBsZSBt dWx0aXBvaW50IHVzZSBjYXNlIHNjZW5hcmlvIGZvcg0KICAgQ0xVRS4gIFRoaXMgZXhhbXBsZSB1 c2VzIHRoZSBtZWRpYSBzd2l0Y2hpbmcgdmFyaWV0eSBvZiB0aGUgVG9wby0NCiAgIE1peGVyIFJU UCB0b3BvbG9neS4gIFRoaXMgZXhhbXBsZSBpcyBpbnRlbmRlZCB0byBwcm9tb3RlIGRpc2N1c3Np b24NCiAgIGFib3V0IGhvdyB0byBpbXBsZW1lbnQgaXQgdXNpbmcgdGhlIENMVUUgRnJhbWV3b3Jr LCBhbmQgd2hldGhlciBvcg0KICAgbm90IHRoZSBmcmFtZXdvcmsgYXMgY3VycmVudGx5IGRlZmlu ZWQgaXMgc3VmZmljaWVudCB0byBlbmFibGUgdGhpcw0KICAgdXNlIGNhc2UuDQoNCiAgIFRoaXMg dmVyc2lvbiBpcyBpbmNvbXBsZXRlLCBhbmQgaXMgaW50ZW5kZWQgdG8gcmFpc2UgcXVlc3Rpb25z IGFuZA0KICAgcHJvbXB0IGRpc2N1c3Npb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From Christian.Groves@nteczone.com Mon Jul 15 17:21:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829721E811C for ; Mon, 15 Jul 2013 17:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC--I7ZRMm0D for ; Mon, 15 Jul 2013 17:21:35 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F0D4B21E8084 for ; Mon, 15 Jul 2013 17:21:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAISR5FF20Who/2dsb2JhbAANTYM6wimBKIMXAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiBikAZJCj2sWg2IDmQWTSA Received: from ppp118-209-104-104.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.104]) by ipmail07.adl2.internode.on.net with ESMTP; 16 Jul 2013 09:51:32 +0930 Message-ID: <51E491F2.2030606@nteczone.com> Date: Tue, 16 Jul 2013 10:21:06 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130715182837.20459.92496.idtracker@ietfa.amsl.com> <51E47043.9010503@alum.mit.edu> In-Reply-To: <51E47043.9010503@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:21:36 -0000 Hello Paul, What if some captures are assigned a priority and others aren't? What does an endpoint assume about the one's that aren't assigned a priority? Highest priority? Lowest priority? No priority? "Not subject to priority" really is a formal way of saying don't apply a priority mechanism to this capture. Regards, Christian On 16/07/2013 7:57 AM, Paul Kyzivat wrote: > Re Priority: > > What does "not subject to priority" mean? I can't conceive of how it > can mean anything. With the new coding, priority zero is the highest > priority. Isn't that good enough? > > Thanks, > Paul > > On 7/15/13 2:28 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : An XML Schema for the CLUE data model >> Author(s) : Roberta Presta >> Simon Pietro Romano >> Filename : draft-ietf-clue-data-model-schema-00.txt >> Pages : 45 >> Date : 2013-07-15 >> >> Abstract: >> This document provides an XML schema file for the definition of CLUE >> data model types. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Jul 15 18:30:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D211E8140 for ; Mon, 15 Jul 2013 18:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaLO0yhLEXyn for ; Mon, 15 Jul 2013 18:30:20 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 980D211E8118 for ; Mon, 15 Jul 2013 18:30:19 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta08.westchester.pa.mail.comcast.net with comcast id 0o1k1m00B17dt5G58pWKXC; Tue, 16 Jul 2013 01:30:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 0pWK1m00H3ZTu2S3ZpWKTr; Tue, 16 Jul 2013 01:30:19 +0000 Message-ID: <51E4A22A.5090903@alum.mit.edu> Date: Mon, 15 Jul 2013 21:30:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130715182837.20459.92496.idtracker@ietfa.amsl.com> <51E47043.9010503@alum.mit.edu> <51E491F2.2030606@nteczone.com> In-Reply-To: <51E491F2.2030606@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373938219; bh=dsL7oPqYrwi5uks+KZtmEbmNMGWrSp0hOx7+54GuBK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iOMx5lKZc9zQ3Qima6YOFJ/JdkbxwZcWjgYq80rkCkwm+QbKqcBGyGqJNohSqA4bu k1r5DzXW8AkOAYcSj4MfMDFlEEI7z0cIIu24FFQPFzsixZGT3c5MmB3EcURv6bdKAb KuCF86HrrFmYS3US6S7R2SwYzZRlGHwNkCAmfeXQavpu6qf7DB+3YgV2eYjiFEfNUV LckgLH9Ily4CCpyZO7SVi3iwuLzxOak4LqQ4M7usT88EzK72/RUtgaETRnOc/PtokD qxywg6ncR6r1SM8f5Z05Z4YcfsdW9cU83uw91xyLxL93vkE/zBMSYuZ9RwBxqKapAC Fy+VyW+x1GapA== Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 01:30:25 -0000 On 7/15/13 8:21 PM, Christian Groves wrote: > Hello Paul, > > What if some captures are assigned a priority and others aren't? What > does an endpoint assume about the one's that aren't assigned a priority? > Highest priority? Lowest priority? No priority? "Not subject to > priority" really is a formal way of saying don't apply a priority > mechanism to this capture. Clearly this needs to be defined. My assumption is that there should be a default priority if none is specified. We can discuss whether it should be high or low. My gut says that the default should be highest. Then you only need to bother specifying priority if you want to indicate that some are less important than the rest. Thanks, Paul > Regards, Christian > > On 16/07/2013 7:57 AM, Paul Kyzivat wrote: >> Re Priority: >> >> What does "not subject to priority" mean? I can't conceive of how it >> can mean anything. With the new coding, priority zero is the highest >> priority. Isn't that good enough? >> >> Thanks, >> Paul >> >> On 7/15/13 2:28 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence Working Group of the IETF. >>> >>> Title : An XML Schema for the CLUE data model >>> Author(s) : Roberta Presta >>> Simon Pietro Romano >>> Filename : draft-ietf-clue-data-model-schema-00.txt >>> Pages : 45 >>> Date : 2013-07-15 >>> >>> Abstract: >>> This document provides an XML schema file for the definition of CLUE >>> data model types. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing 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 keith.drage@alcatel-lucent.com Tue Jul 16 07:58:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55521F9B8C; Tue, 16 Jul 2013 07:58:33 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsNPlcex7ima; Tue, 16 Jul 2013 07:58:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14CA21F84D1; Tue, 16 Jul 2013 07:58:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEwPhL020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:58:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEwP2U023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:58:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:58:25 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrA Date: Tue, 16 Jul 2013 14:58:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [clue] FW: Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 14:58:33 -0000 Extensive cross-post do not reply to this email. For information. We do expect participation input from all the listed worki= ng groups (and possibly more). Keith -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: 16 July 2013 15:53 To: avtext@ietf.org Subject: [avtext] Taxonomy (As AVTEXT WG cochair) The latest version of the RTP taxonomy draft has been submitted. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by DISPATCH, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant meeting time discussing the contents= in the AVTEXT meeting in Berlin, so please start raising your issues on th= e AVTEXT list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From internet-drafts@ietf.org Tue Jul 16 09:30:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4589921E808A; Tue, 16 Jul 2013 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8Tg5Ht-3aa1; Tue, 16 Jul 2013 09:30:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6783121E8082; Tue, 16 Jul 2013 09:30:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2013 09:29:34 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:30:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-requirements-04.txt Pages : 14 Date : 2013-07-15 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirement= s-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Mark.Duckworth@polycom.com Tue Jul 16 09:41:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B95821F9BF7 for ; Tue, 16 Jul 2013 09:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM72eyemGNyM for ; Tue, 16 Jul 2013 09:41:51 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A45D821E804D for ; Tue, 16 Jul 2013 09:41:48 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 16 Jul 2013 09:41:47 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 16 Jul 2013 09:41:45 -0700 Thread-Topic: [clue] comments on description of RTP topologies Thread-Index: Ac6BCiPvHtjV6ztRQ5GKRqhcS9WGCgBN4o8Q Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D29F94@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60146DF92@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D601BC9946@CRPMBOXPRD07.polycom.com> <51E36A40.5040404@nteczone.com> In-Reply-To: <51E36A40.5040404@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] comments on description of RTP topologies X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 16:41:55 -0000 Hello Christian, Regarding "Topo-Video-switch-MCU" -=20 I was going by the minutes of the June 2012 meeting. http://www.ietf.org/proceedings/interim/2012/06/07/clue/minutes/minutes-int= erim-2012-clue-2.txt One of the conclusions is: "4) RTP topologies: support per Magnus' presentation: p2p, distributed en= dpoint, 3 types of mixers." Where the 3 types of mixers are: Media Mixer, Media Switching Mixer, and So= urce Projection Mixer. These terms came from Magnus's presentation. http:= //www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-interim-20= 12-clue-2-6.pdf I believe these three types of mixers map to: 1. Media mixers a. Topo-RTCP-terminating-MCU b. Topo-Mixer, Media Mixing variety (3.6.1 of rtp-topologies-update) 2. Media switching mixers - Topo-Mixer, Media Switching variety (3.6.2 of r= tp-topologies-update) 3. Source projection mixers - Source Projecting Middlebox (3.7 of rtp-topol= ogies-update) I believe there was a reason why Topo-Video-switch-MCU was excluded, but I = could be wrong. Maybe it was supposed to be included in the "Media switchi= ng mixers" category from the presentation? If so, I'd like to get clarific= ation about that. Maybe Jonathan, Roni, Magnus or somebody else can explain? Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Sunday, July 14, 2013 11:19 PM > To: clue@ietf.org > Subject: Re: [clue] comments on description of RTP topologies >=20 > Hello Mark, >=20 > I would agree it would be good to be consistent with the topology > terminology between draft-ietf-clue-rtp-mapping and draft-ietf-avtcore-rt= p- > topologies-update. >=20 > With regards for CLUE support of Topo-Video-switch-MCU is this a real iss= ue? > The Advertisement/Configures could describe such a scenario where the > consumer sees a switched view. The actual RTP would be described by SDP? >=20 > Regards, Christian >=20 >=20 > On 12/07/2013 6:05 AM, Duckworth, Mark wrote: > > > > Can anybody answer my questions below? In particular, we aren't aiming > > for CLUE to support Topo-Video-switch-MCU, correct? > > > > Is anybody else interested in clarifying the rtp-mapping document, to > > more explicitly use the same terminology for topologies from > > draft-ietf-avtcore-rtp-topologies-update? (I assume this avtcore > > document will become an RFC) > > > > Thanks, > > Mark > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > > Of *Duckworth, Mark > > *Sent:* Friday, June 14, 2013 10:35 AM > > *To:* clue@ietf.org > > *Subject:* [clue] comments on description of RTP topologies > > > > This is regarding section 3. RTP topologies for CLUE, in > > draft-ietf-clue-rtp-mapping-00. > > > > I'm having difficulty relating the topologies described here to the > > terminology described in draft-ietf-avtcore-rtp-topologies-update-00. > > There doesn't seem to be a clean mapping, so I'd like to clarify this > > and make it cleaner, using the same terminology. > > > > From the beginning of section 3: > > > > "For telepresence, the relevant topologies include point-to-point, as > > well as media mixers, media- switching mixers, and source-projection > > mixers." > > > > So for these four categories, I would like to understand how they map > > to the topologies described in > > draft-ietf-avtcore-rtp-topologies-update. The following list describes > > how I think the two documents relate. Do I understand this correctly? > > Can we make this more explicit in the CLUE document, to list the CLUE > > topologies directly using terminology from the rtp-topologies-update > > document, so we don't have to map it to a new set of CLUE terminology? > > > > 1.point-to-point. This includes: > > > > a.Topo-Point-to-Point > > > > b.Topo-PtP-Translator - not sure if this is meant to be included or not= ? > > > > c.Back to back RTP sessions - not sure if this is meant to be included > > or not? > > > > 2.media mixers. This includes: > > > > a.Topo-RTCP-terminating-MCU > > > > b.Topo-Mixer, Media Mixing variety (3.6.1 of rtp-topologies-update) > > > > 3.media switching mixers. This includes: > > > > a.Topo-Mixer, Media Switching variety (3.6.2 of rtp-topologies-update) > > > > 4.source projection mixers. This includes: > > > > a.Source Projecting Middlebox (3.7 of rtp-topologies-update) > > > > We should also add De-composite Endpoint (3.10 of > > rtp-topologies-update), as we agreed in the June 2012 interim meeting. > > > > I believe we also agreed CLUE is not attempting to support > > Topo-Video-switch-MCU, so I suggest we remove reference to this one. > > The document refers to this as if CLUE supports it, which I think is > > not the case. > > > > I have a related question in avtcore, asking if source projection is > > intended to be a variety of Topo-Mixer. > > > > Mark Duckworth > > > > > > > > _______________________________________________ > > 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 Tue Jul 16 12:09:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629DB21E80BA for ; Tue, 16 Jul 2013 12:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBB7+gBK9zZo for ; Tue, 16 Jul 2013 12:09:11 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4B86F21E80AA for ; Tue, 16 Jul 2013 12:09:10 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 16 Jul 2013 12:09:09 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 16 Jul 2013 12:09:08 -0700 Thread-Topic: Ticket #34 update framework examples Thread-Index: Ac6CV1rRtK/yEdvnTiSGmgRpdocsng== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A08F@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601D2A08FCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Ticket #34 update framework examples X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 19:09:16 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A08FCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I updated the examples in the framework-11 draft. I cleaned up the media c= apture and encoding related attributes in the examples, to make them consis= tent with the rest of the framework. I think the current level of detail i= s needed to make sense of the examples, so I didn't change that. Please review, and let me know if you have any suggestions to improve the e= xamples. Thanks, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A08FCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I updated the ex= amples in the framework-11 draft.  I cleaned up the media capture and = encoding related attributes in the examples, to make them consistent with t= he rest of the framework.  I think the current level of detail is need= ed to make sense of the examples, so I didn’t change that.=

 

Please r= eview, and let me know if you have any suggestions to improve the examples.=

 

Thanks,
Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A08FCRPMBOXPRD07pol_-- From mary.ietf.barnes@gmail.com Tue Jul 16 13:08:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9229621F99E3 for ; Tue, 16 Jul 2013 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k85YGFiclDN for ; Tue, 16 Jul 2013 13:07:59 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA3E21F99E2 for ; Tue, 16 Jul 2013 13:07:59 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so2556689qab.1 for ; Tue, 16 Jul 2013 13:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=J3ePZVIiFB1vitoer0RczwAFRIUDiFP4SRoPZxAn0wQ=; b=UEyZgTzRxK9oqmCBm9ejM+79wgZsckvjqO4oPF+3gh48AdTx+sfZ8XRa3sqJeiydFu vsfbOxMBGzHckUWvWt0haWkpKBVb1SErhrOfiDiViT+RTfHG4Vz4Adm5Q+BYnmEc5qpK fJD2j/ev0oDpOqzZN8CyzLFUjRLdeXgyj8ZuGlRQD45eh7/5DRvej7YQuMJVXNnWXqvV 9NuLZdGqstjQirKFyEtspOdxcYP6dFnLdABbLXciNqXwsCtGJrTOrU8rZC+cXc1nshrm 5kR2MtUkH+4Fei5rK42xpKoun0c2LdTZH+sV9MT8k3vdYeZEwB6IOtzx0rNHuayEzuvg 1R8Q== MIME-Version: 1.0 X-Received: by 10.229.242.132 with SMTP id li4mr1082234qcb.3.1374005278322; Tue, 16 Jul 2013 13:07:58 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 16 Jul 2013 13:07:58 -0700 (PDT) In-Reply-To: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2013 15:07:58 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b676b4488d4db04e1a68824 Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:08:00 -0000 --047d7b676b4488d4db04e1a68824 Content-Type: text/plain; charset=ISO-8859-1 There really were no changes other than to refresh this draft. I was going to extend the security section with more detail, but I really can't add much more detail without referencing things that are defined in the framework. So, I think the next step is for me to work with Mark on the security for the framework. There are some open issues identified in the appendix of this document that we need to figure out whether they are issues that need resolution for this document. I will open issues in the tracker and we can discuss each one and perhaps make some decisions before Berlin. We also need to consider whether the current framework meets these requirements. If some requirements are not met, we need to decide whether it's because they'll be met by the solution documents or won't be met at all. In which case, we need to decide whether we actually need them for the solution. Regards, Mary. On Tue, Jul 16, 2013 at 11:29 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple streams for > tElepresence Working Group of the IETF. > > Title : Requirements for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : draft-ietf-clue-telepresence-requirements-04.txt > Pages : 14 > Date : 2013-07-15 > > 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 datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --047d7b676b4488d4db04e1a68824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There really were no changes other than to refresh this dr= aft. =A0I was going to extend the security section with more detail, but I = really can't add much more detail without referencing things that are d= efined in the framework. =A0So, I think the next step is for me to work wit= h Mark on the security for the framework. =A0

There are some open issues identified in the appendix of thi= s document =A0that we need to figure out whether they are issues that need = resolution for this document. =A0 I will open issues in the tracker and we = can discuss each one and perhaps make some decisions before Berlin.=A0

We also need to consider whether the current framework = meets these requirements. =A0If some requirements are not met, we need to d= ecide whether it's because they'll be met by the solution documents= or won't be met at all. In which case, we need to decide whether we ac= tually need them for the solution.

Regards,
Mary.=A0


On Tue, Jul 16, 2013 at 11:2= 9 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the ControLling mUltiple streams for tElepr= esence Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for Telepresence M= ulti-Streams
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Allyn Romanow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stephen Botzko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mary Barnes
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-clue-telepresence-requ= irements-04.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-15

Abstract:
=A0 =A0This memo discusses the requirements for a specification that enable= s
=A0 =A0telepresence interoperability, by describing the relationship betwee= n
=A0 =A0multiple RTP streams. =A0In addition, the problem statement and
=A0 =A0definitions are also covered herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-c= lue-telepresence-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-telep= resence-requirements-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-clue-telepresence-requirements-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--047d7b676b4488d4db04e1a68824-- From mary.ietf.barnes@gmail.com Tue Jul 16 13:32:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6F621F9C6E for ; Tue, 16 Jul 2013 13:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.755 X-Spam-Level: X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVbQM5-hoM6z for ; Tue, 16 Jul 2013 13:32:36 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 03A3C21F9C68 for ; Tue, 16 Jul 2013 13:32:35 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so2543534qak.7 for ; Tue, 16 Jul 2013 13:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QBNu3v9s6P2mIJRzcI8HxRflJofwuKLEbWksMpqPLPg=; b=FA/rhLkTPpPppb4ti+JrAD/gdw6qJ7irc4BeB4rIyazNiilngtmWARogcbjgL5qxFO XhxvCSxnQrBI3WrUOcUrZm7KClHxYH6Pep62yDS+GQNTjlSCRd7SrIBy9eBLOLw/bKCq eIuVQknH848gR/9ix2It3wjhhx4umf46KDeX/S+7InVdCVXNIqwRVaPhYasYz+8qeZm2 ng2PlHga1d3brObFnVdWyMjRrEgcs5y6ULNceOo4nc+wmzaRiAjJ9a5T32Uu0aLPi2B9 QdBsyVaMOwyk1yTmXbGTlbuOw1V3i7D/sJrSkYQDphem8bp7OjCaEkn2qFLOkEX4Z1tj HnbA== MIME-Version: 1.0 X-Received: by 10.49.95.97 with SMTP id dj1mr4494384qeb.46.1374006755484; Tue, 16 Jul 2013 13:32:35 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 16 Jul 2013 13:32:35 -0700 (PDT) In-Reply-To: <51E447C8.1000701@nostrum.com> References: <51E447C8.1000701@nostrum.com> Date: Tue, 16 Jul 2013 15:32:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b6da616946d6d04e1a6e001 Subject: [clue] Fwd: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 20:32:36 -0000 --047d7b6da616946d6d04e1a6e001 Content-Type: text/plain; charset=ISO-8859-1 CLUE folks should also take a look at this document. Mary. ---------- Forwarded message ---------- From: Adam Roach Date: Mon, Jul 15, 2013 at 2:04 PM Subject: [MMUSIC] Unified Plan for SDP Handling To: "mmusic@ietf.org" Cc: "rtcweb@ietf.org" [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward. Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points. I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to. Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions. Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting. Document link: http://www.ietf.org/id/draft-**roach-mmusic-unified-plan-00.**txt /a ______________________________**_________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/**listinfo/mmusic --047d7b6da616946d6d04e1a6e001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CLUE folks should also take a look at this document. =A0 = =A0

Mary.

---------- F= orwarded message ----------
From: Adam Roa= ch <adam@nostr= um.com>
Date: Mon, Jul 15, 2013 at 2:04 PM
Subject: [MMUSIC] Unified Plan for SD= P Handling
To: "mmusic@ietf.org<= /a>" <mmusic@ietf.org> Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>


[Cros= s-posting to RTCWEB; follow-ups to MMUSIC, please]

After significant work, Justin, Martin and I have managed to produce a comp= romise plan that provides a high degree of interoperability with existing d= evices (and future non-WebRTC devices) while not being excessively onerous = for WebRTC implementations or applications that use them. It's been a t= ricky balancing act, but I think we've found a good mix between the two= that can form a solid basis for the working group to move forward.

Rather than summarize the key points of the document in this email, I direc= t interested parties to section 2 of the document, which summarizes the key= aspects of the plan in eight relatively concise bullet points.

I apologize for the late publication date of this document -- there's a= ctually been a lot more work put into coming up with a unified draft than I= originally anticipated, and the production of this document took at least = two weeks longer than I expected it to.

Note that this document is intended to be a plan for the work to be done in= this area, and not a specification in itself. The intention is that its co= ntents are used as the basis for work in several other drafts -- some new, = some not -- that form the corpus of work necessary for RTCWEB (and potentia= lly CLUE) to move forward. Except in rare cases, the document does not atte= mpt to explicitly call out venues or documents for such work, as we (or, at= the very least, I) anticipate guidance from the various working group chai= rs to assist in such decisions.

Comments prior to Berlin would be very helpful, although this will clearly = be a point of significant discussion at the face-to-face meeting.

Document link:

http://www.ietf.org/id/draft-roach-mmusic-unified-p= lan-00.txt

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

--047d7b6da616946d6d04e1a6e001-- From Mark.Duckworth@polycom.com Tue Jul 16 15:17:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1124C21F938E for ; Tue, 16 Jul 2013 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llrzJw3mAAb3 for ; Tue, 16 Jul 2013 15:17:20 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B3E9D21F9C68 for ; Tue, 16 Jul 2013 15:17:20 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 16 Jul 2013 15:17:20 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 16 Jul 2013 15:17:18 -0700 Thread-Topic: [clue] Ticket #35 consistency of data model and framework Thread-Index: Ac6Bk4otdSlSm+FzS4q3VXiO7eK3twA2157A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A1CB@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9DD0@CRPMBOXPRD07.polycom.com> <51E450AC.1080102@unina.it> In-Reply-To: <51E450AC.1080102@unina.it> 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_49E45C59CA48264997FEBFB29B6BC2D601D2A1CBCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] Ticket #35 consistency of data model and framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 22:17:25 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A1CBCRPMBOXPRD07pol_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0YSwNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgdG8gdGhlIGRhdGEgbW9kZWwuDQoN Cjx4czpzZXF1ZW5jZT4NCiAgPHhzOmVsZW1lbnQgbmFtZT0ic3BhdGlhbEluZm9ybWF0aW9uIiB0 eXBlPSJ0bnM6c3BhdGlhbEluZm9ybWF0aW9uVHlwZSIvPg0KPC94czpzZXF1ZW5jZT4NCg0KU2hv dWxkIHdlIHJlbW92ZSB0aGUgPHhzOnNlcXVlbmNlPiBwYXJ0IG5vdz8NCg0KSSBhZGRlZCDigJxk ZXNjcmlwdGlvbuKAnSBhdHRyaWJ1dGUgaW4gdGhlIGZyYW1ld29yayB0byBiZSBjb25zaXN0ZW50 IHdpdGggdGhlIGRhdGEgbW9kZWwuDQoNClRoZSBuZXcg4oCcY2FwdHVyZUVuY29kaW5nVHlwZeKA nSBsb29rcyBsaWtlIGEgZ29vZCBzdGFydC4NClR5cG86DQo8IS0tIEVOQ09ESU5HIFBBUkFNRVRF UlMgVFlQRSAtLT4NCjx4czpjb21wbGV4VHlwZSBuYW1lPSJjYXB0dXJlUGFyYW1ldGVyc1R5cGUi Pg0KDQpTb21lIOKAnHhzOmludGVnZXLigJ0gdmFsdWVzIHdlcmUgY2hhbmdlZCB0byBib3VuZGVk IHR5cGVzICh0aGFua3MhKSBpbiBzZWN0aW9uIDMsIGJ1dCBub3QgY2hhbmdlZCBpbiB0aGUgWE1M IHNuaXBwZXRzIHRoYXQgY29tZSBsYXRlciBpbiB0aGUgZG9jdW1lbnQuDQoNCk1hcmsNCg0KDQpG cm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnRhIFByZXN0YQ0KU2VudDogTW9uZGF5LCBKdWx5IDE1LCAyMDEz IDM6NDMgUE0NClRvOiBjbHVlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NsdWVdIFRpY2tldCAj MzUgY29uc2lzdGVuY3kgb2YgZGF0YSBtb2RlbCBhbmQgZnJhbWV3b3JrDQoNCkhpIE1hcmssDQoN CnNvbWUgZGF0YSBtb2RlbCB1cGRhdGVzIGFyZSBsaXN0ZWQgYmVsb3cuDQpUaGFuayB5b3UsDQoN ClJvYmVydGENCg0KSWwgMTIvMDcvMjAxMyAyMTo1NSwgRHVja3dvcnRoLCBNYXJrIGhhIHNjcml0 dG86DQpIZXJlIGlzIHRoZSBsaXN0IG9mIHRoaW5ncyBJIGZvdW5kIHRvIGJlIGluY29uc2lzdGVu dC4NCg0KMSDDouKCrOKAnCBkYXRhIG1vZGVsIHNlY3Rpb24gMyDDouKCrMWTc2ltdWx0YW5lb3Vz IGNhcHR1cmUgc2V0c8Oi4oKswp0gc2hvdWxkIGJlIMOi4oKsxZNzaW11bHRhbmVvdXMgPDx0cmFu c21pc3Npb24+PiBzZXRzw6LigqzCnQ0KT2suDQoNCg0KMiDDouKCrOKAnCBkYXRhIG1vZGVsIHNl Y3Rpb24gMTAgYSBtZWRpYSBjYXB0dXJlIGNhbiBpbmNsdWRlIG1hbnkgc3BhdGlhbEluZm9ybWF0 aW9uIGVsZW1lbnRzLiAgVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBvZiB0aGlzIGJhY2sgaW4g Tm92ZW1iZXIuICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJy ZW50L21zZzAyMTEzLmh0bWwuICBJIHByb3Bvc2Ugd2UgcmVtb3ZlIHRoZSBtYXhPY2N1cnM9w6Li gqzCnXVuYm91bmRlZMOi4oKswp0gYW5kIGhhdmUganVzdCBhIHNpbmdsZSBzcGF0aWFsSW5mb3Jt YXRpb24sIHdoaWNoIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZnJhbWV3b3JrLg0KT2suDQoNCg0K MyDDouKCrOKAnCBkYXRhIG1vZGVsIHNlY3Rpb24gMTAuNi4gIFRoZSBmcmFtZXdvcmsgaW5jbHVk ZXMgYSBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUgb25seSBmb3IgYSBDYXB0dXJlIFNjZW5lLCB3aGls ZSB0aGUgZGF0YSBtb2RlbCBpbmNsdWRlcyBpdCBhbHNvIGZvciBjYXB0dXJlIHNjZW5lIGVudHJp ZXMgYW5kIG1lZGlhIGNhcHR1cmVzLiAgSSBkb27DouKCrOKEonQgcmVjYWxsIHdoeSB0aGVyZSBp cyB0aGUgZGlmZmVyZW5jZS4gIERpZCB0aGUgZ3JvdXAgZGVjaWRlIHdlIHNob3VsZCBhZGQgYSBk ZXNjcmlwdGlvbiBhdHRyaWJ1dGUgdG8gY2FwdHVyZSBzY2VuZSBlbnRyaWVzIGFuZCBtZWRpYSBj YXB0dXJlcz8NCldlIGxlZnQgdGhlIGRlc2NyaXB0aW9uIGVsZW1lbnQgaW4gY2FwdHVyZSBzY2Vu ZSBhbmQgY2FwdHVyZSBzY2VuZSBlbnRyeS4NCkl0IGNhbiBiZSB1c2VmdWwgaW4gdGhlIGRlc2ln biwgZGV2ZWxvcG1lbnQgYW5kIHRlc3RpbmcgcGhhc2VzLg0KSXQgYXBwZWFycyBhcyBhbiBvcHRp b25hbCBmaWVsZCwgaG93ZXZlci4NCg0KDQo0IMOi4oKs4oCcIGRhdGEgbW9kZWwgc2VjdGlvbiAx MC45IHNob3VsZCByZXBsYWNlIGNvbnRlbnQgZWxlbWVudCB3aXRoIHRoZSBwcmVzZW50YXRpb24g ZWxlbWVudCwgYXMgZGVzY3JpYmVkIGluIGZyYW1ld29yayBzZWN0aW9uIDYuMS4xLg0KDQpXZSBo YXZlIHJlbW92ZWQgdGhlIGNvbnRlbnQgYXR0cmlidXRlIGJ1dCB3ZSBoYXZlIG5vdCBtb2RlbGVk IHlldCB0aGUgcHJlc2VudGF0aW9uIGF0dHJpYnV0ZSBieSB1c2luZyBYTUwgU2NoZW1hLi4NCg0K NSDDouKCrOKAnCBib3RoIGRhdGEgbW9kZWwgYW5kIGZyYW1ld29yayBzaG91bGQgYWRkIG5ldyBp bmZvcm1hdGlvbiBhYm91dCByb2xlIGF0dHJpYnV0ZXMvZWxlbWVudHMgYWZ0ZXIgZGlzY3Vzc2lu ZyBkcmFmdC1ncm92ZXMtY2x1ZS1yb2xlLWNsYXJpZmljYXRpb25zLg0KDQpUb0RvLg0KDQo2IMOi 4oKs4oCcIGRhdGEgbW9kZWwgc2VjdGlvbiAxMC54IGFkZCBhIMOi4oKsxZN2aWV3w6LigqzCnSBl bGVtZW50IGFzIGRlc2NyaWJlZCBpbiBmcmFtZXdvcmsgc2VjdGlvbiA2LjEuMQ0KDQpUb0RvLg0K DQo3IMOi4oKs4oCcIGRhdGEgbW9kZWwgc2VjdGlvbiAxMC4xMSByZW5hbWUgdGhlIMOi4oKsxZNk eW5hbWljw6LigqzCnSBlbGVtZW50IHRvIHNvbWV0aGluZyBsaWtlIMOi4oKsxZNjYXB0dXJlTW9i aWxpdHnDouKCrMKdIGFuZCB1cGRhdGUgZGVzY3JpcHRpb24gYXMgZGVzY3JpYmVkIGluIHRoZSBm cmFtZXdvcmsgZm9yIHRoZSDDouKCrMWTTW9iaWxpdHkgb2YgQ2FwdHVyZcOi4oKswp0gYXR0cmli dXRlLg0KDQpPay4gV2UgaGF2ZSBhZGQgYm90aCBhbiBvcHRpb25hbCA8bW9iaWxpdHk+IGVsZW1l bnQgdW5kZXIgdGhlIGRlZmluaXRpb24gb2YgdGhlIG1lZGlhIGNhcHR1cmUgdHlwZSBhbmQgdGhl IGRlZmluaXRpb24gb2YgYW4gZW51bWVyYXRpb24gdHlwZSBuYW1lZCAibW9iaWxpdHlUeXBlIi4N Cg0KOCDDouKCrOKAnCBkYXRhIG1vZGVsIHNlY3Rpb24gMTEuMiBoYXMgYSBtaWNQYXR0ZXJuIGVs ZW1lbnQsIHdoaWNoIGlzIG5vdCBpbiB0aGUgZnJhbWV3b3JrLiAgRGlkIHRoZSBncm91cCBkZWNp ZGUgdG8gYWRkIHRoaXMgYXMgYW4gYXR0cmlidXRlIG9mIGFuIGF1ZGlvIGNhcHR1cmU/ICBJIGRv bsOi4oKs4oSidCByZW1lbWJlciBzdWNoIGEgZGVjaXNpb24uDQpSZW1vdmVkIC0gdGhpcyB3YXMg YW4gZXhhbXBsZSBvZiBhbiAob3B0aW9uYWwpIGF1ZGlvLXNwZWNpZmljIG1lZGlhIGNhcHR1cmUg YXR0cmlidXRlIHRoYXQgd2UgZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgaW4gYSB2ZXJ5 IG9sZCB0aHJlYWQgd2l0aCBKb2huIExlc2xpZSAoMjQtMTAtMjAxMikuDQoNCg0KOSAtIGRhdGEg bW9kZWwgc2VjdGlvbiAxMi4xIGhhcyBhIG5hdGl2ZUFzcGVjdFJhdGlvIGVsZW1lbnQsIHdoaWNo IGlzIG5vdCBpbiB0aGUgZnJhbWV3b3JrLiAgRGlkIHRoZSBncm91cCBkZWNpZGUgdG8gYWRkIHRo aXMgYXMgYW4gYXR0cmlidXRlIG9mIGEgdmlkZW8gY2FwdHVyZT8gIEkgZG9uw6LigqzihKJ0IHJl bWVtYmVyIHN1Y2ggYSBkZWNpc2lvbi4NClJlbW92ZWQgLSBJdCB3YXMgYSBtZWRpYSBjYXB0dXJl IGF0dHJpYnV0ZSBwcm9wb3NlZCBpbiB0aGUgUm9tYW5vdydzIGRhdGEgbW9kZWwgZHJhZnQgdGhh dCB3ZSBjbGFzc2lmaWVkIGFzIGEgdmlkZW8tc3BlY2lmaWMgYXR0cmlidXRlLg0KDQoNCjEwIMOi 4oKs4oCcIGRhdGEgbW9kZWwgc2VjdGlvbiAxNC4xIHRoZSBzY2VuZVNwYWNlIGVsZW1lbnQgc2hv dWxkIGJlIHJlbW92ZWQuICBXZSBhbHJlYWR5IGRlY2lkZWQgdG8gcmVtb3ZlIHRoZSDDouKCrMWT YXJlYSBvZiBzY2VuZcOi4oKswp0gYXR0cmlidXRlIGluIHRoZSBmcmFtZXdvcmsuDQpPay4NCg0K DQoxMSDDouKCrOKAnCBkYXRhIG1vZGVsIHNlY3Rpb24gMjIgc2hvdWxkIGNhcHR1cmVFbmNvZGlu Z1R5cGUgYWxzbyBpbmNsdWRlIGFkZGl0aW9uYWwgZWxlbWVudHMgdG8gc3BlY2lmeSB0aGUgc3Bl Y2lmaWMgdmFsdWVzIG9mIHRoZSBwYXJhbWV0ZXJzIGJhbmR3aWR0aCwgd2lkdGgsIGhlaWdodCwg ZXRjPyAgRnJhbWV3b3JrIHNlY3Rpb24gOSBzYXlzIMOi4oKsxZNFYWNoIENhcHR1cmUgRW5jb2Rp bmcgcmVmZXJzIHRvIG9uZSBNZWRpYSBDYXB0dXJlLCBvbmUgSW5kaXZpZHVhbCBFbmNvZGluZywg YW5kIGluY2x1ZGVzIHRoZSBlbmNvZGluZyBwYXJhbWV0ZXIgdmFsdWVzLsOi4oKswp0gIFJlZmVy IHRvIGNvbnZlcnNhdGlvbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1 ZS9jdXJyZW50L21zZzAyNTI2Lmh0bWwNCg0KWWVzLCBnaXZlbiB3aGF0IGlzIHN0YXRlZCBpbiB0 aGUgZnJhbWV3b3JrIGRvY3VtZW50LCB0aGUgY2FwdHVyZUVuY29kaW5nVHlwZSBzaG91bGQgY29u dGFpbiBib3RoIGNhcHR1cmUgcGFyYW1ldGVycywgc3VjaCBhcyB0aGUgc2VsZWN0ZWQgc3dpdGNo aW5nIHBvbGljeSwgYW5kIGVuY29kaW5nIHBhcmFtZXRlcnMsIHN1Y2ggYXMgdGhlIGJhbmR3aXRk aC4gV2UgcHJvdmlkZSBhIHBvc3NpYmxlIHNvbHV0aW9uIHRoYXQgbmVlZHMgdG8gYmUgZnVydGhl ciBkaXNjdXNzZWQgd2l0aCByZWZlcmVuY2VzIHRvIHRoZSBjb25zaWRlcmF0aW9ucyBtYWRlIGlu DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJyZW50L21zZzAy NTI2Lmh0bWwuDQoNClJlZ2FyZHMsDQpNYXJrDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpjbHVlIG1haWxpbmcgbGlzdA0KDQpj bHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A1CBCRPMBOXPRD07pol_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0KLyogRm9udCBE ZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9z ZS0xOjIgNyA0IDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb3Vy aWVyOw0KCXBhbm9zZS0xOjIgNyA0IDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAx MSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hp dGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGkgUm9i ZXJ0YSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5UaGFua3MgZm9yIHRoZSB1cGRhdGVzIHRvIHRoZSBkYXRhIG1vZGVs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjp3aW5kb3d0ZXh0Jz4mbHQ7eHM6c2VxdWVuY2Um Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1h dXRvc3BhY2U6bm9uZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOndpbmRvd3RleHQnPsKgICZsdDt4czplbGVtZW50IG5hbWU9JnF1b3Q7c3Bh dGlhbEluZm9ybWF0aW9uJnF1b3Q7IHR5cGU9JnF1b3Q7dG5zOnNwYXRpYWxJbmZvcm1hdGlvblR5 cGUmcXVvdDsvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOndpbmRv d3RleHQnPiZsdDsveHM6c2VxdWVuY2UmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ U2hvdWxkIHdlIHJlbW92ZSB0aGUgJmx0O3hzOnNlcXVlbmNlJmd0OyBwYXJ0IG5vdz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIGFkZGVkIOKAnGRlc2NyaXB0aW9u4oCdIGF0dHJpYnV0 ZSBpbiB0aGUgZnJhbWV3b3JrIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGF0YSBtb2RlbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgbmV3IOKAnGNhcHR1cmVFbmNvZGluZ1R5 cGXigJ0gbG9va3MgbGlrZSBhIGdvb2Qgc3RhcnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VHlwbzo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpub25l Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OndpbmRvd3RleHQnPiZsdDshLS0gRU5DT0RJTkcgUEFSQU1FVEVSUyBUWVBFIC0tJmd0OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjp3aW5kb3d0ZXh0Jz4mbHQ7eHM6Y29t cGxleFR5cGUgbmFtZT0mcXVvdDtjYXB0dXJlUGFyYW1ldGVyc1R5cGUmcXVvdDsmZ3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5Tb21lIOKAnHhzOmludGVnZXLigJ0gdmFsdWVzIHdlcmUgY2hhbmdlZCB0byBib3VuZGVkIHR5 cGVzICh0aGFua3MhKSBpbiBzZWN0aW9uIDMsIGJ1dCBub3QgY2hhbmdlZCBpbiB0aGUgWE1MIHNu aXBwZXRzIHRoYXQgY29tZSBsYXRlciBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+TWFyazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4 dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gY2x1ZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2Yg PC9iPlJvYmVydGEgUHJlc3RhPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTUsIDIwMTMg Mzo0MyBQTTxicj48Yj5Ubzo8L2I+IGNsdWVAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbY2x1ZV0gVGlja2V0ICMzNSBjb25zaXN0ZW5jeSBvZiBkYXRhIG1vZGVsIGFuZCBmcmFtZXdv cms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgTWFyayw8 YnI+PGJyPnNvbWUgZGF0YSBtb2RlbCB1cGRhdGVzIGFyZSBsaXN0ZWQgYmVsb3cuPGJyPlRoYW5r IHlvdSw8YnI+PGJyPlJvYmVydGE8YnI+PGJyPklsIDEyLzA3LzIwMTMgMjE6NTUsIER1Y2t3b3J0 aCwgTWFyayBoYSBzY3JpdHRvOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxl PSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1h bD5IZXJlIGlzIHRoZSBsaXN0IG9mIHRoaW5ncyBJIGZvdW5kIHRvIGJlIGluY29uc2lzdGVudC48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjEgw6LigqzigJwgZGF0YSBtb2RlbCBzZWN0aW9uIDMgw6LigqzFk3Np bXVsdGFuZW91cyBjYXB0dXJlIHNldHPDouKCrMKdIHNob3VsZCBiZSDDouKCrMWTc2ltdWx0YW5l b3VzICZsdDsmbHQ7dHJhbnNtaXNzaW9uJmd0OyZndDsgc2V0c8Oi4oKswp08bzpwPjwvbzpwPjwv cD48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPk9rLjxicj48YnI+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+MiDDouKCrOKAnCBkYXRhIG1vZGVsIHNlY3Rpb24gMTAg YSBtZWRpYSBjYXB0dXJlIGNhbiBpbmNsdWRlIG1hbnkgc3BhdGlhbEluZm9ybWF0aW9uIGVsZW1l bnRzLiZuYnNwOyBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9mIHRoaXMgYmFjayBpbiBOb3Zl bWJlci4mbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2NsdWUvY3VycmVudC9tc2cwMjExMy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvY2x1ZS9jdXJyZW50L21zZzAyMTEzLmh0bWw8L2E+LiZuYnNwOyBJIHByb3Bvc2Ug d2UgcmVtb3ZlIHRoZSBtYXhPY2N1cnM9w6LigqzCnXVuYm91bmRlZMOi4oKswp0gYW5kIGhhdmUg anVzdCBhIHNpbmdsZSBzcGF0aWFsSW5mb3JtYXRpb24sIHdoaWNoIGlzIGNvbnNpc3RlbnQgd2l0 aCB0aGUgZnJhbWV3b3JrLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiJz5Pay48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjMgw6LigqzigJwgZGF0YSBt b2RlbCBzZWN0aW9uIDEwLjYuJm5ic3A7IFRoZSBmcmFtZXdvcmsgaW5jbHVkZXMgYSBkZXNjcmlw dGlvbiBhdHRyaWJ1dGUgb25seSBmb3IgYSBDYXB0dXJlIFNjZW5lLCB3aGlsZSB0aGUgZGF0YSBt b2RlbCBpbmNsdWRlcyBpdCBhbHNvIGZvciBjYXB0dXJlIHNjZW5lIGVudHJpZXMgYW5kIG1lZGlh IGNhcHR1cmVzLiZuYnNwOyBJIGRvbsOi4oKs4oSidCByZWNhbGwgd2h5IHRoZXJlIGlzIHRoZSBk aWZmZXJlbmNlLiZuYnNwOyBEaWQgdGhlIGdyb3VwIGRlY2lkZSB3ZSBzaG91bGQgYWRkIGEgZGVz Y3JpcHRpb24gYXR0cmlidXRlIHRvIGNhcHR1cmUgc2NlbmUgZW50cmllcyBhbmQgbWVkaWEgY2Fw dHVyZXM/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPldlIGxl ZnQgdGhlIGRlc2NyaXB0aW9uIGVsZW1lbnQgaW4gY2FwdHVyZSBzY2VuZSBhbmQgY2FwdHVyZSBz Y2VuZSBlbnRyeS4gPGJyPkl0IGNhbiBiZSB1c2VmdWwgaW4gdGhlIGRlc2lnbiwgZGV2ZWxvcG1l bnQgYW5kIHRlc3RpbmcgcGhhc2VzLjxicj5JdCBhcHBlYXJzIGFzIGFuIG9wdGlvbmFsIGZpZWxk LCBob3dldmVyLiA8YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjQgw6LigqzigJwgZGF0 YSBtb2RlbCBzZWN0aW9uIDEwLjkgc2hvdWxkIHJlcGxhY2UgY29udGVudCBlbGVtZW50IHdpdGgg dGhlIHByZXNlbnRhdGlvbiBlbGVtZW50LCBhcyBkZXNjcmliZWQgaW4gZnJhbWV3b3JrIHNlY3Rp b24gNi4xLjEuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz5XZSBoYXZlIHJlbW92ZWQgdGhl IGNvbnRlbnQgYXR0cmlidXRlIGJ1dCB3ZSBoYXZlIG5vdCBtb2RlbGVkIHlldCB0aGUgcHJlc2Vu dGF0aW9uIGF0dHJpYnV0ZSBieSB1c2luZyBYTUwgU2NoZW1hLi48YnI+PGJyPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+NSDDouKCrOKAnCBib3RoIGRhdGEgbW9kZWwg YW5kIGZyYW1ld29yayBzaG91bGQgYWRkIG5ldyBpbmZvcm1hdGlvbiBhYm91dCByb2xlIGF0dHJp YnV0ZXMvZWxlbWVudHMgYWZ0ZXIgZGlzY3Vzc2luZyBkcmFmdC1ncm92ZXMtY2x1ZS1yb2xlLWNs YXJpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+VG9Eby48YnI+PGJyPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+NiDDouKCrOKAnCBkYXRhIG1v ZGVsIHNlY3Rpb24gMTAueCBhZGQgYSDDouKCrMWTdmlld8Oi4oKswp0gZWxlbWVudCBhcyBkZXNj cmliZWQgaW4gZnJhbWV3b3JrIHNlY3Rpb24gNi4xLjE8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiInPlRvRG8uPGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs Pjcgw6LigqzigJwgZGF0YSBtb2RlbCBzZWN0aW9uIDEwLjExIHJlbmFtZSB0aGUgw6LigqzFk2R5 bmFtaWPDouKCrMKdIGVsZW1lbnQgdG8gc29tZXRoaW5nIGxpa2Ugw6LigqzFk2NhcHR1cmVNb2Jp bGl0ecOi4oKswp0gYW5kIHVwZGF0ZSBkZXNjcmlwdGlvbiBhcyBkZXNjcmliZWQgaW4gdGhlIGZy YW1ld29yayBmb3IgdGhlIMOi4oKsxZNNb2JpbGl0eSBvZiBDYXB0dXJlw6LigqzCnSBhdHRyaWJ1 dGUuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz5Pay4gV2UgaGF2ZSBhZGQgYm90aCBhbiBv cHRpb25hbCAmbHQ7bW9iaWxpdHkmZ3Q7IGVsZW1lbnQgdW5kZXIgdGhlIGRlZmluaXRpb24gb2Yg dGhlIG1lZGlhIGNhcHR1cmUgdHlwZSBhbmQgdGhlIGRlZmluaXRpb24gb2YgYW4gZW51bWVyYXRp b24gdHlwZSBuYW1lZCAmcXVvdDttb2JpbGl0eVR5cGUmcXVvdDsuPGJyPjxicj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjggw6LigqzigJwgZGF0YSBtb2RlbCBzZWN0 aW9uIDExLjIgaGFzIGEgbWljUGF0dGVybiBlbGVtZW50LCB3aGljaCBpcyBub3QgaW4gdGhlIGZy YW1ld29yay4mbmJzcDsgRGlkIHRoZSBncm91cCBkZWNpZGUgdG8gYWRkIHRoaXMgYXMgYW4gYXR0 cmlidXRlIG9mIGFuIGF1ZGlvIGNhcHR1cmU/Jm5ic3A7IEkgZG9uw6LigqzihKJ0IHJlbWVtYmVy IHN1Y2ggYSBkZWNpc2lvbi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIic+UmVtb3ZlZCAtIHRoaXMgd2FzIGFuIGV4YW1wbGUgb2YgYW4gKG9wdGlvbmFsKSBhdWRp by1zcGVjaWZpYyBtZWRpYSBjYXB0dXJlIGF0dHJpYnV0ZSB0aGF0IHdlIGRpc2N1c3NlZCBvbiB0 aGUgbWFpbGluZyBsaXN0IGluIGEgdmVyeSBvbGQgdGhyZWFkIHdpdGggSm9obiBMZXNsaWUgKDI0 LTEwLTIwMTIpLjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+OSAtIGRhdGEgbW9kZWwg c2VjdGlvbiAxMi4xIGhhcyBhIG5hdGl2ZUFzcGVjdFJhdGlvIGVsZW1lbnQsIHdoaWNoIGlzIG5v dCBpbiB0aGUgZnJhbWV3b3JrLiZuYnNwOyBEaWQgdGhlIGdyb3VwIGRlY2lkZSB0byBhZGQgdGhp cyBhcyBhbiBhdHRyaWJ1dGUgb2YgYSB2aWRlbyBjYXB0dXJlPyZuYnNwOyBJIGRvbsOi4oKs4oSi dCByZW1lbWJlciBzdWNoIGEgZGVjaXNpb24uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiInPlJlbW92ZWQgLSBJdCB3YXMgYSBtZWRpYSBjYXB0dXJlIGF0dHJpYnV0 ZSBwcm9wb3NlZCBpbiB0aGUgUm9tYW5vdydzIGRhdGEgbW9kZWwgZHJhZnQgdGhhdCB3ZSBjbGFz c2lmaWVkIGFzIGEgdmlkZW8tc3BlY2lmaWMgYXR0cmlidXRlLjxicj48YnI+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+MTAgw6LigqzigJwgZGF0YSBtb2RlbCBzZWN0aW9uIDE0LjEgdGhlIHNjZW5l U3BhY2UgZWxlbWVudCBzaG91bGQgYmUgcmVtb3ZlZC4mbmJzcDsgV2UgYWxyZWFkeSBkZWNpZGVk IHRvIHJlbW92ZSB0aGUgw6LigqzFk2FyZWEgb2Ygc2NlbmXDouKCrMKdIGF0dHJpYnV0ZSBpbiB0 aGUgZnJhbWV3b3JrLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Jz5Pay48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjExIMOi4oKs4oCcIGRhdGEgbW9k ZWwgc2VjdGlvbiAyMiBzaG91bGQgY2FwdHVyZUVuY29kaW5nVHlwZSBhbHNvIGluY2x1ZGUgYWRk aXRpb25hbCBlbGVtZW50cyB0byBzcGVjaWZ5IHRoZSBzcGVjaWZpYyB2YWx1ZXMgb2YgdGhlIHBh cmFtZXRlcnMgYmFuZHdpZHRoLCB3aWR0aCwgaGVpZ2h0LCBldGM/ICZuYnNwO0ZyYW1ld29yayBz ZWN0aW9uIDkgc2F5cyDDouKCrMWTRWFjaCBDYXB0dXJlIEVuY29kaW5nIHJlZmVycyB0byBvbmUg TWVkaWEgQ2FwdHVyZSwgb25lIEluZGl2aWR1YWwgRW5jb2RpbmcsIGFuZCBpbmNsdWRlcyB0aGUg ZW5jb2RpbmcgcGFyYW1ldGVyIHZhbHVlcy7DouKCrMKdJm5ic3A7IFJlZmVyIHRvIGNvbnZlcnNh dGlvbiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9j dXJyZW50L21zZzAyNTI2Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9jbHVlL2N1cnJlbnQvbXNnMDI1MjYuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiInPlllcywgZ2l2ZW4gd2hhdCBpcyBzdGF0ZWQgaW4gdGhlIGZyYW1ld29yayBkb2N1bWVudCwg dGhlIGNhcHR1cmVFbmNvZGluZ1R5cGUgc2hvdWxkIGNvbnRhaW4gYm90aCBjYXB0dXJlIHBhcmFt ZXRlcnMsIHN1Y2ggYXMgdGhlIHNlbGVjdGVkIHN3aXRjaGluZyBwb2xpY3ksIGFuZCBlbmNvZGlu ZyBwYXJhbWV0ZXJzLCBzdWNoIGFzIHRoZSBiYW5kd2l0ZGguIFdlIHByb3ZpZGUgYSBwb3NzaWJs ZSBzb2x1dGlvbiB0aGF0IG5lZWRzIHRvIGJlIGZ1cnRoZXIgZGlzY3Vzc2VkIHdpdGggcmVmZXJl bmNlcyB0byB0aGUgY29uc2lkZXJhdGlvbnMgbWFkZSBpbiA8YnI+PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NsdWUvY3VycmVudC9tc2cwMjUyNi5odG1sIj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJyZW50L21zZzAyNTI2 Lmh0bWw8L2E+Ljxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5NYXJrPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Iic+PGJyPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPjxwcmU+Y2x1 ZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNsdWVA aWV0Zi5vcmciPmNsdWVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A1CBCRPMBOXPRD07pol_-- From keith.drage@alcatel-lucent.com Wed Jul 17 04:07:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C366921F9948; Wed, 17 Jul 2013 04:07:01 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7BkwHXD8h6U; Wed, 17 Jul 2013 04:06:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF521F9D4A; Wed, 17 Jul 2013 04:06:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6HB6nwZ009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:06:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HB6lVR032483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:06:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:06:48 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARA= Date: Wed, 17 Jul 2013 11:06:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [clue] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 11:07:02 -0000 Breaking my own rule about cross posting... Just wanted to add is that this document would not be retrospective, i.e. w= e would not start rewriting the existing published RFCs to take into accoun= t the new terminology. The expectation however is that documents going forward from other working = groups would use the new terminology rather than other terms.=20 Obviously how this is handled is up to the individual working groups, but u= sing the new terminology will be the only good way of making your results u= nderstandable outside your specific field. So that is why your review and input is important. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 16 July 2013 15:58 > To: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; > avt@ietf.org > Subject: FW: Taxonomy >=20 > Extensive cross-post do not reply to this email. >=20 > For information. We do expect participation input from all the listed > working groups (and possibly more). >=20 > Keith >=20 > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 15:53 > To: avtext@ietf.org > Subject: [avtext] Taxonomy >=20 > (As AVTEXT WG cochair) >=20 > The latest version of the RTP taxonomy draft has been submitted. >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping- > taxonomy/ >=20 > This document was allocated to AVTEXT by DISPATCH, and we have created a > milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant meeting time discussing the > contents in the AVTEXT meeting in Berlin, so please start raising your > issues on the AVTEXT list. >=20 > Additionally, if there are counter proposals existing that the AVTEXT > chairs would not otherwise be aware of, then please identify them to the > AVTEXT chairs / list. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From ibc@aliax.net Wed Jul 17 04:27:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EDC21F9D92 for ; Wed, 17 Jul 2013 04:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw5V-a8G4P8u for ; Wed, 17 Jul 2013 04:27:09 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6721F9DA9 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so1024921qeb.22 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EKaU4MI2ZQsAWPvMCk3JxHj6BeoOuRCIjkCYNQ+jx9I=; b=TBnotIYnCODXIwImRJfC/iKzwjBpBvQ7LGCYNtMcmR6fwL1wRDWzZGBdcuCpktHMcY a33nyF3ngeJeVs9y0JqpRVsHWXICSs0ytZCaIlMo5CepXBEEIYynF7/bP6oP9BkXbFsc 2ivleUPQ3i//q0hcP4KY2uOKPN7Ab0DUHR/tzlOyM2XO8A1UF6WOMNOddkkczPFaIu+e +oUSrMAVXJ29H9PsGJOeVWhiOejLeSv2qOomFRuOX+ESeYckB4Vf8P9n2n00Nxp45ScD WXDThiztnXEKYDp9mS85atEypUWnBxog8uZvLkxNz+ya5pLSdTFviaWoYnTsswOaZeEx B/QQ== X-Received: by 10.224.90.1 with SMTP id g1mr8708293qam.0.1374060427977; Wed, 17 Jul 2013 04:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 17 Jul 2013 04:26:47 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 13:26:47 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlGbpEtOD5VF4TvEe5t1mg4g6eX45nMMhDUR7pJWx5s8s6qSLmiayIO/1a81ep4Z2LhbK79 X-Mailman-Approved-At: Wed, 17 Jul 2013 06:37:08 -0700 Cc: "clue@ietf.org" , "dispatch@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [clue] [dispatch] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 11:27:13 -0000 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=C3=B1aki Baz Castillo From mary.ietf.barnes@gmail.com Wed Jul 17 07:47:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B154421F8BD8 for ; Wed, 17 Jul 2013 07:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku2PpoRpjb9Y for ; Wed, 17 Jul 2013 07:47:38 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40C21F8B4E for ; Wed, 17 Jul 2013 07:47:36 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so1116507qcx.36 for ; Wed, 17 Jul 2013 07:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uqDCstsmsmrlKnJC9yAnkQePeSoCtqzv9SuD7CXWWs8=; b=IPxZLHjffqCWv8g/sw8pVhh0Knm//zIwEC2THmunXWtdB/TNC3dDiYAKju2sNZEVUU ++EvDTe1ihV+zebjH9s0c4q7QylcT3JOXgRomTeVUUWRSm6YN2RuPj1ytyvGhObc/ZoQ 9xgU4s+8qhGPRSTlFs+ACMn52AhO9jSnEfwiarWt8CeJSwCgk46aB3k/b9gRRQ1f/wZe B3QEt1qvBMdy8v0VUgjlSGSrtPK7U8PiAMfbu8i1yg6fzUirmBfHXr7oH4+TJprQkP1O tkQ6OTNpL9ONqp/QQSDOzvouwKPbjcNmLQq1V1kpoEPLOalUC118sgJifFTbU7cNLJpy j+jQ== MIME-Version: 1.0 X-Received: by 10.229.33.136 with SMTP id h8mr467500qcd.25.1374072455542; Wed, 17 Jul 2013 07:47:35 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 07:47:35 -0700 (PDT) Date: Wed, 17 Jul 2013 09:47:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=14dae9d70d0a9bc2c504e1b62c4e Subject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:47:40 -0000 --14dae9d70d0a9bc2c504e1b62c4e Content-Type: text/plain; charset=ISO-8859-1 Please note that we have moved the 2nd CLUE WG session from Friday morning to Wednesday afternoon (taking the original DISPATCH slot): Session 2 (2:00:00) Wednesday, Afternoon Session III 1620-1720 Room Name: Charlottenburg 2/3 The reason was to ensure that one of our key document editors could attend the session. Thanks, Mary. --14dae9d70d0a9bc2c504e1b62c4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please note that we have moved the 2nd CLUE WG session fro= m Friday morning to Wednesday afternoon (taking the original DISPATCH slot)= :
=A0
Session 2 (2:00:00)
=A0 =A0 Wednesday, Afternoon Session III 1620-1720
=A0 =A0 Room Name: Ch= arlottenburg 2/3

The reason was t= o ensure that one of our key document editors could attend the session.

Thanks,
Mary.=A0
--14dae9d70d0a9bc2c504e1b62c4e-- From coverdale@sympatico.ca Wed Jul 17 08:37:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8812F11E80E6 for ; Wed, 17 Jul 2013 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmL1lFJOIVkj for ; Wed, 17 Jul 2013 08:37:05 -0700 (PDT) Received: from blu0-omc1-s16.blu0.hotmail.com (blu0-omc1-s16.blu0.hotmail.com [65.55.116.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB7121F9ADD for ; Wed, 17 Jul 2013 08:37:04 -0700 (PDT) Received: from BLU0-SMTP100 ([65.55.116.9]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 08:37:04 -0700 X-EIP: [r9/Xvv/Q32ER5sR+Ek2Z6KuwS8e2oDsO] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.37.242]) by BLU0-SMTP100.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 08:37:01 -0700 From: Paul Coverdale To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Wed, 17 Jul 2013 11:36:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01CE82E1.F2BE18C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6C/JyK46cXga+xRu6Ssol3+7kyxgABgrJA Content-Language: en-us X-OriginalArrivalTime: 17 Jul 2013 15:37:01.0930 (UTC) FILETIME=[7B6E74A0:01CE8303] Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:37:21 -0000 ------=_NextPart_000_0044_01CE82E1.F2BE18C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And lost an hour? It seems that Wednesday Session III lasts from 1620-1720. (I guess, so as not to over-run into the Operations and Administration Plenary) ...Paul From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, July 17, 2013 10:48 AM To: CLUE Subject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session Please note that we have moved the 2nd CLUE WG session from Friday morning to Wednesday afternoon (taking the original DISPATCH slot): Session 2 (2:00:00) Wednesday, Afternoon Session III 1620-1720 Room Name: Charlottenburg 2/3 The reason was to ensure that one of our key document editors could attend the session. Thanks, Mary. ------=_NextPart_000_0044_01CE82E1.F2BE18C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And lost an hour? It seems that Wednesday Session III lasts from = 1620-1720. (I guess, so as not to over-run into the Operations and = Administration Plenary) 

  

 

...Paul

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Wednesday, July 17, 2013 10:48 = AM
To: CLUE
Subject: [clue] IMPORTANT: Schedule = change for 2nd CLUE WG session

 

Please = note that we have moved the 2nd CLUE WG session from Friday morning to = Wednesday afternoon (taking the original DISPATCH = slot):

 

Session 2 = (2:00:00)
    Wednesday, Afternoon Session III = 1620-1720
    Room Name: Charlottenburg = 2/3

 

The reason was to ensure that = one of our key document editors could attend the = session.

 

Thanks,

Mary. =

------=_NextPart_000_0044_01CE82E1.F2BE18C0-- From Mark.Duckworth@polycom.com Wed Jul 17 08:46:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DE521F8DE3 for ; Wed, 17 Jul 2013 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFVovsaapDQ8 for ; Wed, 17 Jul 2013 08:46:02 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D740021F9E1A for ; Wed, 17 Jul 2013 08:45:58 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 17 Jul 2013 08:45:58 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Jul 2013 08:45:56 -0700 Thread-Topic: [clue] data model for specifying attribute value in Configure message Thread-Index: Ac6BCEtl/Y3Gpq5MSpi0wWLJ1azILQB+43zw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> In-Reply-To: <51E36725.80002@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 15:46:06 -0000 Hi Christian, I think I understand your point, and it does seem like an issue in the data= -model-schema-00 document, section 22. This structure requires the captureParameters to be specified for each capt= ureEncodingType, but this isn't what we want. I think it would be better t= o have a structure that specifies a mediaCaptureID just once, with just one= corresponding captureParameters element, but with a list of encodingID and= encodingParameters to represent the multiple encodings of the single media= capture. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Sunday, July 14, 2013 11:06 PM > To: clue@ietf.org > Subject: Re: [clue] data model for specifying attribute value in Configur= e > message >=20 > Hello Mark, >=20 > I don't think the rule regarding CSE helps. The configure only lists the > CaptureID/EncodingID, no CSE or SceneID. The trouble with having > parameters in the Configure is that effectively a CaptureID no longer lis= ts a > unique capture. You could in theory have a CaptureID with different sets = of > attributes. An Advertisement could offer a CaptureID with multiple values > and a set of encodings. A consumer could in theory return the same > CaptureID multiple times with different values and the same encoding ID. > This would lead to the same CaptureEncoding which would cause referencing > issues. >=20 > Regards, Christian >=20 > On 13/07/2013 7:44 AM, Duckworth, Mark wrote: > > Paul, I agree it doesn't make sense to include different values of the > attribute for the same capture. This is related to the statement in the > framework in section 6.2.2 "The Consumer must choose the same value for > all the Media Captures in the Capture Scene Entry." So for me, the quest= ion > is should we devise an XML schema for this such that it is impossible for= the > Consumer to construct an inconsistent message? Or is it okay to have a > schema with potentially redundant information, thus enabling the possibil= ity > for the values to be inconsistent? My proposal allows the inconsistency,= and > I agree it would be better to avoid the redundancy and possibility of > inconsistency. I could make another proposal along those lines later. > > > > Are you saying there are also other problems with attributes that can b= e > specified in the Configure message? What about specifying the encoding > parameters, we agreed on that before didn't we? That is very similar to > specifying attribute values. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Friday, July 12, 2013 5:09 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] data model for specifying attribute value in > >> Configure message > >> > >> I've brought this up before, but I'll try again: > >> > >> As currently conceived, this mechanism has problems. > >> > >> Specifically, these attributes apply to captures, not capture-encoding= s. > >> > >> Suppose I configure two different encodings of the same capture, and > >> supply different attributes to each. (E.g. one with site switching > >> and one with scene > >> switching.) > >> > >> At that point, what is the meaning of the capture? I have two > >> encodings which may be showing entirely different content. IMO this is > nonsense. > >> > >> So I think there is a problem with attributes that can be specified > >> in the configure. There are a variety of possible solutions. The > >> simplest is simply to disallow them. > >> > >> Thanks, > >> Paul > >> > >> > >> > >> On 7/12/13 4:54 PM, Duckworth, Mark wrote: > >>> I think the data model is intended to support building a Configure > >>> message by using a list of captureEncoding elements. If so, there > >>> also needs to be a way to add parameter values of items where the > >>> Provider has offered a choice. > >>> > >>> From the framework: > >>> > >>> For each Media Capture in the message, the Consumer may also > >>> > >>> specify the value of any attributes for which the Provider has > >>> > >>> offered a choice, for example the value for the > >>> Scene-switch-policy > >>> > >>> attribute. > >>> > >>> Currently, I think Scene-switch-policy is the only attribute in this > >>> category. > >>> > >>> Does it make sense to add an element to do this into the > >>> captureEncodingType? This is similar to item 11 in my other list of > >>> comments http://www.ietf.org/mail- > >> archive/web/clue/current/msg02666.html. > >>> Mark > >>> > >>> > >>> > >>> _______________________________________________ > >>> clue mailing 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 keith.drage@alcatel-lucent.com Wed Jul 17 08:56:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1213E21F9E28 for ; Wed, 17 Jul 2013 08:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVVKjc+Fx5Tn for ; Wed, 17 Jul 2013 08:56:23 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 043FF21F9B8C for ; Wed, 17 Jul 2013 08:56:22 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6HFuI0e004777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 10:56:19 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HFtprL031353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 17:56:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 17:55:55 +0200 From: "DRAGE, Keith (Keith)" To: Paul Coverdale , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session Thread-Index: AQHOgvylH4RkVJshyUeLmhzaJA96/5lo33CAgAAix7A= Date: Wed, 17 Jul 2013 15:55:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06BC7F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B06BC7FFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:56:30 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B06BC7FFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And that change does not work for me either - that was the one slot I had t= o fit an external conference call into. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Coverdale Sent: 17 July 2013 16:37 To: 'Mary Barnes'; 'CLUE' Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session And lost an hour? It seems that Wednesday Session III lasts from 1620-1720.= (I guess, so as not to over-run into the Operations and Administration Ple= nary) ...Paul From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Wednesday, July 17, 2013 10:48 AM To: CLUE Subject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session Please note that we have moved the 2nd CLUE WG session from Friday morning = to Wednesday afternoon (taking the original DISPATCH slot): Session 2 (2:00:00) Wednesday, Afternoon Session III 1620-1720 Room Name: Charlottenburg 2/3 The reason was to ensure that one of our key document editors could attend = the session. Thanks, Mary. --_000_949EF20990823C4C85C18D59AA11AD8B06BC7FFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And that change does not work for me e= ither – that was the one slot I had to fit an external conference cal= l into.

 

Keith

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale
Sent: 17 July 2013 16:37
To: 'Mary Barnes'; 'CLUE' Subject: Re: [clue] IMPORTAN= T: Schedule change for 2nd CLUE WG session

 

= And lost an hour? It seems that Wednesday Session III lasts from 162= 0-1720. (I guess, so as not to over-run into the Operations and Administration Plenary)  =

=   

=  

= ...Paul

=  

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Wednesday, July 17, 2013 10= :48 AM
To: CLUE
Subject: [clue] IMPORTANT: S= chedule change for 2nd CLUE WG session

 

Please note that we have moved the 2n= d CLUE WG session from Friday morning to Wednesday afternoon (taking the or= iginal DISPATCH slot):

 

Session 2 (2:00:00)
    Wednesday, Afternoon Session III 1620-1720
    Room Name: Charlottenburg 2/3

 

The reason was to ensure that one of our key document editors could att= end the session.

 

Thanks,

Mary. =

--_000_949EF20990823C4C85C18D59AA11AD8B06BC7FFR712WXCHMBA11zeu_-- From pkyzivat@alum.mit.edu Wed Jul 17 09:02:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7621E8084 for ; Wed, 17 Jul 2013 09:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBZLr7zZiHAB for ; Wed, 17 Jul 2013 09:02:29 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 32BCF21F9E47 for ; Wed, 17 Jul 2013 09:02:28 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id 1R6j1m0051ZXKqc51U2PFB; Wed, 17 Jul 2013 16:02:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 1U2P1m00i3ZTu2S3hU2PUQ; Wed, 17 Jul 2013 16:02:23 +0000 Message-ID: <51E6C00E.6080903@alum.mit.edu> Date: Wed, 17 Jul 2013 12:02:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374076943; bh=Wg5xCcYmseJ4bncpPnxAKrXPaMgLM5hor9OVqwMvZx0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E4RfpDneerhxtyOyuqvjbfAYJJnEHPvXEI6nLOAbxFHgk+XB786N0d7rxW1X3BxWb BCEbWq+iTHYAlH/BdQ/RxbV7S3o8cBquSyKaz7T4XdalwVWrozyPJ6bguuYOW71F56 bTwjThzcMfr1xVpr8zMYWFhT3beVxMVF6YW8cAE+SV3WQOICjcJOyLCAuc8UQuoQfM owD2Aom3KvOhOh2PTU+Mw00flao6d/4K6Pb6oNIcu6x70w0EVjf1EFnAoX6gTaqWgI r4oPhbS7lT1WsMe5XP4JOVMXztFBRrLBYt8nc0k4mSMw6wDCyh0KOzN5GwRKelL2KG eZZKbLdjCNA3g== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 16:02:34 -0000 This *helps*. But it still means that a capture is only unique in the context of a configure. For instance this means that an MCU can't construct a capture once for all the endpoints that configure it. Of course this is true for capture-encodings too. But the effect is to constrain the architecture, putting the implementation of switching/composition into the encoding side of the pipeline. Maybe that is fine - I don't know the implementation details. But it is worth considering. But for me it is a conceptual issue - it fuzzes up what "capture" *means*. Thanks, Paul On 7/17/13 11:45 AM, Duckworth, Mark wrote: > Hi Christian, > > I think I understand your point, and it does seem like an issue in the data-model-schema-00 document, section 22. > > > > > > > > > > > > > This structure requires the captureParameters to be specified for each captureEncodingType, but this isn't what we want. I think it would be better to have a structure that specifies a mediaCaptureID just once, with just one corresponding captureParameters element, but with a list of encodingID and encodingParameters to represent the multiple encodings of the single media capture. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Sunday, July 14, 2013 11:06 PM >> To: clue@ietf.org >> Subject: Re: [clue] data model for specifying attribute value in Configure >> message >> >> Hello Mark, >> >> I don't think the rule regarding CSE helps. The configure only lists the >> CaptureID/EncodingID, no CSE or SceneID. The trouble with having >> parameters in the Configure is that effectively a CaptureID no longer lists a >> unique capture. You could in theory have a CaptureID with different sets of >> attributes. An Advertisement could offer a CaptureID with multiple values >> and a set of encodings. A consumer could in theory return the same >> CaptureID multiple times with different values and the same encoding ID. >> This would lead to the same CaptureEncoding which would cause referencing >> issues. >> >> Regards, Christian >> >> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>> Paul, I agree it doesn't make sense to include different values of the >> attribute for the same capture. This is related to the statement in the >> framework in section 6.2.2 "The Consumer must choose the same value for >> all the Media Captures in the Capture Scene Entry." So for me, the question >> is should we devise an XML schema for this such that it is impossible for the >> Consumer to construct an inconsistent message? Or is it okay to have a >> schema with potentially redundant information, thus enabling the possibility >> for the values to be inconsistent? My proposal allows the inconsistency, and >> I agree it would be better to avoid the redundancy and possibility of >> inconsistency. I could make another proposal along those lines later. >>> >>> Are you saying there are also other problems with attributes that can be >> specified in the Configure message? What about specifying the encoding >> parameters, we agreed on that before didn't we? That is very similar to >> specifying attribute values. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Friday, July 12, 2013 5:09 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] data model for specifying attribute value in >>>> Configure message >>>> >>>> I've brought this up before, but I'll try again: >>>> >>>> As currently conceived, this mechanism has problems. >>>> >>>> Specifically, these attributes apply to captures, not capture-encodings. >>>> >>>> Suppose I configure two different encodings of the same capture, and >>>> supply different attributes to each. (E.g. one with site switching >>>> and one with scene >>>> switching.) >>>> >>>> At that point, what is the meaning of the capture? I have two >>>> encodings which may be showing entirely different content. IMO this is >> nonsense. >>>> >>>> So I think there is a problem with attributes that can be specified >>>> in the configure. There are a variety of possible solutions. The >>>> simplest is simply to disallow them. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>> I think the data model is intended to support building a Configure >>>>> message by using a list of captureEncoding elements. If so, there >>>>> also needs to be a way to add parameter values of items where the >>>>> Provider has offered a choice. >>>>> >>>>> From the framework: >>>>> >>>>> For each Media Capture in the message, the Consumer may also >>>>> >>>>> specify the value of any attributes for which the Provider has >>>>> >>>>> offered a choice, for example the value for the >>>>> Scene-switch-policy >>>>> >>>>> attribute. >>>>> >>>>> Currently, I think Scene-switch-policy is the only attribute in this >>>>> category. >>>>> >>>>> Does it make sense to add an element to do this into the >>>>> captureEncodingType? This is similar to item 11 in my other list of >>>>> comments http://www.ietf.org/mail- >>>> archive/web/clue/current/msg02666.html. >>>>> Mark >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Jul 17 09:18:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93621F9C55 for ; Wed, 17 Jul 2013 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQNvmk52p5lI for ; Wed, 17 Jul 2013 09:18:34 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59E21F99F8 for ; Wed, 17 Jul 2013 09:18:34 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so1228210qeb.16 for ; Wed, 17 Jul 2013 09:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pl6jEHIGgb8hX8lAvFSo8yKtcDt9ZyUl7mpJ0XnlfcM=; b=cqam5iy6RWDxQ9n6Rj0QQIKA1kCNWxtQ//yc0XTYVXntOe55/tLh+LnP921nMpa6B1 1xAwMv/AxbENLnqcANX/E7CMYxzR9WWE6jdYHbTIBTpUTK1H0/NdlHFHS/zJPJk2Co8l 3jegecc7l4ThjxWxLWTrHJUCyXjZUABLZLhtGiabbqCE5bmrbk6yJV14I0Nk5N0UPRnY WSFylrSlNuGRFUvcLTay9hcDeNPG4nHREitl9W5rLCxRcpODS9RyrFGG/1qvFQwEQtVr 0uBqLKHt6X1ezc3BCB0CqNJCBqRtoMgsfUUp8RSAsmMCe4zsNGiI7ZviSHoIb5hLMcGu Cutw== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr9655066qaj.57.1374077913969; Wed, 17 Jul 2013 09:18:33 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 09:18:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 11:18:33 -0500 Message-ID: From: Mary Barnes To: Paul Coverdale Content-Type: multipart/alternative; boundary=001a11c3e0e4f4d70d04e1b771ea Cc: CLUE Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:18:35 -0000 --001a11c3e0e4f4d70d04e1b771ea Content-Type: text/plain; charset=ISO-8859-1 It thought it was a two hour slot as that's what we requested for DISPATCH and that's what's noted at the top, but maybe they just show what you requested. Let me double check. The reason for the change was because Rob won't be here Friday. If it's really an hour, I'll ask if we can get an hour on Friday. If folks recall, we used <1 hour for our second slot in Orlando. Mary. On Wed, Jul 17, 2013 at 10:36 AM, Paul Coverdale wrote: > And lost an hour? It seems that Wednesday Session III lasts from > 1620-1720. (I guess, so as not to over-run into the Operations and > Administration Plenary) **** > > **** > > ** ** > > ...Paul**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Wednesday, July 17, 2013 10:48 AM > *To:* CLUE > *Subject:* [clue] IMPORTANT: Schedule change for 2nd CLUE WG session**** > > ** ** > > Please note that we have moved the 2nd CLUE WG session from Friday morning > to Wednesday afternoon (taking the original DISPATCH slot):**** > > **** > > Session 2 (2:00:00) > Wednesday, Afternoon Session III 1620-1720 > Room Name: Charlottenburg 2/3**** > > ** ** > > The reason was to ensure that one of our key document editors could attend > the session.**** > > ** ** > > Thanks,**** > > Mary. **** > --001a11c3e0e4f4d70d04e1b771ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It thought it was a two hour slot as that's what we re= quested for DISPATCH and that's what's noted at the top, but maybe = they just show what you requested. =A0Let me double check. =A0 The reason f= or the change was because Rob won't be here Friday. =A0 If it's rea= lly an hour, I'll ask if we can get an hour on Friday. If folks recall,= we used <1 hour for our second slot in Orlando. =A0

Mary.


On Wed, Jul 17, 2013 at 10:36 AM, Paul Coverdale <= coverdale@sympatico.ca> wrote:

And lost an h= our? It seems that Wednesday Session III lasts from 1620-1720. (I guess, so= as not to over-run into the Operations and Administration Plenary)=A0 <= /u>

=A0=A0

=A0

...Paul

=A0<= /span>

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, July 17, 2013 10:48 AM
To: CLUE
Sub= ject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session<= u>

=A0

Please note that we have m= oved the 2nd CLUE WG session from Friday morning to Wednesday afternoon (ta= king the original DISPATCH slot):

=A0

Session 2= (2:00:00)
=A0 =A0 Wednesday, Afternoon Session III 1620-1720
=A0 =A0= Room Name: Charlottenburg 2/3

=A0

The reason was to ensure that one of our key document editor= s could attend the session.

=A0

Thanks,

= Mary.=A0


--001a11c3e0e4f4d70d04e1b771ea-- From mary.ietf.barnes@gmail.com Wed Jul 17 09:30:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41F311E80E0 for ; Wed, 17 Jul 2013 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uolx0f87UEUq for ; Wed, 17 Jul 2013 09:30:46 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 623A521F9EA7 for ; Wed, 17 Jul 2013 09:30:45 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so1243109qeb.33 for ; Wed, 17 Jul 2013 09:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SdhVaTvq5bbxdTFZ1bLsguJt2O2SyfkOlE3nZNmAtB4=; b=U+nz/MQDkNrOfpo1lqeDQOPZwB9N96p7LSkHJeyqrpPuuGFx4/7vMlQunXy8Ag7CS8 nLLzSodk564ChTOtBp3t2luq+mbX2z/WeWJzTe5NvoqDbzhZvtepiMv662/DzoTFBWmG 5VWGFqB23aREkwsmIG1NjHxTi/5XwVv+oyBVdHBH76DBJzo5cWzRGh/mrz1GR5P/aeBG U1aDZGMweNDDSvnrfSE2oYVbNiDY9N+q5eYeusBUg5pgUh4LnRl2YQU8bXjslcJx2lge 8J3cVT42t6NUpZXRD8PZByOPuMZqLH/PJ1aDDymjLb5yyUZxFQmKlb8UiLdz7b1euDDW jkmw== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr8576609qeb.6.1374078644725; Wed, 17 Jul 2013 09:30:44 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 09:30:44 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06BC7F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06BC7F@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 17 Jul 2013 11:30:44 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=047d7bdc90aa8360cd04e1b79d0a Cc: CLUE Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:30:47 -0000 --047d7bdc90aa8360cd04e1b79d0a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Unfortunately, I believe it is more important to optimize things for document authors. As the IETF agenda *always* states: *IETF agendas are subject to change, up to and during the meeting.* * * Mary. On Wed, Jul 17, 2013 at 10:55 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > **** > > And that change does not work for me either =96 that was the one slot I h= ad > to fit an external conference call into.**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Paul Coverdale > *Sent:* 17 July 2013 16:37 > *To:* 'Mary Barnes'; 'CLUE' > *Subject:* Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session*= * > ** > > ** ** > > And lost an hour? It seems that Wednesday Session III lasts from > 1620-1720. (I guess, so as not to over-run into the Operations and > Administration Plenary) **** > > **** > > ** ** > > ...Paul**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Wednesday, ** July 17, 2013** **10:48 AM** > *To:* CLUE > *Subject:* [clue] IMPORTANT: Schedule change for 2nd CLUE WG session**** > > ** ** > > Please note that we have moved the 2nd CLUE WG session from Friday mornin= g > to Wednesday afternoon (taking the original DISPATCH slot):**** > > **** > > Session 2 (2:00:00) > Wednesday, Afternoon Session III 1620-1720 > Room Name: Charlottenburg 2/3**** > > ** ** > > The reason was to ensure that one of our key document editors could atten= d > the session.**** > > ** ** > > Thanks,**** > > Mary. **** > --047d7bdc90aa8360cd04e1b79d0a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Unfortunately, I believe it is more important to optimize = things for document authors. =A0As the IETF agenda *always* states:=A0
= IETF agendas are subj= ect to change, up to and during the meeting.

Mary.


On Wed, Jul 17, 2013 at 10:55 AM, DRAGE,= Keith (Keith) <keith.drage@alcatel-lucent.com>= wrote:

And that change does not work= for me either =96 that was the one slot I had to fit an external conferenc= e call into.

=A0

Keith

=A0

From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of Paul Coverdale
Sent: 17 July 2013 16:37
To: 'Mary Barnes'; &= #39;CLUE'
Subject: Re: [clue] IMPORTAN= T: Schedule change for 2nd CLUE WG session

=A0

And= lost an hour? It seems that Wednesday Session III lasts from 1620-1720. (I= guess, so as not to over-run into the Operations and Administration Plenary)=A0 =

=A0= =A0

= =A0

...= Paul

= =A0

From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of Mary Barnes
Sent: Wednesday, July 17, 2013 10:48 AM
To: CLUE
Subject: [clue] IMPORTANT: S= chedule change for 2nd CLUE WG session

=A0

Please note that we have moved the 2n= d CLUE WG session from Friday morning to Wednesday afternoon (taking the or= iginal DISPATCH slot):

=A0

Session 2 (2:00:00)
=A0 =A0 Wednesday, Afternoon Session III 1620-1720
=A0 =A0 Room Name: Charlottenburg 2/3=

=A0

The reason was to ensur= e that one of our key document editors could attend the session.

=A0

Thanks,

Mary.=A0<= /span>


--047d7bdc90aa8360cd04e1b79d0a-- From mary.ietf.barnes@gmail.com Wed Jul 17 09:43:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2726421F9D0E for ; Wed, 17 Jul 2013 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHb+pL4e6tH6 for ; Wed, 17 Jul 2013 09:43:57 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2365A21F9C72 for ; Wed, 17 Jul 2013 09:43:56 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so3066449qak.7 for ; Wed, 17 Jul 2013 09:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HWFVeIzsOhrjpbfbNq3td2DWDNxFuFPE6CxoM1LCIok=; b=Iv7LnM4Bs+ldTPtwDVh/yU+YZSY5l1WFLP0LEkEmxLgXjoX/48llcUfazrVaKuDplK cwOfxHJgn+HqrDWGi4wm7qRYMsxHGfeoCpsqmctwCz01AIZ8fJhTmvUt8mkyeu7Ufscy zKhZWQOVO5CqfybpRwGo3130XzLgWdJvXyJYFqo6g51um254//3MgiBKkVUK+IyvoLc9 YtW9meNdJZl0BZt1rPajbEOVPo70BfuhU2G++/DdHgDyKoVAY9crvkogP/QLTRmOzMPy m+1yKOGcmEKPZLYUCcSYcEHS/CIiNwZaIM1b+hNF8p1RsnunflvHP7hVnnXJTXql0zk/ MT0w== MIME-Version: 1.0 X-Received: by 10.224.149.199 with SMTP id u7mr9874239qav.37.1374079428154; Wed, 17 Jul 2013 09:43:48 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 09:43:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 11:43:48 -0500 Message-ID: From: Mary Barnes To: Paul Coverdale Content-Type: multipart/alternative; boundary=089e010d9912355b7f04e1b7cc46 Cc: CLUE Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:43:58 -0000 --089e010d9912355b7f04e1b7cc46 Content-Type: text/plain; charset=ISO-8859-1 I checked with Stephanie. DISPATCH also have the 1510-1610 slot in the same room, so CLUE can have that slot as well. I don't know why it didn't show up in the email I got for the DISPATCH slot. Mary. On Wed, Jul 17, 2013 at 11:18 AM, Mary Barnes wrote: > It thought it was a two hour slot as that's what we requested for DISPATCH > and that's what's noted at the top, but maybe they just show what you > requested. Let me double check. The reason for the change was because > Rob won't be here Friday. If it's really an hour, I'll ask if we can get > an hour on Friday. If folks recall, we used <1 hour for our second slot in > Orlando. > > Mary. > > > On Wed, Jul 17, 2013 at 10:36 AM, Paul Coverdale wrote: > >> And lost an hour? It seems that Wednesday Session III lasts from >> 1620-1720. (I guess, so as not to over-run into the Operations and >> Administration Plenary) **** >> >> **** >> >> ** ** >> >> ...Paul**** >> >> ** ** >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* Wednesday, July 17, 2013 10:48 AM >> *To:* CLUE >> *Subject:* [clue] IMPORTANT: Schedule change for 2nd CLUE WG session**** >> >> ** ** >> >> Please note that we have moved the 2nd CLUE WG session from Friday >> morning to Wednesday afternoon (taking the original DISPATCH slot):**** >> >> **** >> >> Session 2 (2:00:00) >> Wednesday, Afternoon Session III 1620-1720 >> Room Name: Charlottenburg 2/3**** >> >> ** ** >> >> The reason was to ensure that one of our key document editors could >> attend the session.**** >> >> ** ** >> >> Thanks,**** >> >> Mary. **** >> > > --089e010d9912355b7f04e1b7cc46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I checked with Stephanie. =A0DISPATCH also have the 1510-1= 610 slot in the same room, so CLUE can have that slot as well. I don't = know why it didn't show up in the email I got for the DISPATCH slot.
Mary.=A0


On Wed, Jul 17, 2013 at 11:18 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
It thought it was a two hou= r slot as that's what we requested for DISPATCH and that's what'= ;s noted at the top, but maybe they just show what you requested. =A0Let me= double check. =A0 The reason for the change was because Rob won't be h= ere Friday. =A0 If it's really an hour, I'll ask if we can get an h= our on Friday. If folks recall, we used <1 hour for our second slot in O= rlando. =A0

Mary.


On= Wed, Jul 17, 2013 at 10:36 AM, Paul Coverdale <coverdale@sympatico.c= a> wrote:

And lost an h= our? It seems that Wednesday Session III lasts from 1620-1720. (I guess, so= as not to over-run into the Operations and Administration Plenary)=A0 <= /u>

=A0=A0

=A0

...Paul

=A0<= /span>

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, July 17, 2013 10:48 AM
To: CLUE
Sub= ject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session<= u>

=A0

Please note that we have m= oved the 2nd CLUE WG session from Friday morning to Wednesday afternoon (ta= king the original DISPATCH slot):

=A0

Session 2= (2:00:00)
=A0 =A0 Wednesday, Afternoon Session III 1620-1720
=A0 =A0= Room Name: Charlottenburg 2/3

=A0

The reason was to ensure that one of our key document editor= s could attend the session.

=A0

Thanks,

= Mary.=A0



--089e010d9912355b7f04e1b7cc46-- From Mark.Duckworth@polycom.com Wed Jul 17 09:53:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A5721F92C2 for ; Wed, 17 Jul 2013 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6EnWZKtggQn for ; Wed, 17 Jul 2013 09:53:41 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7698E21F91CB for ; Wed, 17 Jul 2013 09:53:40 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 17 Jul 2013 09:53:40 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Jul 2013 09:53:38 -0700 Thread-Topic: [clue] data model for specifying attribute value in Configure message Thread-Index: Ac6DBxL1WiriZdR8RqqN7Pso5IOszgABQuFA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A459@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E6C00E.6080903@alum.mit.edu> In-Reply-To: <51E6C00E.6080903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 16:53:47 -0000 Hi Paul, Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, July 17, 2013 12:02 PM > To: clue@ietf.org > Subject: Re: [clue] data model for specifying attribute value in Configur= e > message >=20 > This *helps*. But it still means that a capture is only unique in the con= text of > a configure. [Duckworth, Mark] But to begin with, a capture is only unique within the c= ontext of an advertisement. Then a configure references an advertisement. = I don't see the problem with specifying an attribute in the configure, for= which the MCU has advertised choices. I view it as a shorthand for advert= ising separate captures with separate attribute values. I thought that was= the motivation for including the "select a value from the advertised choic= es" mechanism (for the scene-switch-policy attribute). [Duckworth, Mark] If we remove this mechanism, and simply have the Provide= r advertise separate captures with separate attribute values, would this ad= dress your concern? > For instance this means that an MCU can't construct a capture > once for all the endpoints that configure it. [Duckworth, Mark] It would be an internal implementation detail if an MCU = wants to relate captures from one advertisement in one CLUE protocol sessio= n to captures in another advertisement in another CLUE protocol session. F= rom CLUE protocol point of view, there should be no relationship. > Of course this is true for capture-encodings too. But the effect is to co= nstrain > the architecture, putting the implementation of switching/composition int= o > the encoding side of the pipeline. Maybe that is fine - I don't know the > implementation details. But it is worth considering. [Duckworth, Mark] I don't follow what you are trying to say. >=20 > But for me it is a conceptual issue - it fuzzes up what "capture" *means*= . >=20 > Thanks, > Paul >=20 > On 7/17/13 11:45 AM, Duckworth, Mark wrote: > > Hi Christian, > > > > I think I understand your point, and it does seem like an issue in the = data- > model-schema-00 document, section 22. > > > > > > > > > > > > > > type=3D"captureParametersType" minOccurs=3D"0"/> > > type=3D"encodingParametersType" minOccurs=3D"0"/> > > > > > > > > This structure requires the captureParameters to be specified for each > captureEncodingType, but this isn't what we want. I think it would be be= tter > to have a structure that specifies a mediaCaptureID just once, with just = one > corresponding captureParameters element, but with a list of encodingID an= d > encodingParameters to represent the multiple encodings of the single medi= a > capture. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Sunday, July 14, 2013 11:06 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] data model for specifying attribute value in > >> Configure message > >> > >> Hello Mark, > >> > >> I don't think the rule regarding CSE helps. The configure only lists > >> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having > >> parameters in the Configure is that effectively a CaptureID no longer > >> lists a unique capture. You could in theory have a CaptureID with > >> different sets of attributes. An Advertisement could offer a > >> CaptureID with multiple values and a set of encodings. A consumer > >> could in theory return the same CaptureID multiple times with differen= t > values and the same encoding ID. > >> This would lead to the same CaptureEncoding which would cause > >> referencing issues. > >> > >> Regards, Christian > >> > >> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: > >>> Paul, I agree it doesn't make sense to include different values of > >>> the > >> attribute for the same capture. This is related to the statement in > >> the framework in section 6.2.2 "The Consumer must choose the same > >> value for all the Media Captures in the Capture Scene Entry." So for > >> me, the question is should we devise an XML schema for this such that > >> it is impossible for the Consumer to construct an inconsistent > >> message? Or is it okay to have a schema with potentially redundant > >> information, thus enabling the possibility for the values to be > >> inconsistent? My proposal allows the inconsistency, and I agree it > >> would be better to avoid the redundancy and possibility of inconsisten= cy. > I could make another proposal along those lines later. > >>> > >>> Are you saying there are also other problems with attributes that > >>> can be > >> specified in the Configure message? What about specifying the > >> encoding parameters, we agreed on that before didn't we? That is > >> very similar to specifying attribute values. > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Friday, July 12, 2013 5:09 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] data model for specifying attribute value in > >>>> Configure message > >>>> > >>>> I've brought this up before, but I'll try again: > >>>> > >>>> As currently conceived, this mechanism has problems. > >>>> > >>>> Specifically, these attributes apply to captures, not capture-encodi= ngs. > >>>> > >>>> Suppose I configure two different encodings of the same capture, > >>>> and supply different attributes to each. (E.g. one with site > >>>> switching and one with scene > >>>> switching.) > >>>> > >>>> At that point, what is the meaning of the capture? I have two > >>>> encodings which may be showing entirely different content. IMO this > >>>> is > >> nonsense. > >>>> > >>>> So I think there is a problem with attributes that can be specified > >>>> in the configure. There are a variety of possible solutions. The > >>>> simplest is simply to disallow them. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> > >>>> > >>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: > >>>>> I think the data model is intended to support building a Configure > >>>>> message by using a list of captureEncoding elements. If so, there > >>>>> also needs to be a way to add parameter values of items where the > >>>>> Provider has offered a choice. > >>>>> > >>>>> From the framework: > >>>>> > >>>>> For each Media Capture in the message, the Consumer may also > >>>>> > >>>>> specify the value of any attributes for which the Provider > >>>>> has > >>>>> > >>>>> offered a choice, for example the value for the > >>>>> Scene-switch-policy > >>>>> > >>>>> attribute. > >>>>> > >>>>> Currently, I think Scene-switch-policy is the only attribute in > >>>>> this category. > >>>>> > >>>>> Does it make sense to add an element to do this into the > >>>>> captureEncodingType? This is similar to item 11 in my other list > >>>>> of comments http://www.ietf.org/mail- > >>>> archive/web/clue/current/msg02666.html. > >>>>> Mark > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Jul 17 10:16:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9710821F9F34 for ; Wed, 17 Jul 2013 10:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYbTkNbXsUaI for ; Wed, 17 Jul 2013 10:16:08 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D391821F9F85 for ; Wed, 17 Jul 2013 10:16:07 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id 1PiX1m0060bG4ec51VG7GX; Wed, 17 Jul 2013 17:16:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 1VG71m0033ZTu2S3PVG7Zu; Wed, 17 Jul 2013 17:16:07 +0000 Message-ID: <51E6D155.6060203@alum.mit.edu> Date: Wed, 17 Jul 2013 13:16:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E6C00E.6080903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601D2A459@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601D2A459@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374081367; bh=8IClTi3LeyMHgpHMmTTnkmvFKmMwlboPHSln6bWtxN4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lmpxTqL7aUueEyFhwwTAwNm7qXKw3LtB69oy+7SZxrVtaFxiLKQ/HOwFISWJsHpwX E7c8GQ/0O34NrsUwAp/YziyUWycbnGSsDSPSA5UMa4HtfkdiDAB3Fha7VEfKmbOQ9g Dhu1PFlAIdlruLJhchTHuU4u3HeNIvhgghButy0eL+XJybRZqkK3ifXAGpVoJ7tBNA VhJNIdPHjktJJ76uu9FbsORSjDD3gpi+CaBJ/r5SdJOSs81XIbDXsRGp7/eorieDT4 lnrhW/rlFuM5+oD67biinfa4zO/4G+qZAmSV+WbR7f6ygfs/tY9LN0c4L7UYBAZ6wK jSa6Z7aW0dflA== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 17:16:16 -0000 On 7/17/13 12:53 PM, Duckworth, Mark wrote: > Hi Paul, > > Comments inline. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Wednesday, July 17, 2013 12:02 PM >> To: clue@ietf.org >> Subject: Re: [clue] data model for specifying attribute value in Configure >> message >> >> This *helps*. But it still means that a capture is only unique in the context of >> a configure. > > [Duckworth, Mark] But to begin with, a capture is only unique within the context of an advertisement. Then a configure references an advertisement. I don't see the problem with specifying an attribute in the configure, for which the MCU has advertised choices. I view it as a shorthand for advertising separate captures with separate attribute values. I thought that was the motivation for including the "select a value from the advertised choices" mechanism (for the scene-switch-policy attribute). See below comment. > [Duckworth, Mark] If we remove this mechanism, and simply have the Provider advertise separate captures with separate attribute values, would this address your concern? Yes. >> For instance this means that an MCU can't construct a capture >> once for all the endpoints that configure it. > > [Duckworth, Mark] It would be an internal implementation detail if an MCU wants to relate captures from one advertisement in one CLUE protocol session to captures in another advertisement in another CLUE protocol session. From CLUE protocol point of view, there should be no relationship. Yes, I agree it is. But I can imagine that an implementation might find it important to share as much as possible of the processing pipeline between multiple endpoints. We should at least be mindful if we are making this more difficult. OTOH, I suppose an MCU that wants to do that could construct its advertisements so that they don't provide any inconvenient configure options. >> Of course this is true for capture-encodings too. But the effect is to constrain >> the architecture, putting the implementation of switching/composition into >> the encoding side of the pipeline. Maybe that is fine - I don't know the >> implementation details. But it is worth considering. > > [Duckworth, Mark] I don't follow what you are trying to say. I'm saying that if a capture offers multiple encodings, then that presents some of the same issues - that different encodings of a capture might need to be generated depending on what is configured. I'm assuming there is some sort of processing pipeline, from reception, decoding, switching & composition, encoding. The question is how much of this pipeline can be common among different endpoints of the MCU. But I'm probably obsessing. >> But for me it is a conceptual issue - it fuzzes up what "capture" *means*. And this is the fundamental issue to me. With this kind of parameterization, what is the definition of a capture, independent of the configuration parameters? Can we explain it in a way that makes sense? (Especially to people not intimately involved in clue.) Thanks, Paul From mary.ietf.barnes@gmail.com Wed Jul 17 10:48:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7929C21F9CC7 for ; Wed, 17 Jul 2013 10:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLEUExl35fDc for ; Wed, 17 Jul 2013 10:48:57 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6121F92C2 for ; Wed, 17 Jul 2013 10:48:57 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so1271599qeb.22 for ; Wed, 17 Jul 2013 10:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nfptFdR0nYKdTIA0v1Ralvr99P5EvFxqxQLBhRki+RE=; b=Ln0jyknEJUNk9H/tuuB/c2/VT+G28b9+XNrU9lXfyEWT0BOuGBrbhisi2h+v5zzRFN AqfrjoJ6qx5NQjLsgMmx0K/SalL89jgYiqoizUa3UbWBxxzrc0bju/LWfR0x/iKPjrAD w2PiM5WeNmkHZiHnkd5cOAb1D3uTJArJ099AQ9JxiQvXy3W9jbjFiUQs+0GlUKttWWqr jRB/m60PGD0MJcasnWlRPBo+0xB/rgAngm69DAFE4A83OdeT7WzZtVuOPSScgH4yaaii 7s+swUAWkSMNcB/mseTylJBM4KVIPGSAaQ79VI0DeWj8ohhUIrCq9scV+BKLTBgxeW8t dDIg== MIME-Version: 1.0 X-Received: by 10.224.149.199 with SMTP id u7mr10161899qav.37.1374083337097; Wed, 17 Jul 2013 10:48:57 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 10:48:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 12:48:56 -0500 Message-ID: From: Mary Barnes To: Paul Coverdale Content-Type: multipart/alternative; boundary=089e010d991233358604e1b8b547 Cc: CLUE Subject: Re: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:48:58 -0000 --089e010d991233358604e1b8b547 Content-Type: text/plain; charset=ISO-8859-1 One thing I should also highlight is that we only requested 1.0 hour for a 2nd slot based upon the time used in Orlando. We were originally given the 2.0 slot on Friday, but that was just how it worked out, not that we requested it. Mary. On Wed, Jul 17, 2013 at 11:43 AM, Mary Barnes wrote: > I checked with Stephanie. DISPATCH also have the 1510-1610 slot in the > same room, so CLUE can have that slot as well. I don't know why it didn't > show up in the email I got for the DISPATCH slot. > > Mary. > > > On Wed, Jul 17, 2013 at 11:18 AM, Mary Barnes wrote: > >> It thought it was a two hour slot as that's what we requested for >> DISPATCH and that's what's noted at the top, but maybe they just show what >> you requested. Let me double check. The reason for the change was >> because Rob won't be here Friday. If it's really an hour, I'll ask if we >> can get an hour on Friday. If folks recall, we used <1 hour for our second >> slot in Orlando. >> >> Mary. >> >> >> On Wed, Jul 17, 2013 at 10:36 AM, Paul Coverdale wrote: >> >>> And lost an hour? It seems that Wednesday Session III lasts from >>> 1620-1720. (I guess, so as not to over-run into the Operations and >>> Administration Plenary) **** >>> >>> **** >>> >>> ** ** >>> >>> ...Paul**** >>> >>> ** ** >>> >>> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >>> Of *Mary Barnes >>> *Sent:* Wednesday, July 17, 2013 10:48 AM >>> *To:* CLUE >>> *Subject:* [clue] IMPORTANT: Schedule change for 2nd CLUE WG session**** >>> >>> ** ** >>> >>> Please note that we have moved the 2nd CLUE WG session from Friday >>> morning to Wednesday afternoon (taking the original DISPATCH slot):**** >>> >>> **** >>> >>> Session 2 (2:00:00) >>> Wednesday, Afternoon Session III 1620-1720 >>> Room Name: Charlottenburg 2/3**** >>> >>> ** ** >>> >>> The reason was to ensure that one of our key document editors could >>> attend the session.**** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> Mary. **** >>> >> >> > --089e010d991233358604e1b8b547 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One thing I should also highlight is that we only requeste= d 1.0 hour for a 2nd slot based upon the time used in Orlando. =A0We were o= riginally given the 2.0 slot on Friday, but that was just how it worked out= , not that we requested it.=A0

Mary.=A0


On Wed, Jul 17, 2013 at 11:43 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
I checked with Stephanie. = =A0DISPATCH also have the 1510-1610 slot in the same room, so CLUE can have= that slot as well. I don't know why it didn't show up in the email= I got for the DISPATCH slot.

Mary.=A0


On Wed, Jul 17, 2013 at 11:18 AM, Mary Barnes <mary.ietf.barnes@= gmail.com> wrote:
It thought it was a two hou= r slot as that's what we requested for DISPATCH and that's what'= ;s noted at the top, but maybe they just show what you requested. =A0Let me= double check. =A0 The reason for the change was because Rob won't be h= ere Friday. =A0 If it's really an hour, I'll ask if we can get an h= our on Friday. If folks recall, we used <1 hour for our second slot in O= rlando. =A0

Mary.


On Wed, Jul 17, 2013 at 10:36 AM= , Paul Coverdale <coverdale@sympatico.ca> wrote:

And lost an h= our? It seems that Wednesday Session III lasts from 1620-1720. (I guess, so= as not to over-run into the Operations and Administration Plenary)=A0 <= /u>

=A0=A0

=A0

...Paul

=A0<= /span>

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, July 17, 2013 10:48 AM
To: CLUE
Sub= ject: [clue] IMPORTANT: Schedule change for 2nd CLUE WG session<= u>

=A0

Please note that we have m= oved the 2nd CLUE WG session from Friday morning to Wednesday afternoon (ta= king the original DISPATCH slot):

=A0

Session 2= (2:00:00)
=A0 =A0 Wednesday, Afternoon Session III 1620-1720
=A0 =A0= Room Name: Charlottenburg 2/3

=A0

The reason was to ensure that one of our key document editor= s could attend the session.

=A0

Thanks,

= Mary.=A0




--089e010d991233358604e1b8b547-- From mary.ietf.barnes@gmail.com Wed Jul 17 11:00:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B99C21F9C53 for ; Wed, 17 Jul 2013 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cQUt2amPq39 for ; Wed, 17 Jul 2013 11:00:20 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6B21F9A1E for ; Wed, 17 Jul 2013 11:00:19 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so1237678qcv.37 for ; Wed, 17 Jul 2013 11:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P046I0Ggxf1UHGHK4K3jve6+NuTR79VUZEmfJ98zkFQ=; b=OLXELsrTv8WatzIR2VEeKntJD0phWHKhZpM5RrI4L1uMYPlALRQhZFDNKVdCaAQL38 q+iCTW3bzIZQNTY3hUVLDzZcoSC8vGYJeX9Kro7jhefzmzjZb8mS/sYeuwNhTLthE/R+ kKrpt4nasKwZIHewGW+mbdIcAoKhbSnjJGD3TepXe0wBsEp9D0ibdZz2k+f0NRXGbeIi bpNghlnc7UZtcubCs9zETlfp/7zq617fTBKaOpAwio+Damq87PVr3IhjRB4lbBjIg3DR ypW6qClbiDndtIv/J/q33CYGn75kuFqkSPCA8Th7XyJXjWrgweWCti6TDglrYwEH7ey3 Le1Q== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr8957802qeb.6.1374084019323; Wed, 17 Jul 2013 11:00:19 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 17 Jul 2013 11:00:19 -0700 (PDT) In-Reply-To: <20130717163322.17038.53136.idtracker@ietfa.amsl.com> References: <20130717163322.17038.53136.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 13:00:19 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bdc90aadd267b04e1b8dd20 Subject: [clue] Fwd: clue - Requested sessions have been scheduled for IETF 87 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 18:00:20 -0000 --047d7bdc90aadd267b04e1b8dd20 Content-Type: text/plain; charset=ISO-8859-1 FYI...the official schedule change. ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Wed, Jul 17, 2013 at 11:33 AM Subject: clue - Requested sessions have been scheduled for IETF 87 To: mary.ietf.barnes@gmail.com Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, smccammon@amsl.com Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (2:30:00) Monday, Morning Session I 0900-1130 Room Name: Tiergarten 1/2 --------------------------------------------- clue Session 2 (1:00:00) Wednesday, Afternoon Session II 1510-1610 Room Name: Charlottenburg 2/3 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: dispatch xrblock xmpp vipr siprec sipcore straw rtcweb payload mmusic insipid geopriv ecrit cuss codec bfcpbis avtext avtcore rmcat jose Second Priority: drinks soc p2psip Special Requests: Please schedule the sessions with at least two days in between (e.g., Mon & Wed/Thurs/Friday. We would also like Meetecho support for both sessions --------------------------------------------------------- --047d7bdc90aadd267b04e1b8dd20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI...the official schedule change.

---------- Forwarded message ----------
From: "IETF Secretariat" <agenda@ietf.org>
Date: Wed, Jul 17, 2013 at 11:33 AM
Subject: clue - Requested sessions h= ave been scheduled for IETF 87
To: mary.ietf.barnes@gmail.com
Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, smccammon@amsl.com


Dear Mary Barnes,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

clue Session 1 (2:30:00)
=A0 =A0 Monday, Morning Session I 0900-1130
=A0 =A0 Room Name: Tiergarten 1/2
=A0 =A0 ---------------------------------------------
=A0 =A0 clue Session 2 (1:00:00)
=A0 =A0 Wednesday, Afternoon Session II 1510-1610
=A0 =A0 Room Name: Charlottenburg 2/3
=A0 =A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name:
Area Name:
Session Requester:

Number of Sessions: 2
Length of Session(s): =A02.5 Hours, 1 Hour
Number of Attendees: 80
Conflicts to Avoid:
=A0First Priority: dispatch xrblock xmpp vipr siprec sipcore straw rtcweb p= ayload mmusic insipid geopriv ecrit cuss codec bfcpbis avtext avtcore rmcat= jose
=A0Second Priority: drinks soc p2psip



Special Requests:
=A0 Please schedule the sessions with at least two days in between (e.g., M= on &amp; Wed/Thurs/Friday.
We would also like Meetecho support for both sessions
---------------------------------------------------------


--047d7bdc90aadd267b04e1b8dd20-- From Mark.Duckworth@polycom.com Wed Jul 17 14:15:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1952D21F9D4F for ; Wed, 17 Jul 2013 14:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdoi3nPkyd98 for ; Wed, 17 Jul 2013 14:15:33 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D3ACC21F9CA8 for ; Wed, 17 Jul 2013 14:15:26 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 17 Jul 2013 14:15:26 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Jul 2013 14:15:24 -0700 Thread-Topic: MCU Advertising swtiched captures, and spatial relation Thread-Index: Ac6DMBNaHIJp+42AToSyZNQdxTdvyw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A65F@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601D2A65FCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] MCU Advertising swtiched captures, and spatial relation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 21:15:38 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A65FCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a follow up to the discussion from the last interim meeting, about = handling advertisements and spatial relations in a multipoint conference us= ing the media switching variety of the Topo-Mixer topology. The example an= d issues for discussion are in draft-duckworth-clue-switching-example-01. = I'd like to have some discussion on the list prior to Berlin. At the interim meeting, people seemed to prefer the "one big scene" approac= h, rather than the "multiple scenes" approach, so let's start with my draft= section 3.1 Advertising one big scene. I think everybody agreed it is ok= ay for the MCU Provider to advertise many (12 in this example) video captur= es in a single CSE, with some way to indicate the Consumer can pick a subse= t of them and still get a "complete" representation of the scene. The issu= e we still have is how does the Consumer know how to render the received en= codings with correct spatial relationships? It can't be just based on the Provider's advertised spatial coordinates, be= cause the provider doesn't know how the Consumer wants to organize it's lay= out (figures 1 and 2 for examples). And the advertised coordinates are ove= rconstrained and not clear how it is useful as described in issue 4. I come back to the consumer layout draft [draft-hansen-clue-consumer-layout= ] which proposes a solution. I think we should consider that proposal, for= enabling the Consumer to send "Area of Display" information to the Provide= r, so the Provider can make switching decisions based on how the Consumer w= ants to arrange its rendering. What other ideas or comments do you have about section 3.1 in my draft? Do= the issues 1 through 4 make sense? Is there an easier way to solve the pr= oblem for this use case example? Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A65FCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a follow= up to the discussion from the last interim meeting, about handling adverti= sements and spatial relations in a multipoint conference using the media sw= itching variety of the Topo-Mixer topology.  The example and issues fo= r discussion are in draft-duckworth-clue-switching-example-01.  I̵= 7;d like to have some discussion on the list prior to Berlin.

 

At the inte= rim meeting, people seemed to prefer the “one big scene” approa= ch, rather than the “multiple scenes” approach, so let’s = start with my draft section 3.1 Advertising one big scene.   I th= ink everybody agreed it is okay for the MCU Provider to advertise many (12 = in this example) video captures in a single CSE, with some way to indicate = the Consumer can pick a subset of them and still get a “complete̶= 1; representation of the scene.  The issue we still have is how does t= he Consumer know how to render the received encodings with correct spatial = relationships?

 

It can’t be just based on the Provider’s adver= tised spatial coordinates, because the provider doesn’t know how the = Consumer wants to organize it’s layout (figures 1 and 2 for examples)= .  And the advertised coordinates are overconstrained and not clear ho= w it is useful as described in issue 4.

=  

I come back to the consumer layou= t draft [draft-hansen-clue-consumer-layout] which proposes a solution. = ; I think we should consider that proposal, for enabling the Consumer to se= nd “Area of Display” information to the Provider, so the Provid= er can make switching decisions based on how the Consumer wants to arrange = its rendering.

 

What other ideas or comments do you have about section 3.1= in my draft?  Do the issues 1 through 4 make sense?  Is there an= easier way to solve the problem for this use case example?

<= p class=3DMsoNormal> 

Regards,=

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601D2A65FCRPMBOXPRD07pol_-- From Christian.Groves@nteczone.com Wed Jul 17 18:16:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7346921F9A16 for ; Wed, 17 Jul 2013 18:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDey7Lawkvlu for ; Wed, 17 Jul 2013 18:16:00 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 290A721F99FB for ; Wed, 17 Jul 2013 18:15:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAI1A51F20Ycd/2dsb2JhbAANTYM6SsBFgSmDFwEBAQQBAQEkERsbCg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAQUSh3wFo3mSQo5IgTkGg3UDpAaIR4Ff Received: from ppp118-209-135-29.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.135.29]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Jul 2013 10:45:56 +0930 Message-ID: <51E741C3.6030401@nteczone.com> Date: Thu, 18 Jul 2013 11:15:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 01:16:01 -0000 Hello Mark, What is needed is a structure that only allows one set of captureParameters per mediaCaptureID AND that the chosen set of captureParameters are used in all CaptureEncodings that reference the mediaCaptureID. This guarantees uniqueness. Having such a restriction does have side effects. For example: if the Provider indicates the support of segment and site switched for one CaptureID and the consumer wants both types of Captures in different capture encodings then this would not be possible. For this to be possible the Provider would have to Advertise one CaptureID with "segment" and another CaptureID with "site". If this is the case then the question is, is there any point in having a list of values in the first place? Regards, Christian On 18/07/2013 1:45 AM, Duckworth, Mark wrote: > Hi Christian, > > I think I understand your point, and it does seem like an issue in the data-model-schema-00 document, section 22. > > > > > > > > > > > > > This structure requires the captureParameters to be specified for each captureEncodingType, but this isn't what we want. I think it would be better to have a structure that specifies a mediaCaptureID just once, with just one corresponding captureParameters element, but with a list of encodingID and encodingParameters to represent the multiple encodings of the single media capture. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Sunday, July 14, 2013 11:06 PM >> To: clue@ietf.org >> Subject: Re: [clue] data model for specifying attribute value in Configure >> message >> >> Hello Mark, >> >> I don't think the rule regarding CSE helps. The configure only lists the >> CaptureID/EncodingID, no CSE or SceneID. The trouble with having >> parameters in the Configure is that effectively a CaptureID no longer lists a >> unique capture. You could in theory have a CaptureID with different sets of >> attributes. An Advertisement could offer a CaptureID with multiple values >> and a set of encodings. A consumer could in theory return the same >> CaptureID multiple times with different values and the same encoding ID. >> This would lead to the same CaptureEncoding which would cause referencing >> issues. >> >> Regards, Christian >> >> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>> Paul, I agree it doesn't make sense to include different values of the >> attribute for the same capture. This is related to the statement in the >> framework in section 6.2.2 "The Consumer must choose the same value for >> all the Media Captures in the Capture Scene Entry." So for me, the question >> is should we devise an XML schema for this such that it is impossible for the >> Consumer to construct an inconsistent message? Or is it okay to have a >> schema with potentially redundant information, thus enabling the possibility >> for the values to be inconsistent? My proposal allows the inconsistency, and >> I agree it would be better to avoid the redundancy and possibility of >> inconsistency. I could make another proposal along those lines later. >>> Are you saying there are also other problems with attributes that can be >> specified in the Configure message? What about specifying the encoding >> parameters, we agreed on that before didn't we? That is very similar to >> specifying attribute values. >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Friday, July 12, 2013 5:09 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] data model for specifying attribute value in >>>> Configure message >>>> >>>> I've brought this up before, but I'll try again: >>>> >>>> As currently conceived, this mechanism has problems. >>>> >>>> Specifically, these attributes apply to captures, not capture-encodings. >>>> >>>> Suppose I configure two different encodings of the same capture, and >>>> supply different attributes to each. (E.g. one with site switching >>>> and one with scene >>>> switching.) >>>> >>>> At that point, what is the meaning of the capture? I have two >>>> encodings which may be showing entirely different content. IMO this is >> nonsense. >>>> So I think there is a problem with attributes that can be specified >>>> in the configure. There are a variety of possible solutions. The >>>> simplest is simply to disallow them. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>> I think the data model is intended to support building a Configure >>>>> message by using a list of captureEncoding elements. If so, there >>>>> also needs to be a way to add parameter values of items where the >>>>> Provider has offered a choice. >>>>> >>>>> From the framework: >>>>> >>>>> For each Media Capture in the message, the Consumer may also >>>>> >>>>> specify the value of any attributes for which the Provider has >>>>> >>>>> offered a choice, for example the value for the >>>>> Scene-switch-policy >>>>> >>>>> attribute. >>>>> >>>>> Currently, I think Scene-switch-policy is the only attribute in this >>>>> category. >>>>> >>>>> Does it make sense to add an element to do this into the >>>>> captureEncodingType? This is similar to item 11 in my other list of >>>>> comments http://www.ietf.org/mail- >>>> archive/web/clue/current/msg02666.html. >>>>> Mark >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Jul 17 18:26:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F2C21F8AD5 for ; Wed, 17 Jul 2013 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meznyK1T3xQI for ; Wed, 17 Jul 2013 18:26:54 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA021F8947 for ; Wed, 17 Jul 2013 18:26:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAI1D51F20Ycd/2dsb2JhbAANTYM6wQ+BKYMXAQEBBAEBAS8BBRsVBgQGEQsYCRYPCQMCAQIBFTATBgIBAReIAaN9kj8EkAEWg2UDrE0 Received: from ppp118-209-135-29.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.135.29]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Jul 2013 10:56:41 +0930 Message-ID: <51E74446.6080802@nteczone.com> Date: Thu, 18 Jul 2013 11:26:30 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601D2A65F@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601D2A65F@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] MCU Advertising swtiched captures, and spatial relation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 01:26:55 -0000 Hello Mark, I'm still trying to get closure on the my draft with my other co-authors which discusses this switching issue. Unfortunately it wasn't ready for the draft cut-off deadline. Effectively it proposes a way to maintain the source Scene/Capture from the originating endpoints through the MCU to the receiving endpoint. Both multiple scenes and single scenes could be used depending on the mixing/switching scenario and it allows the ability to describe the composition of a single capture. Regards, Christian On 18/07/2013 7:15 AM, Duckworth, Mark wrote: > > This is a follow up to the discussion from the last interim meeting, > about handling advertisements and spatial relations in a multipoint > conference using the media switching variety of the Topo-Mixer > topology. The example and issues for discussion are in > draft-duckworth-clue-switching-example-01. I抎 like to have some > discussion on the list prior to Berlin. > > At the interim meeting, people seemed to prefer the 搊ne big scene > approach, rather than the 搈ultiple scenes approach, so let抯 start > with my draft section 3.1 Advertising one big scene. I think everybody > agreed it is okay for the MCU Provider to advertise many (12 in this > example) video captures in a single CSE, with some way to indicate the > Consumer can pick a subset of them and still get a 揷omplete > representation of the scene. The issue we still have is how does the > Consumer know how to render the received encodings with correct > spatial relationships? > > It can抰 be just based on the Provider抯 advertised spatial > coordinates, because the provider doesn抰 know how the Consumer wants > to organize it抯 layout (figures 1 and 2 for examples). And the > advertised coordinates are overconstrained and not clear how it is > useful as described in issue 4. > > I come back to the consumer layout draft > [draft-hansen-clue-consumer-layout] which proposes a solution. I think > we should consider that proposal, for enabling the Consumer to send > 揂rea of Display information to the Provider, so the Provider can > make switching decisions based on how the Consumer wants to arrange > its rendering. > > What other ideas or comments do you have about section 3.1 in my > draft? Do the issues 1 through 4 make sense? Is there an easier way to > solve the problem for this use case example? > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 17 18:33:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74EC21F9344 for ; Wed, 17 Jul 2013 18:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5roDQZzI5RYj for ; Wed, 17 Jul 2013 18:33:55 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 521BC21F8E1F for ; Wed, 17 Jul 2013 18:33:55 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 17 Jul 2013 18:33:54 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Jul 2013 18:33:54 -0700 Thread-Topic: [clue] MCU Advertising swtiched captures, and spatial relation Thread-Index: Ac6DVebY9B1n+oQvRSWnUuCEcuEXPQAAKAFg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A6E4@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601D2A65F@CRPMBOXPRD07.polycom.com> <51E74446.6080802@nteczone.com> In-Reply-To: <51E74446.6080802@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] MCU Advertising swtiched captures, and spatial relation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 01:33:59 -0000 Hi Christian, That sounds interesting. Can you tell us more? Will you be in Berlin to t= alk about it? Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, July 17, 2013 9:27 PM > To: clue@ietf.org > Subject: Re: [clue] MCU Advertising swtiched captures, and spatial relati= on >=20 > Hello Mark, >=20 > I'm still trying to get closure on the my draft with my other co-authors = which > discusses this switching issue. Unfortunately it wasn't ready for the dra= ft cut- > off deadline. Effectively it proposes a way to maintain the source > Scene/Capture from the originating endpoints through the MCU to the > receiving endpoint. Both multiple scenes and single scenes could be used > depending on the mixing/switching scenario and it allows the ability to > describe the composition of a single capture. >=20 > Regards, Christian >=20 > On 18/07/2013 7:15 AM, Duckworth, Mark wrote: > > > > This is a follow up to the discussion from the last interim meeting, > > about handling advertisements and spatial relations in a multipoint > > conference using the media switching variety of the Topo-Mixer > > topology. The example and issues for discussion are in > > draft-duckworth-clue-switching-example-01. I'd like to have some > > discussion on the list prior to Berlin. > > > > At the interim meeting, people seemed to prefer the "one big scene" > > approach, rather than the "multiple scenes" approach, so let's start > > with my draft section 3.1 Advertising one big scene. I think everybody > > agreed it is okay for the MCU Provider to advertise many (12 in this > > example) video captures in a single CSE, with some way to indicate the > > Consumer can pick a subset of them and still get a "complete" > > representation of the scene. The issue we still have is how does the > > Consumer know how to render the received encodings with correct > > spatial relationships? > > > > It can't be just based on the Provider's advertised spatial > > coordinates, because the provider doesn't know how the Consumer wants > > to organize it's layout (figures 1 and 2 for examples). And the > > advertised coordinates are overconstrained and not clear how it is > > useful as described in issue 4. > > > > I come back to the consumer layout draft > > [draft-hansen-clue-consumer-layout] which proposes a solution. I think > > we should consider that proposal, for enabling the Consumer to send > > "Area of Display" information to the Provider, so the Provider can > > make switching decisions based on how the Consumer wants to arrange > > its rendering. > > > > What other ideas or comments do you have about section 3.1 in my > > draft? Do the issues 1 through 4 make sense? Is there an easier way to > > solve the problem for this use case example? > > > > Regards, > > > > Mark > > > > > > > > _______________________________________________ > > 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 Wed Jul 17 18:40:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC91021F9B07 for ; Wed, 17 Jul 2013 18:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPuhWbMfORwZ for ; Wed, 17 Jul 2013 18:40:06 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 701BC21F9AD6 for ; Wed, 17 Jul 2013 18:40:06 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 17 Jul 2013 18:40:06 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Jul 2013 18:40:05 -0700 Thread-Topic: [clue] data model for specifying attribute value in Configure message Thread-Index: Ac6DVGIBjNJRqa2NRPKzizu7YyorNAAAqHRw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> In-Reply-To: <51E741C3.6030401@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 01:40:11 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, July 17, 2013 9:16 PM > To: clue@ietf.org > Subject: Re: [clue] data model for specifying attribute value in Configur= e > message >=20 > Hello Mark, >=20 > What is needed is a structure that only allows one set of captureParamete= rs > per mediaCaptureID AND that the chosen set of captureParameters are used > in all CaptureEncodings that reference the mediaCaptureID. This guarantee= s > uniqueness. [Duckworth, Mark] Yes, this is exactly what I was trying to suggest. > Having such a restriction does have side effects. For example: if the Pro= vider > indicates the support of segment and site switched for one CaptureID and > the consumer wants both types of Captures in different capture encodings > then this would not be possible. For this to be possible the Provider wou= ld > have to Advertise one CaptureID with "segment" and another CaptureID > with "site". If this is the case then the question is, is there any point= in having > a list of values in the first place? [Duckworth, Mark] It sounds like you and Paul are both suggesting we remove= this "advertise a choice of values for the Consumer to choose from" mechan= ism from the scene-switch-policy attribute. Instead, just use it like all = the other attributes where the Advertisement indicates the attribute and it= s value. Then we could also simplify the data model, removing the captureP= arameters element. That would be fine with me. > Regards, Christian >=20 >=20 > On 18/07/2013 1:45 AM, Duckworth, Mark wrote: > > Hi Christian, > > > > I think I understand your point, and it does seem like an issue in the = data- > model-schema-00 document, section 22. > > > > > > > > > > > > > > type=3D"captureParametersType" minOccurs=3D"0"/> > > type=3D"encodingParametersType" minOccurs=3D"0"/> > > > > > > > > This structure requires the captureParameters to be specified for each > captureEncodingType, but this isn't what we want. I think it would be be= tter > to have a structure that specifies a mediaCaptureID just once, with just = one > corresponding captureParameters element, but with a list of encodingID an= d > encodingParameters to represent the multiple encodings of the single medi= a > capture. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Sunday, July 14, 2013 11:06 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] data model for specifying attribute value in > >> Configure message > >> > >> Hello Mark, > >> > >> I don't think the rule regarding CSE helps. The configure only lists > >> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having > >> parameters in the Configure is that effectively a CaptureID no longer > >> lists a unique capture. You could in theory have a CaptureID with > >> different sets of attributes. An Advertisement could offer a > >> CaptureID with multiple values and a set of encodings. A consumer > >> could in theory return the same CaptureID multiple times with differen= t > values and the same encoding ID. > >> This would lead to the same CaptureEncoding which would cause > >> referencing issues. > >> > >> Regards, Christian > >> > >> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: > >>> Paul, I agree it doesn't make sense to include different values of > >>> the > >> attribute for the same capture. This is related to the statement in > >> the framework in section 6.2.2 "The Consumer must choose the same > >> value for all the Media Captures in the Capture Scene Entry." So for > >> me, the question is should we devise an XML schema for this such that > >> it is impossible for the Consumer to construct an inconsistent > >> message? Or is it okay to have a schema with potentially redundant > >> information, thus enabling the possibility for the values to be > >> inconsistent? My proposal allows the inconsistency, and I agree it > >> would be better to avoid the redundancy and possibility of inconsisten= cy. > I could make another proposal along those lines later. > >>> Are you saying there are also other problems with attributes that > >>> can be > >> specified in the Configure message? What about specifying the > >> encoding parameters, we agreed on that before didn't we? That is > >> very similar to specifying attribute values. > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Friday, July 12, 2013 5:09 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] data model for specifying attribute value in > >>>> Configure message > >>>> > >>>> I've brought this up before, but I'll try again: > >>>> > >>>> As currently conceived, this mechanism has problems. > >>>> > >>>> Specifically, these attributes apply to captures, not capture-encodi= ngs. > >>>> > >>>> Suppose I configure two different encodings of the same capture, > >>>> and supply different attributes to each. (E.g. one with site > >>>> switching and one with scene > >>>> switching.) > >>>> > >>>> At that point, what is the meaning of the capture? I have two > >>>> encodings which may be showing entirely different content. IMO this > >>>> is > >> nonsense. > >>>> So I think there is a problem with attributes that can be specified > >>>> in the configure. There are a variety of possible solutions. The > >>>> simplest is simply to disallow them. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> > >>>> > >>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: > >>>>> I think the data model is intended to support building a Configure > >>>>> message by using a list of captureEncoding elements. If so, there > >>>>> also needs to be a way to add parameter values of items where the > >>>>> Provider has offered a choice. > >>>>> > >>>>> From the framework: > >>>>> > >>>>> For each Media Capture in the message, the Consumer may also > >>>>> > >>>>> specify the value of any attributes for which the Provider > >>>>> has > >>>>> > >>>>> offered a choice, for example the value for the > >>>>> Scene-switch-policy > >>>>> > >>>>> attribute. > >>>>> > >>>>> Currently, I think Scene-switch-policy is the only attribute in > >>>>> this category. > >>>>> > >>>>> Does it make sense to add an element to do this into the > >>>>> captureEncodingType? This is similar to item 11 in my other list > >>>>> of comments http://www.ietf.org/mail- > >>>> archive/web/clue/current/msg02666.html. > >>>>> Mark > >>>>> From Christian.Groves@nteczone.com Wed Jul 17 20:01:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D10521F9943 for ; Wed, 17 Jul 2013 20:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxZScZZ6BFTC for ; Wed, 17 Jul 2013 20:01:13 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 88DD121F9958 for ; Wed, 17 Jul 2013 20:01:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJdY51F20Ycd/2dsb2JhbAANQwqDOkrARYEpgxcBAQEBAwEBAS8BBRsVBgQGEQsYCRYIBwkDAgECARUfERMGAgEBBRIEh3gFpBKSQo44BgSBP4N7A5QFhQCLAYhHgVYJ Received: from ppp118-209-135-29.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.135.29]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Jul 2013 12:31:09 +0930 Message-ID: <51E75A6C.3090707@nteczone.com> Date: Thu, 18 Jul 2013 13:01:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 03:01:16 -0000 Hello Mary, I did a review of the requirements and Appendix to see if they are met. My comments are below. Sorry for the length of the email but I figured it would be easier for people to read my comment [CNG] along with the requirement. REQMT-1:The solution MUST support a description of the spatial arrangement of source video images sent in video streams which enables a satisfactory reproduction at the receiver of the original scene.This applies to each site in a point to point or a multipoint meeting and refers to the spatial ordering within a site, not to the ordering of images between sites. [CNG] Supported via Capture Area attribute. Use case point to point symmetric, and all other use cases. REQMT-1a:The solution MUST support a means of allowing the preservation of the order of images in the captured scene.For example, if John is to Susan's right in the image capture, John is also to Susan's right in the rendered image. [CNG] Supported via Capture Area attribute. REQMT-1b:The solution MUST support a means of allowing the preservation of order of images in the scene in two dimensions - horizontal and vertical. [CNG] Supported via Capture Area attribute. REQMT-1c:The solution MUST support a means to identify the point of capture of individual video captures in three dimensions. [CNG] Supported via Point of capture attribute. REQMT-1d:The solution MUST support a means to identify the extent of individual video captures in three dimensions. [CNG] Partial Capture area attribute allows the specification of a plane of capture in 3 dimensions. However depth of the capture (needed for a 3D area) is not supported. REQMT-2:The solution MUST support a description of the spatial arrangement of captured source audio sent in audio streams which enables a satisfactory reproduction at the receiver in a spatially correct manner.This applies to each site in a point to point or a multipoint meeting and refers to the spatial ordering within a site, not the ordering of channels between sites. [CNG] Supported Via Capture Area attribute. Use case point to point symmetric, and all use cases, especially heterogeneous. REQMT-2a:The solution MUST support a means of preserving the spatial order of audio in the captured scene.For example, if John sounds as if he is at Susan's right in the captured audio, John voice is also placed at Susan's right in the rendered image. [CNG] Supported Via Capture Area attribute. REQMT-2b:The solution MUST support a means to identify the number and spatial arrangement of audio channels including monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. [CNG] Partial the Audio Channel Format attribute currently only supports 搈ono and 搒tereo. It doesn抰 support the 3.0 format. REQMT-2c:The solution MUST NOT preclude the use of binaural audio.[Edt. This is an outstanding issue.Text will be changed when the issue is resolved.] [CNG] Partial? Binaural isn抰 mentioned in the framework so isn抰 precluded as such. There is no indication in CLUE recording a binaural capture. REQMT-2d:The solution MUST support a means to identify the point of capture of individual audio captures in three dimensions. [CNG] Supported via Point of capture attribute. REQMT-2e:The solution MUST support a means to identify the extent of individual audio captures in three dimensions. [CNG] Partial The Capture area attribute is based on capturing a plane in Cartesian space. There is no depth parameter. Whether the plane concept holds for audio like it does video needs further thought. REQMT-3:The solution MUST support a mechanism to enable a satisfactory spatial matching between audio and video streams coming from the same endpoints. [CNG] Supported - The given that an Advertiser places captures in a particular scene it is possible to indicate audio and video streams are from the same endpoint. Use case is point to point symmetric, and all use cases. REQMT-3a:The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position. [CNG] Supported (Partial?) It is possible to deduce that audio and video relate to the same capture area in a scene by analysing the Capture Area parameters. It is possible to relate individual audio captures to video captures if the Advertisement is constructed in a limited way. However its not possible to deduce the relationships between individual captures by utilising the Scene, CSE and capture concepts. CSE only relate to one media type. So it抯 not possible to link audio CSEs to video CSEs. REQMT-3b:The solution MUST enable individual audio streams to be rendered in any desired spatial position. [CNG] Supported? I think its assumed that a Consumer can do whatever it likes with respect to rendering decisions. Ultimately that抯 local policy. Edt: Rendering is an open issue. Text will be changed when it is resolved.] REQMT-4:The solution MUST enable interoperability between endpoints that have a different number of similar devices. For example, one endpoint may have 1 screen, 1 speaker, 1 camera, 1 mic, and another endpoint may have 3 screens, 2 speakers, 3 cameras and 2 mics.Or, in a multi-point conference, one endpoint may have one screen, another may have 2 screens and a third may have 3 screens.This includes endpoints where the number of devices of a given type is zero. Use case is asymmetric point to point and multipoint. [CNG] Supported CLUE enables different capture capabilities to be signalled. It makes no assumption as to the rendering. REQMT-5:The solution MUST support means of enabling interoperability between telepresence endpoints where cameras are of different picture aspect ratios. [CNG] Supported CLUE doesn抰 describe 揳spect ratio but allows different capture areas to be defined. This is a means of describing aspect ratio. REQMT-6:The solution MUST provide scaling information which enables rendering of a video image at the actual size of the captured scene. [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture and Scene Scale allow this. REQMT-7:The solution MUST support means of enabling interoperability between telepresence endpoints where displays are of different resolutions. [CNG] Supported? CLUE allow encoding parameters to be associated with captures which could state the resolution of the captured image. However there is no way to indicate 揹isplay resolution. Perhaps the requirement needs to be reworded? REQMT-8:The solution MUST support methods for handling different bit rates in the same conference. [CNG] Supported CLUE allow encoding parameters to be associated with captures which could state the bit rate. REQMT-9:The solution MUST support means of enabling interoperability between endpoints that send and receive different numbers of media streams. Use case heterogeneous and multipoint. [CNG] Supported CLUE allows different numbers of captures to be sent. REQMT-10:The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. [CNG] Supported The support of a CLUE channel will be negotiated between endpoints. From the current signalling draft it seems a basic set of media can be established without CLUE. Endpoints that don抰 support CLUE obviously won抰 be able to determine spatial information etc REQMT-11:The solution MUST support a mechanism for determining whether or not an endpoint or MCU is capable of telepresence extensions. [CNG] Supported? The negotiation of a CLUE channel via SDP is one method in the signalling draft. Another indication at the SIP level may be beneficial such as a feature tag. This is yet to be documented. REQMT-12:The solution MUST support a means to enable more than two sites to participate in a teleconference. Use case multipoint. [CNG] Partial This is on the agenda and there抯 basic support i.e. via the composed attribute and 搒cene-switch-policy CSE attribute. However no method is yet defined to keep the source information. REQMT-13:The solution MUST support both transcoding and switching approaches to providing multipoint conferences. [CNG] Supported CLUE supports these two methods. However further work is needed on the details. REQMT-14:The solution MUST support mechanisms to make possible for either or both site switching or segment switching.[Edt: This needs rewording.Deferred until layout discussion is resolved.] [CNG] Partial The 搒cene-switch-policy CSE attribute supports this to some level but further work is needed in this area. REQMT-15:The solution MUST support mechanisms for presentations in such a way that: *Presentations can have different sources *Presentations can be seen by all *There can be variation in placement, number and size of Presentations [CNG] Partial CLUE allows an endpoint whether the capture is related to a presentation or not through the use of the presentation attribute. The spatial attributes (i.e. capture area) allows the place and size to be indicated. The number can be inferred from the number of captures. CLUE doesn抰 have any policy on who can see the presentations. The CLUE Advertisement mechanism may include presentation captures to all people within the conference. Perhaps the 2^nd bullet can be removed or clarified that its not related to policy? REQMT-16:The solution MUST include extensibility mechanisms. [CNG] Supported? whilst not explicitly documented I think there抯 general agreement this is needed. REQMT-17:The solution must support a mechanism for allowing information about media captures to change during a conference. [CNG] Supported? Keeping the CLUE signalling channel open would allow for this and people seem in agreement this should be possible. Further detailed work is needed in the signalling draft to describe this. i.e. incremental vs full updates. Interaction with bearer signalling (i.e. SDP O/A) etc. REQMT-18:The solution MUST provide a mechanism for the secure exchange of information about the media captures. [CNG] Partial? It is assumed that CLUE will operate over a DTLS/SCTP however there抯 no documentation regarding CLUE security. Appendix A. open issues OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural audio is unresolved, and the "MUST NOT preclude" language in this requirement is problematic.The authors believe this requirement needs to be either changed or withdrawn, depending on how the issue is resolved. [CNG] Not supported - This is still unresolved. OPEN-2Reference to Rendering [REQMT-3b] This is the only requirement which refers to rendering.It may also be empty, since receivers can rendering audio captures as they wish. This is deferred until broader discussion on rendering requirements is concluded. [CNG] I think we should frame the requirements with regards to captures as that抯 the way the framework is written. Perhaps some text to say that rendering is based on the receivers local policy. OPEN-3Conference modes [REQMT-14] This wording of this requirement is problematic in part because the conference modes (site switching and segment switching) are not defined.It at least needs rewording.This is deferred until broader discussion on layout is concluded. [CNG] Yes this is still open. OPEN-4Need to capture requirement that attributes can change at any time during the call. [CNG] Yes although it seems REQMT-17 covers this. OPEN-5Need to add requirement for three dimensions in the right place [CNG] Requirements 1d and 2e do capture an aspect of 3D. OPEN-6Multi-view, is there a requirement needed? [CNG] Even if there抯 no requirement we appear to support it because we allow both the capture area and capture point to be sent for captures. An Advertiser could describe multiple capture points capturing the same area of capture. Regards, Christian On 17/07/2013 6:07 AM, Mary Barnes wrote: > There really were no changes other than to refresh this draft. I was > going to extend the security section with more detail, but I really > can't add much more detail without referencing things that are defined > in the framework. So, I think the next step is for me to work with > Mark on the security for the framework. > > There are some open issues identified in the appendix of this document > that we need to figure out whether they are issues that need > resolution for this document. I will open issues in the tracker and we > can discuss each one and perhaps make some decisions before Berlin. > > We also need to consider whether the current framework meets these > requirements. If some requirements are not met, we need to decide > whether it's because they'll be met by the solution documents or won't > be met at all. In which case, we need to decide whether we actually > need them for the solution. > > Regards, > Mary. > > > On Tue, Jul 16, 2013 at 11:29 AM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple streams for > tElepresence Working Group of the IETF. > > Title : Requirements for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : draft-ietf-clue-telepresence-requirements-04.txt > Pages : 14 > Date : 2013-07-15 > > 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 datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft > > directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Jul 17 20:09:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2386221F9A16 for ; Wed, 17 Jul 2013 20:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfRF1NxX7BWU for ; Wed, 17 Jul 2013 20:09:42 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id A6DE921F99F6 for ; Wed, 17 Jul 2013 20:09:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJdb51F20Ycd/2dsb2JhbAANTYM6SsBFgSmDFwEBAQEDAQEBJBEbGwoNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQEFEod8BaQYkkKOSIE5BoN1A6QGiEeBXw Received: from ppp118-209-135-29.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.135.29]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Jul 2013 12:39:36 +0930 Message-ID: <51E75C69.2040301@nteczone.com> Date: Thu, 18 Jul 2013 13:09:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 03:09:44 -0000 Hello Mark, Actually I'm torn on this one. Being able to provide a list of values and have the Consumer choose seems like a good capability to be built into the protocol. However the implementation becomes problematic and adds complications. I had thought about the Consumer appending the mediaCaptureID i.e. 1a, 1b, 1c if it wants multiple instances but how would that work with STS? Also what would be the interaction when there are multiple set of attributes that have multiple values? Without a simple way to introduce it may be simpler to KISS and remove the captureParameters element. However if someone can come up with a way to support it I'm all ears :-). Regards, Christian On 18/07/2013 11:40 AM, Duckworth, Mark wrote: >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Wednesday, July 17, 2013 9:16 PM >> To: clue@ietf.org >> Subject: Re: [clue] data model for specifying attribute value in Configure >> message >> >> Hello Mark, >> >> What is needed is a structure that only allows one set of captureParameters >> per mediaCaptureID AND that the chosen set of captureParameters are used >> in all CaptureEncodings that reference the mediaCaptureID. This guarantees >> uniqueness. > [Duckworth, Mark] Yes, this is exactly what I was trying to suggest. > >> Having such a restriction does have side effects. For example: if the Provider >> indicates the support of segment and site switched for one CaptureID and >> the consumer wants both types of Captures in different capture encodings >> then this would not be possible. For this to be possible the Provider would >> have to Advertise one CaptureID with "segment" and another CaptureID >> with "site". If this is the case then the question is, is there any point in having >> a list of values in the first place? > [Duckworth, Mark] It sounds like you and Paul are both suggesting we remove this "advertise a choice of values for the Consumer to choose from" mechanism from the scene-switch-policy attribute. Instead, just use it like all the other attributes where the Advertisement indicates the attribute and its value. Then we could also simplify the data model, removing the captureParameters element. That would be fine with me. > >> Regards, Christian >> >> >> On 18/07/2013 1:45 AM, Duckworth, Mark wrote: >>> Hi Christian, >>> >>> I think I understand your point, and it does seem like an issue in the data- >> model-schema-00 document, section 22. >>> >>> >>> >>> >>> >>> > type="captureParametersType" minOccurs="0"/> >>> > type="encodingParametersType" minOccurs="0"/> >>> >>> >>> >>> This structure requires the captureParameters to be specified for each >> captureEncodingType, but this isn't what we want. I think it would be better >> to have a structure that specifies a mediaCaptureID just once, with just one >> corresponding captureParameters element, but with a list of encodingID and >> encodingParameters to represent the multiple encodings of the single media >> capture. >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Sunday, July 14, 2013 11:06 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] data model for specifying attribute value in >>>> Configure message >>>> >>>> Hello Mark, >>>> >>>> I don't think the rule regarding CSE helps. The configure only lists >>>> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having >>>> parameters in the Configure is that effectively a CaptureID no longer >>>> lists a unique capture. You could in theory have a CaptureID with >>>> different sets of attributes. An Advertisement could offer a >>>> CaptureID with multiple values and a set of encodings. A consumer >>>> could in theory return the same CaptureID multiple times with different >> values and the same encoding ID. >>>> This would lead to the same CaptureEncoding which would cause >>>> referencing issues. >>>> >>>> Regards, Christian >>>> >>>> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>>>> Paul, I agree it doesn't make sense to include different values of >>>>> the >>>> attribute for the same capture. This is related to the statement in >>>> the framework in section 6.2.2 "The Consumer must choose the same >>>> value for all the Media Captures in the Capture Scene Entry." So for >>>> me, the question is should we devise an XML schema for this such that >>>> it is impossible for the Consumer to construct an inconsistent >>>> message? Or is it okay to have a schema with potentially redundant >>>> information, thus enabling the possibility for the values to be >>>> inconsistent? My proposal allows the inconsistency, and I agree it >>>> would be better to avoid the redundancy and possibility of inconsistency. >> I could make another proposal along those lines later. >>>>> Are you saying there are also other problems with attributes that >>>>> can be >>>> specified in the Configure message? What about specifying the >>>> encoding parameters, we agreed on that before didn't we? That is >>>> very similar to specifying attribute values. >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Friday, July 12, 2013 5:09 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>> Configure message >>>>>> >>>>>> I've brought this up before, but I'll try again: >>>>>> >>>>>> As currently conceived, this mechanism has problems. >>>>>> >>>>>> Specifically, these attributes apply to captures, not capture-encodings. >>>>>> >>>>>> Suppose I configure two different encodings of the same capture, >>>>>> and supply different attributes to each. (E.g. one with site >>>>>> switching and one with scene >>>>>> switching.) >>>>>> >>>>>> At that point, what is the meaning of the capture? I have two >>>>>> encodings which may be showing entirely different content. IMO this >>>>>> is >>>> nonsense. >>>>>> So I think there is a problem with attributes that can be specified >>>>>> in the configure. There are a variety of possible solutions. The >>>>>> simplest is simply to disallow them. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>>>> I think the data model is intended to support building a Configure >>>>>>> message by using a list of captureEncoding elements. If so, there >>>>>>> also needs to be a way to add parameter values of items where the >>>>>>> Provider has offered a choice. >>>>>>> >>>>>>> From the framework: >>>>>>> >>>>>>> For each Media Capture in the message, the Consumer may also >>>>>>> >>>>>>> specify the value of any attributes for which the Provider >>>>>>> has >>>>>>> >>>>>>> offered a choice, for example the value for the >>>>>>> Scene-switch-policy >>>>>>> >>>>>>> attribute. >>>>>>> >>>>>>> Currently, I think Scene-switch-policy is the only attribute in >>>>>>> this category. >>>>>>> >>>>>>> Does it make sense to add an element to do this into the >>>>>>> captureEncodingType? This is similar to item 11 in my other list >>>>>>> of comments http://www.ietf.org/mail- >>>>>> archive/web/clue/current/msg02666.html. >>>>>>> Mark >>>>>>> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From john@jlc.net Thu Jul 18 04:16:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C9121E80DE for ; Thu, 18 Jul 2013 04:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.919 X-Spam-Level: X-Spam-Status: No, score=-105.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBv-QN-TLysB for ; Thu, 18 Jul 2013 04:16:03 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7671621E80CA for ; Thu, 18 Jul 2013 04:16:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4B02233C2C; Thu, 18 Jul 2013 07:16:02 -0400 (EDT) Date: Thu, 18 Jul 2013 07:16:02 -0400 From: John Leslie To: Christian Groves Message-ID: <20130718111602.GD5411@verdi> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E75A6C.3090707@nteczone.com> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 11:16:08 -0000 Christian Groves wrote: > > I did a review of the requirements and Appendix to see if they are met. >... > > REQMT-2:The solution MUST support a description of the spatial > arrangement of captured source audio sent in audio streams > which enables a satisfactory reproduction at the receiver > in a spatially correct manner.This applies to each site > in a point to point or a multipoint meeting and refers to > the spatial ordering within a site, not the ordering of > channels between sites. > > [CNG] Supported ? Via Capture Area attribute... Um... audio isn't two-dimensinal... > REQMT-2a:The solution MUST support a means of preserving > the spatial order of audio in the captured > scene.For example, if John sounds as if he is > at Susan's right in the captured audio, John > voice is also placed at Susan's right in the > rendered image. This REQMT could use some work... > REQMT-2e:The solution MUST support a means to identify > the extent of individual audio captures in > three dimensions. (I don't know what that means.) > [CNG] Partial ? The Capture area attribute is based on capturing a plane > in Cartesian space. There is no depth parameter. Whether the plane > concept holds for audio like it does video needs further thought. It doesn't. A microphone can be modeled by a capture point and direction, plus a sensitivity pattern; but no actual sensitivity pattern resembles a camera's pattern. Furthermore, no X/Y information survives, but distance from audio source to the microphone becomes significant (about one millisecond per foot). > REQMT-3b:The solution MUST enable individual audio > streams to be rendered in any desired spatial > position. > > [CNG] Supported? ? I think its assumed that a Consumer can do whatever > it likes with respect to rendering decisions. Ultimately that?s local > policy. I agree it's local policy. > OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural > audio is unresolved, and the "MUST NOT preclude" language in > this requirement is problematic.The authors believe this > requirement needs to be either changed or withdrawn, > depending on how the issue is resolved. > > [CNG] Not supported - This is still unresolved. Binaural audio works fairly well when the listener's head is stationary. Alas, it won't be. -- John Leslie From pkyzivat@alum.mit.edu Thu Jul 18 07:42:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890421E8100 for ; Thu, 18 Jul 2013 07:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZUoO7O4IY6r for ; Thu, 18 Jul 2013 07:42:24 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 4414821E80F5 for ; Thu, 18 Jul 2013 07:42:24 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id 1oga1m00617dt5G56qiPyw; Thu, 18 Jul 2013 14:42:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 1qiP1m00S3ZTu2S3ZqiPm5; Thu, 18 Jul 2013 14:42:23 +0000 Message-ID: <51E7FECE.7000607@alum.mit.edu> Date: Thu, 18 Jul 2013 10:42:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> In-Reply-To: <51E75A6C.3090707@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374158543; bh=FI0sOzvYx/lNJJqakSCDh/l3Rzywgx9cqnmpX+k9YOg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LQqYjWxxpuNA35e4NG9/MF6Vrjgo3xgXw8Z7aPLI8Vd5W65Pal1liHly/+iQoj2xW mIaAjznFV+GCkgRPQrJ5LbGT2kWH4JSpFFXcB+M+uyVnXS9xyD0L94uvrmH7QJCSVp MceNQsSAKf2pX8K1mDTGeOSwCVgkpEg2HQkTfjSVoqcO+17o2GYS1i/eg8FgVu2Fhw PVDbaaliYx8t8V6UuHrJJCCyMkVADtM243ardlEszzJlHDnOa/HOAJ2ZgNyevjyp5w RpXlJR8YJJ/BT8350GGPJuLMP9jVolzuOSt0hROh/ao3Wf7q3pzbLyhGw5LE4KIWja QWoogELX5ZIGQ== Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:42:28 -0000 Christian, You raise a point that has bothered me for some time: We describe the spatial attributes of a capture by point of capture and area of capture (a quadrilateral). Implicitly this describes an unbounded pyramid. In reality, it is bounded by the geometry of the room and the stuff in it, but we don't have that info. This pyramid may be meaningful in some sense for video, though we lack other information such as depth of field. But as John replied, I guess it means very little for audio. The fundamental question is: does this provide sufficient information for the consumer to properly adapt the received media to his available equipment? I don't know the answer to that, but I suspect that it will allow some approximation, but probably not enough to do the best possible job. Is there more that we ought to be providing to help with that job? Or does doing more provide diminishing returns? Thanks, Paul On 7/17/13 11:01 PM, Christian Groves wrote: > Hello Mary, > > I did a review of the requirements and Appendix to see if they are met. > My comments are below. Sorry for the length of the email but I figured > it would be easier for people to read my comment [CNG] along with the > requirement. > > REQMT-1:The solution MUST support a description of the spatial > > arrangement of source video images sent in video streams > > which enables a satisfactory reproduction at the receiver > > of the original scene.This applies to each site in a > > point to point or a multipoint meeting and refers to the > > spatial ordering within a site, not to the ordering of > > images between sites. > > [CNG] Supported via Capture Area attribute. > > Use case point to point symmetric, and all other use cases. > > REQMT-1a:The solution MUST support a means of allowing > > the preservation of the order of images in the > > captured scene.For example, if John is to > > Susan's right in the image capture, John is > > also to Susan's right in the rendered image. > > [CNG] Supported via Capture Area attribute. > > REQMT-1b:The solution MUST support a means of allowing > > the preservation of order of images in the > > scene in two dimensions - horizontal and > > vertical. > > [CNG] Supported via Capture Area attribute. > > REQMT-1c:The solution MUST support a means to identify > > the point of capture of individual video > > captures in three dimensions. > > [CNG] Supported via Point of capture attribute. > > REQMT-1d:The solution MUST support a means to identify > > the extent of individual video captures in > > three dimensions. > > [CNG] Partial Capture area attribute allows the specification of a > plane of capture in 3 dimensions. However depth of the capture (needed > for a 3D area) is not supported. > > REQMT-2:The solution MUST support a description of the spatial > > arrangement of captured source audio sent in audio streams > > which enables a satisfactory reproduction at the receiver > > in a spatially correct manner.This applies to each site > > in a point to point or a multipoint meeting and refers to > > the spatial ordering within a site, not the ordering of > > channels between sites. > > [CNG] Supported Via Capture Area attribute. > > Use case point to point symmetric, and all use cases, > > especially heterogeneous. > > REQMT-2a:The solution MUST support a means of preserving > > the spatial order of audio in the captured > > scene.For example, if John sounds as if he is > > at Susan's right in the captured audio, John > > voice is also placed at Susan's right in the > > rendered image. > > [CNG] Supported Via Capture Area attribute. > > REQMT-2b:The solution MUST support a means to identify > > the number and spatial arrangement of audio > > channels including monaural, stereophonic > > (2.0), and 3.0 (left, center, right) audio > > channels. > > [CNG] Partial the Audio Channel Format attribute currently only > supports 搈ono and 搒tereo. It doesn抰 support the 3.0 format. > > REQMT-2c:The solution MUST NOT preclude the use of > > binaural audio.[Edt. This is an outstanding > > issue.Text will be changed when the issue is > > resolved.] > > [CNG] Partial? Binaural isn抰 mentioned in the framework so isn抰 > precluded as such. There is no indication in CLUE recording a binaural > capture. > > REQMT-2d:The solution MUST support a means to identify > > the point of capture of individual audio > > captures in three dimensions. > > [CNG] Supported via Point of capture attribute. > > REQMT-2e:The solution MUST support a means to identify > > the extent of individual audio captures in > > three dimensions. > > [CNG] Partial The Capture area attribute is based on capturing a plane > in Cartesian space. There is no depth parameter. Whether the plane > concept holds for audio like it does video needs further thought. > > REQMT-3:The solution MUST support a mechanism to enable a > > satisfactory spatial matching between audio and video > > streams coming from the same endpoints. > > [CNG] Supported - The given that an Advertiser places captures in a > particular scene it is possible to indicate audio and video streams are > from the same endpoint. > > Use case is point to point symmetric, and all use cases. > > REQMT-3a:The solution MUST enable individual audio > > streams to be associated with one or more video > > image captures, and individual video image > > captures to be associated with one or more > > audio captures, for the purpose of rendering > > proper position. > > [CNG] Supported (Partial?) It is possible to deduce that audio and > video relate to the same capture area in a scene by analysing the > Capture Area parameters. It is possible to relate individual audio > captures to video captures if the Advertisement is constructed in a > limited way. However its not possible to deduce the relationships > between individual captures by utilising the Scene, CSE and capture > concepts. CSE only relate to one media type. So it抯 not possible to > link audio CSEs to video CSEs. > > REQMT-3b:The solution MUST enable individual audio > > streams to be rendered in any desired spatial > > position. > > [CNG] Supported? I think its assumed that a Consumer can do whatever > it likes with respect to rendering decisions. Ultimately that抯 local > policy. > > Edt: Rendering is an open issue. Text will > > be changed when it is resolved.] > > REQMT-4:The solution MUST enable interoperability between > > endpoints that have a different number of similar devices. > > For example, one endpoint may have 1 screen, 1 speaker, 1 > > camera, 1 mic, and another endpoint may have 3 screens, 2 > > speakers, 3 cameras and 2 mics.Or, in a multi-point > > conference, one endpoint may have one screen, another may > > have 2 screens and a third may have 3 screens.This > > includes endpoints where the number of devices of a given > > type is zero. > > Use case is asymmetric point to point and multipoint. > > [CNG] Supported CLUE enables different capture capabilities to be > signalled. It makes no assumption as to the rendering. > > REQMT-5:The solution MUST support means of enabling > > interoperability between telepresence endpoints where > > cameras are of different picture aspect ratios. > > [CNG] Supported CLUE doesn抰 describe 揳spect ratio but allows > different capture areas to be defined. This is a means of describing > aspect ratio. > > REQMT-6:The solution MUST provide scaling information which > > enables rendering of a video image at the actual size of > > the captured scene. > > [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture > and Scene Scale allow this. > > REQMT-7:The solution MUST support means of enabling > > interoperability between telepresence endpoints where > > displays are of different resolutions. > > [CNG] Supported? CLUE allow encoding parameters to be associated with > captures which could state the resolution of the captured image. However > there is no way to indicate 揹isplay resolution. Perhaps the > requirement needs to be reworded? > > REQMT-8:The solution MUST support methods for handling different > > bit rates in the same conference. > > [CNG] Supported CLUE allow encoding parameters to be associated with > captures which could state the bit rate. > > REQMT-9:The solution MUST support means of enabling > > interoperability between endpoints that send and receive > > different numbers of media streams. > > Use case heterogeneous and multipoint. > > [CNG] Supported CLUE allows different numbers of captures to be sent. > > REQMT-10:The solution MUST make it possible for endpoints without > > support for telepresence extensions to participate in a > > telepresence session with those that do. > > [CNG] Supported The support of a CLUE channel will be negotiated > between endpoints. From the current signalling draft it seems a basic > set of media can be established without CLUE. Endpoints that don抰 > support CLUE obviously won抰 be able to determine spatial information etc > > REQMT-11:The solution MUST support a mechanism for determining > > whether or not an endpoint or MCU is capable of > > telepresence extensions. > > [CNG] Supported? The negotiation of a CLUE channel via SDP is one > method in the signalling draft. Another indication at the SIP level may > be beneficial such as a feature tag. This is yet to be documented. > > REQMT-12:The solution MUST support a means to enable more than two > > sites to participate in a teleconference. > > Use case multipoint. > > [CNG] Partial This is on the agenda and there抯 basic support i.e. via > the composed attribute and 搒cene-switch-policy CSE attribute. However > no method is yet defined to keep the source information. > > REQMT-13:The solution MUST support both transcoding and switching > > approaches to providing multipoint conferences. > > [CNG] Supported CLUE supports these two methods. However further work > is needed on the details. > > REQMT-14:The solution MUST support mechanisms to make possible for > > either or both site switching or segment switching.[Edt: > > This needs rewording.Deferred until layout discussion is > > resolved.] > > [CNG] Partial The 搒cene-switch-policy CSE attribute supports this to > some level but further work is needed in this area. > > REQMT-15:The solution MUST support mechanisms for presentations in > > such a way that: > > *Presentations can have different sources > > *Presentations can be seen by all > > *There can be variation in placement, number and size of > > Presentations > > [CNG] Partial CLUE allows an endpoint whether the capture is related > to a presentation or not through the use of the presentation attribute. > The spatial attributes (i.e. capture area) allows the place and size to > be indicated. The number can be inferred from the number of captures. > CLUE doesn抰 have any policy on who can see the presentations. The CLUE > Advertisement mechanism may include presentation captures to all people > within the conference. Perhaps the 2^nd bullet can be removed or > clarified that its not related to policy? > > REQMT-16:The solution MUST include extensibility mechanisms. > > [CNG] Supported? whilst not explicitly documented I think there抯 > general agreement this is needed. > > REQMT-17:The solution must support a mechanism for allowing > > information about media captures to change during a > > conference. > > [CNG] Supported? Keeping the CLUE signalling channel open would allow > for this and people seem in agreement this should be possible. Further > detailed work is needed in the signalling draft to describe this. i.e. > incremental vs full updates. Interaction with bearer signalling (i.e. > SDP O/A) etc. > > REQMT-18:The solution MUST provide a mechanism for the secure > > exchange of information about the media captures. > > [CNG] Partial? It is assumed that CLUE will operate over a DTLS/SCTP > however there抯 no documentation regarding CLUE security. > > Appendix A. open issues > > OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural > > audio is unresolved, and the "MUST NOT preclude" language in > > this requirement is problematic.The authors believe this > > requirement needs to be either changed or withdrawn, > > depending on how the issue is resolved. > > [CNG] Not supported - This is still unresolved. > > OPEN-2Reference to Rendering [REQMT-3b] This is the only > > requirement which refers to rendering.It may also be empty, > > since receivers can rendering audio captures as they wish. > > This is deferred until broader discussion on rendering > > requirements is concluded. > > [CNG] I think we should frame the requirements with regards to captures > as that抯 the way the framework is written. Perhaps some text to say > that rendering is based on the receivers local policy. > > OPEN-3Conference modes [REQMT-14] This wording of this requirement > > is problematic in part because the conference modes (site > > switching and segment switching) are not defined.It at > > least needs rewording.This is deferred until broader > > discussion on layout is concluded. > > [CNG] Yes this is still open. > > OPEN-4Need to capture requirement that attributes can change at any > > time during the call. > > [CNG] Yes although it seems REQMT-17 covers this. > > OPEN-5Need to add requirement for three dimensions in the right > > place > > [CNG] Requirements 1d and 2e do capture an aspect of 3D. > > OPEN-6Multi-view, is there a requirement needed? > > [CNG] Even if there抯 no requirement we appear to support it because we > allow both the capture area and capture point to be sent for captures. > An Advertiser could describe multiple capture points capturing the same > area of capture. > > > Regards, Christian > > On 17/07/2013 6:07 AM, Mary Barnes wrote: >> There really were no changes other than to refresh this draft. I was >> going to extend the security section with more detail, but I really >> can't add much more detail without referencing things that are defined >> in the framework. So, I think the next step is for me to work with >> Mark on the security for the framework. >> >> There are some open issues identified in the appendix of this document >> that we need to figure out whether they are issues that need >> resolution for this document. I will open issues in the tracker and we >> can discuss each one and perhaps make some decisions before Berlin. >> >> We also need to consider whether the current framework meets these >> requirements. If some requirements are not met, we need to decide >> whether it's because they'll be met by the solution documents or won't >> be met at all. In which case, we need to decide whether we actually >> need them for the solution. >> >> Regards, >> Mary. >> >> >> On Tue, Jul 16, 2013 at 11:29 AM, > > wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : Requirements for Telepresence Multi-Streams >> Author(s) : Allyn Romanow >> Stephen Botzko >> Mary Barnes >> Filename : draft-ietf-clue-telepresence-requirements-04.txt >> Pages : 14 >> Date : 2013-07-15 >> >> 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 datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft >> >> directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Jul 18 08:04:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B4211E8180 for ; Thu, 18 Jul 2013 08:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za8t-Vt8ges5 for ; Thu, 18 Jul 2013 08:04:21 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66D21E810D for ; Thu, 18 Jul 2013 08:02:12 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id 1nQB1m0020mv7h05Dr27mU; Thu, 18 Jul 2013 15:02:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 1r261m01A3ZTu2S3Xr26GT; Thu, 18 Jul 2013 15:02:06 +0000 Message-ID: <51E8036D.4040704@alum.mit.edu> Date: Thu, 18 Jul 2013 11:02:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> In-Reply-To: <51E741C3.6030401@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374159727; bh=zAtzI1D0b22EUh9hmdQn+erL/+HY9p/dB/iVefba0jI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OFpGCx1FCKk7rPDLxlRiVApwqm1H/39yFCOxhvl/ffe6FWDMsXKWondmsbfBpM+Xo sbEMyJuwzkn+mXUDRluSitcr0882+f0XrM0eAXt6a8mE+hR9r5iijFJe+V0QEcWJ7u LFNk0lYBvxNIWUAIu243f8rXQ/WIzNrZ1yTFHqL+Se24AM9SAcMo3A/bnEC0RQzkT9 +4r6mHOZLQC2B1YLhsC+sElOSVFL6JW3xXKvDBwTkdMLcbIPVTd2Z32Ae7SGFF0Evw Bz65+H7FJY1YkvoY9pfkyEtSYSxHRn1fqTXq9E6vwM25iw7x5SGI8IhUJdKcRbQQY9 oVAZ1eHWBhrow== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 15:04:26 -0000 On 7/17/13 9:15 PM, Christian Groves wrote: > Hello Mark, > > What is needed is a structure that only allows one set of > captureParameters per mediaCaptureID AND that the chosen set of > captureParameters are used in all CaptureEncodings that reference the > mediaCaptureID. This guarantees uniqueness. > > Having such a restriction does have side effects. For example: if the > Provider indicates the support of segment and site switched for one > CaptureID and the consumer wants both types of Captures in different > capture encodings then this would not be possible. Another consequence of this is that putting the switching attribute on a CSE makes little sense. Rather the attribute needs to be on the individual captures. (Putting it on the CSE causes trouble if the same capture appears in more than one CSE with different attribute values.) Thanks, Paul > For this to be > possible the Provider would have to Advertise one CaptureID with > "segment" and another CaptureID with "site". If this is the case then > the question is, is there any point in having a list of values in the > first place? > > Regards, Christian > > > On 18/07/2013 1:45 AM, Duckworth, Mark wrote: >> Hi Christian, >> >> I think I understand your point, and it does seem like an issue in the >> data-model-schema-00 document, section 22. >> >> >> >> >> >> >> > minOccurs="0"/> >> > type="encodingParametersType" minOccurs="0"/> >> >> >> >> >> This structure requires the captureParameters to be specified for each >> captureEncodingType, but this isn't what we want. I think it would be >> better to have a structure that specifies a mediaCaptureID just once, >> with just one corresponding captureParameters element, but with a list >> of encodingID and encodingParameters to represent the multiple >> encodings of the single media capture. >> >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Christian Groves >>> Sent: Sunday, July 14, 2013 11:06 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] data model for specifying attribute value in >>> Configure >>> message >>> >>> Hello Mark, >>> >>> I don't think the rule regarding CSE helps. The configure only lists the >>> CaptureID/EncodingID, no CSE or SceneID. The trouble with having >>> parameters in the Configure is that effectively a CaptureID no longer >>> lists a >>> unique capture. You could in theory have a CaptureID with different >>> sets of >>> attributes. An Advertisement could offer a CaptureID with multiple >>> values >>> and a set of encodings. A consumer could in theory return the same >>> CaptureID multiple times with different values and the same encoding ID. >>> This would lead to the same CaptureEncoding which would cause >>> referencing >>> issues. >>> >>> Regards, Christian >>> >>> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>>> Paul, I agree it doesn't make sense to include different values of the >>> attribute for the same capture. This is related to the statement in the >>> framework in section 6.2.2 "The Consumer must choose the same value for >>> all the Media Captures in the Capture Scene Entry." So for me, the >>> question >>> is should we devise an XML schema for this such that it is impossible >>> for the >>> Consumer to construct an inconsistent message? Or is it okay to have a >>> schema with potentially redundant information, thus enabling the >>> possibility >>> for the values to be inconsistent? My proposal allows the >>> inconsistency, and >>> I agree it would be better to avoid the redundancy and possibility of >>> inconsistency. I could make another proposal along those lines later. >>>> Are you saying there are also other problems with attributes that >>>> can be >>> specified in the Configure message? What about specifying the encoding >>> parameters, we agreed on that before didn't we? That is very similar to >>> specifying attribute values. >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Friday, July 12, 2013 5:09 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>> Configure message >>>>> >>>>> I've brought this up before, but I'll try again: >>>>> >>>>> As currently conceived, this mechanism has problems. >>>>> >>>>> Specifically, these attributes apply to captures, not >>>>> capture-encodings. >>>>> >>>>> Suppose I configure two different encodings of the same capture, and >>>>> supply different attributes to each. (E.g. one with site switching >>>>> and one with scene >>>>> switching.) >>>>> >>>>> At that point, what is the meaning of the capture? I have two >>>>> encodings which may be showing entirely different content. IMO this is >>> nonsense. >>>>> So I think there is a problem with attributes that can be specified >>>>> in the configure. There are a variety of possible solutions. The >>>>> simplest is simply to disallow them. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> >>>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>>> I think the data model is intended to support building a Configure >>>>>> message by using a list of captureEncoding elements. If so, there >>>>>> also needs to be a way to add parameter values of items where the >>>>>> Provider has offered a choice. >>>>>> >>>>>> From the framework: >>>>>> >>>>>> For each Media Capture in the message, the Consumer may also >>>>>> >>>>>> specify the value of any attributes for which the Provider has >>>>>> >>>>>> offered a choice, for example the value for the >>>>>> Scene-switch-policy >>>>>> >>>>>> attribute. >>>>>> >>>>>> Currently, I think Scene-switch-policy is the only attribute in this >>>>>> category. >>>>>> >>>>>> Does it make sense to add an element to do this into the >>>>>> captureEncodingType? This is similar to item 11 in my other list of >>>>>> comments http://www.ietf.org/mail- >>>>> archive/web/clue/current/msg02666.html. >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing 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@alum.mit.edu Thu Jul 18 08:06:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D352C21F85B8 for ; Thu, 18 Jul 2013 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LhZQ4T221gb for ; Thu, 18 Jul 2013 08:06:10 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B49C21F841A for ; Thu, 18 Jul 2013 08:04:51 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id 1nj31m00227AodY5Ar4qUE; Thu, 18 Jul 2013 15:04:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 1r4q1m00D3ZTu2S3fr4qB4; Thu, 18 Jul 2013 15:04:50 +0000 Message-ID: <51E80412.6050700@alum.mit.edu> Date: Thu, 18 Jul 2013 11:04:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> <51E75C69.2040301@nteczone.com> In-Reply-To: <51E75C69.2040301@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374159890; bh=2X/CjKXdYfEimUDQp7zvjiknY+90wECqOYAspkEbpEU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ocaTP80Vi+yR7alhoy/XSOoYmnqttO34QHGdUQq8UZMgEy6O5Vq79i3RMpJehEYcp hSMcRjG9AkxDc31Sot1qsQT5Bu7RwyjmO5g42ZCbBBYLjPrLrtK1rp81sUXh6tA99+ +MlW2mpM+aqV9J0p5zN1D0zQyPqNZB+7pFofNypYBrO6UjN7x11SOY3uzJVox9ChUc qNjZeCPwiPB8k5L4A0Xm70SCYaaB36i3YVCEStfuEInfYMGE+SnfRpRBDal93Bfa7z udjh2g1Tb6Ard3epHMWeFxlanN6eshFarGBM/jtf2y7sV81Siu6hlojT3R/oJnstGe gejgcdW44Cggg== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 15:06:15 -0000 I also waffle on this. On one hand this seems like a syntactic trick to reduce the size of advertisements, and that might be a good thing. But it does have these unintended consequences. IMO we would be better off to follow the KISS principle for now. If that proves to be inadequate then it can be addressed later. Thanks, Paul (as individual) On 7/17/13 11:09 PM, Christian Groves wrote: > Hello Mark, > > Actually I'm torn on this one. Being able to provide a list of values > and have the Consumer choose seems like a good capability to be built > into the protocol. However the implementation becomes problematic and > adds complications. I had thought about the Consumer appending the > mediaCaptureID i.e. 1a, 1b, 1c if it wants multiple instances but how > would that work with STS? Also what would be the interaction when there > are multiple set of attributes that have multiple values? Without a > simple way to introduce it may be simpler to KISS and remove the > captureParameters element. However if someone can come up with a way to > support it I'm all ears :-). > > Regards, Christian > > On 18/07/2013 11:40 AM, Duckworth, Mark wrote: >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Christian Groves >>> Sent: Wednesday, July 17, 2013 9:16 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] data model for specifying attribute value in >>> Configure >>> message >>> >>> Hello Mark, >>> >>> What is needed is a structure that only allows one set of >>> captureParameters >>> per mediaCaptureID AND that the chosen set of captureParameters are used >>> in all CaptureEncodings that reference the mediaCaptureID. This >>> guarantees >>> uniqueness. >> [Duckworth, Mark] Yes, this is exactly what I was trying to suggest. >> >>> Having such a restriction does have side effects. For example: if the >>> Provider >>> indicates the support of segment and site switched for one CaptureID and >>> the consumer wants both types of Captures in different capture encodings >>> then this would not be possible. For this to be possible the Provider >>> would >>> have to Advertise one CaptureID with "segment" and another CaptureID >>> with "site". If this is the case then the question is, is there any >>> point in having >>> a list of values in the first place? >> [Duckworth, Mark] It sounds like you and Paul are both suggesting we >> remove this "advertise a choice of values for the Consumer to choose >> from" mechanism from the scene-switch-policy attribute. Instead, just >> use it like all the other attributes where the Advertisement indicates >> the attribute and its value. Then we could also simplify the data >> model, removing the captureParameters element. That would be fine >> with me. >> >>> Regards, Christian >>> >>> >>> On 18/07/2013 1:45 AM, Duckworth, Mark wrote: >>>> Hi Christian, >>>> >>>> I think I understand your point, and it does seem like an issue in >>>> the data- >>> model-schema-00 document, section 22. >>>> >>>> >>>> >>>> >>>> >>>> >> type="captureParametersType" minOccurs="0"/> >>>> >> type="encodingParametersType" minOccurs="0"/> >>>> >>>> >>>> >>>> This structure requires the captureParameters to be specified for each >>> captureEncodingType, but this isn't what we want. I think it would >>> be better >>> to have a structure that specifies a mediaCaptureID just once, with >>> just one >>> corresponding captureParameters element, but with a list of >>> encodingID and >>> encodingParameters to represent the multiple encodings of the single >>> media >>> capture. >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>>> Of Christian Groves >>>>> Sent: Sunday, July 14, 2013 11:06 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>> Configure message >>>>> >>>>> Hello Mark, >>>>> >>>>> I don't think the rule regarding CSE helps. The configure only lists >>>>> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having >>>>> parameters in the Configure is that effectively a CaptureID no longer >>>>> lists a unique capture. You could in theory have a CaptureID with >>>>> different sets of attributes. An Advertisement could offer a >>>>> CaptureID with multiple values and a set of encodings. A consumer >>>>> could in theory return the same CaptureID multiple times with >>>>> different >>> values and the same encoding ID. >>>>> This would lead to the same CaptureEncoding which would cause >>>>> referencing issues. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>>>>> Paul, I agree it doesn't make sense to include different values of >>>>>> the >>>>> attribute for the same capture. This is related to the statement in >>>>> the framework in section 6.2.2 "The Consumer must choose the same >>>>> value for all the Media Captures in the Capture Scene Entry." So for >>>>> me, the question is should we devise an XML schema for this such that >>>>> it is impossible for the Consumer to construct an inconsistent >>>>> message? Or is it okay to have a schema with potentially redundant >>>>> information, thus enabling the possibility for the values to be >>>>> inconsistent? My proposal allows the inconsistency, and I agree it >>>>> would be better to avoid the redundancy and possibility of >>>>> inconsistency. >>> I could make another proposal along those lines later. >>>>>> Are you saying there are also other problems with attributes that >>>>>> can be >>>>> specified in the Configure message? What about specifying the >>>>> encoding parameters, we agreed on that before didn't we? That is >>>>> very similar to specifying attribute values. >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Friday, July 12, 2013 5:09 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>>> Configure message >>>>>>> >>>>>>> I've brought this up before, but I'll try again: >>>>>>> >>>>>>> As currently conceived, this mechanism has problems. >>>>>>> >>>>>>> Specifically, these attributes apply to captures, not >>>>>>> capture-encodings. >>>>>>> >>>>>>> Suppose I configure two different encodings of the same capture, >>>>>>> and supply different attributes to each. (E.g. one with site >>>>>>> switching and one with scene >>>>>>> switching.) >>>>>>> >>>>>>> At that point, what is the meaning of the capture? I have two >>>>>>> encodings which may be showing entirely different content. IMO this >>>>>>> is >>>>> nonsense. >>>>>>> So I think there is a problem with attributes that can be specified >>>>>>> in the configure. There are a variety of possible solutions. The >>>>>>> simplest is simply to disallow them. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>>>>> I think the data model is intended to support building a Configure >>>>>>>> message by using a list of captureEncoding elements. If so, there >>>>>>>> also needs to be a way to add parameter values of items where the >>>>>>>> Provider has offered a choice. >>>>>>>> >>>>>>>> From the framework: >>>>>>>> >>>>>>>> For each Media Capture in the message, the Consumer may also >>>>>>>> >>>>>>>> specify the value of any attributes for which the Provider >>>>>>>> has >>>>>>>> >>>>>>>> offered a choice, for example the value for the >>>>>>>> Scene-switch-policy >>>>>>>> >>>>>>>> attribute. >>>>>>>> >>>>>>>> Currently, I think Scene-switch-policy is the only attribute in >>>>>>>> this category. >>>>>>>> >>>>>>>> Does it make sense to add an element to do this into the >>>>>>>> captureEncodingType? This is similar to item 11 in my other list >>>>>>>> of comments http://www.ietf.org/mail- >>>>>>> archive/web/clue/current/msg02666.html. >>>>>>>> Mark >>>>>>>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Jul 18 08:09:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D566511E816E for ; Thu, 18 Jul 2013 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtFt4gfVcYer for ; Thu, 18 Jul 2013 08:09:21 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A7E6321F92C2 for ; Thu, 18 Jul 2013 08:08:29 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so1773422qcx.39 for ; Thu, 18 Jul 2013 08:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hIEB4IbtwAVND/3ZKR1Z3gydRflgVrxm3vyO/dZPVRA=; b=A3afwEXU/e43+EwElM9Ifd+pdMEWamNi0zYCnYQA8WC20j45ss98h/6fPCwMw0p9Gs lrKEvY9vgnmkQvDBnp2ZU1ck1gT53MjSCIl8IJNAqt9UROS+C3g2oljHebs4cN4yk0Xm Ifrd1vmxw0/QzW4aMPmuIv2hH9zXzS6VlmaV2yP4CLf/9chWZzpeVRWzus3Qm4nYUYGs mOAUWcjknGmmKcpt48rrOwk7MeTQVJET9N7aiokS2DSSLN+m0+mWAkOkIIW9ppdVN4gT TBfJ0Y1JXHhWR6yAvBIqvhpR8PqUycB0wWSsdgWXBGodMADY1kbdc1nllZ0p1nLtFO4s 5CUA== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr12957339qeb.6.1374160105319; Thu, 18 Jul 2013 08:08:25 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 18 Jul 2013 08:08:25 -0700 (PDT) Date: Thu, 18 Jul 2013 10:08:25 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bdc90aaf1325804e1ca94d4 Subject: [clue] CLUE-87 Agenda & Planning X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 15:09:26 -0000 --047d7bdc90aaf1325804e1ca94d4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The agenda for the CLUE WG session is available: https://datatracker.ietf.org/meeting/87/agenda/clue/ Please comment on the agenda now so that we go into the meeting ready to go. Also, there is a doodle for a "CLUE WG Social Dinner": http://www.doodle.com/fb6kzkxfwk5hrfr9 Please respond to the doodle poll if you are interested in dinner no later than Wednesday, July 24th 24:00 UTC, so that I have some time before the meeting starts to find a place. Regards, Mary. --047d7bdc90aaf1325804e1ca94d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The agenda for the CLUE WG sess= ion is available:

Please comment on the = agenda now so that we go into the meeting ready to go. =A0
=
Also, there is a doodle for a=A0"CLUE WG Social Dinner&= quot;:
http://www.doodle.com/fb6kzkxfwk5hrfr9

Please respond to the doodle poll if you a= re interested in dinner no later than Wednesday, July 24th 24:00 UTC, so th= at I have some time before the meeting starts to find a place.

Regar= ds,
Mary.=A0
--047d7bdc90aaf1325804e1ca94d4-- From Christian.Groves@nteczone.com Thu Jul 18 18:18:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137D21F9DBA for ; Thu, 18 Jul 2013 18:18:20 -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_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFRQdGU38Id9 for ; Thu, 18 Jul 2013 18:18:20 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id BF57221F9956 for ; Thu, 18 Jul 2013 18:18:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGGT6FF20Z+w/2dsb2JhbAANQwrEU4EqgxgBAQEDATgbFREQCxgJJQ8CRgYNAQUCAQEXh2+kEJI3jlOBPAeDfAOUBphI Received: from ppp118-209-159-176.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.159.176]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Jul 2013 10:47:51 +0930 Message-ID: <51E89391.30507@nteczone.com> Date: Fri, 19 Jul 2013 11:17:05 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Leslie References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> In-Reply-To: <20130718111602.GD5411@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 01:18:20 -0000 Hello John, Please see my comments below. Regards, Christian On 18/07/2013 9:16 PM, John Leslie wrote: > Christian Groves wrote: >> I did a review of the requirements and Appendix to see if they are met. >> ... >> >> REQMT-2:The solution MUST support a description of the spatial >> arrangement of captured source audio sent in audio streams >> which enables a satisfactory reproduction at the receiver >> in a spatially correct manner.This applies to each site >> in a point to point or a multipoint meeting and refers to >> the spatial ordering within a site, not the ordering of >> channels between sites. >> >> [CNG] Supported ? Via Capture Area attribute... > Um... audio isn't two-dimensinal... [CNG] That's why the "?" is next to "Supported" :-). I agree there's the 2D issues which I pick up on below. > >> REQMT-2a:The solution MUST support a means of preserving >> the spatial order of audio in the captured >> scene.For example, if John sounds as if he is >> at Susan's right in the captured audio, John >> voice is also placed at Susan's right in the >> rendered image. > This REQMT could use some work... > >> REQMT-2e:The solution MUST support a means to identify >> the extent of individual audio captures in >> three dimensions. > (I don't know what that means.) > >> [CNG] Partial ? The Capture area attribute is based on capturing a plane >> in Cartesian space. There is no depth parameter. Whether the plane >> concept holds for audio like it does video needs further thought. > It doesn't. > > A microphone can be modeled by a capture point and direction, plus > a sensitivity pattern; but no actual sensitivity pattern resembles a > camera's pattern. Furthermore, no X/Y information survives, but distance > from audio source to the microphone becomes significant (about one > millisecond per foot). [CNG] Could you perhaps propose some attributes (and descriptive text) based on direction and sensitivity pattern that you mentioned above? It would be good to have something more to discuss. > >> REQMT-3b:The solution MUST enable individual audio >> streams to be rendered in any desired spatial >> position. >> >> [CNG] Supported? ? I think its assumed that a Consumer can do whatever >> it likes with respect to rendering decisions. Ultimately that?s local >> policy. > I agree it's local policy. > >> OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural >> audio is unresolved, and the "MUST NOT preclude" language in >> this requirement is problematic.The authors believe this >> requirement needs to be either changed or withdrawn, >> depending on how the issue is resolved. >> >> [CNG] Not supported - This is still unresolved. > Binaural audio works fairly well when the listener's head is > stationary. Alas, it won't be. [CNG] I think the use case that was thought about was participating in a telepresence conference via a smart phone whilst wearing headphones. I think it was Christer that had that concern. > > -- > John Leslie > From Christian.Groves@nteczone.com Thu Jul 18 18:24:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DF111E8208 for ; Thu, 18 Jul 2013 18:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gasQndKFFuxD for ; Thu, 18 Jul 2013 18:24:29 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C129D11E81A5 for ; Thu, 18 Jul 2013 18:24:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkDAIWU6FF20Z+w/2dsb2JhbAANQwqDO0rASgMBgSqDGAEBAQMBAQEBLwEFGxUGBAYRCxgJFggHCQMCAQIBFR8REwYCAQEFEgSHaw0Fo36SN45NBgRFeoN8A5QGhQCLAYhHgVYJ Received: from ppp118-209-159-176.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.159.176]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Jul 2013 10:54:27 +0930 Message-ID: <51E8952D.9020106@nteczone.com> Date: Fri, 19 Jul 2013 11:23:57 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <51E7FECE.7000607@alum.mit.edu> In-Reply-To: <51E7FECE.7000607@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 01:24:31 -0000 Hello Paul, There was a bounding attribute "the scene area" which was removed. As I mentioned at the time the idea was to give an indication of how the capture areas were located in the room. With regards to audio I think we need to revisit that with respect to the spatial attributes. Regards, Christian On 19/07/2013 12:42 AM, Paul Kyzivat wrote: > Christian, > > You raise a point that has bothered me for some time: > > We describe the spatial attributes of a capture by point of capture > and area of capture (a quadrilateral). Implicitly this describes an > unbounded pyramid. In reality, it is bounded by the geometry of the > room and the stuff in it, but we don't have that info. This pyramid > may be meaningful in some sense for video, though we lack other > information such as depth of field. But as John replied, I guess it > means very little for audio. > > The fundamental question is: does this provide sufficient information > for the consumer to properly adapt the received media to his available > equipment? I don't know the answer to that, but I suspect that it will > allow some approximation, but probably not enough to do the best > possible job. Is there more that we ought to be providing to help with > that job? Or does doing more provide diminishing returns? > > Thanks, > Paul > > On 7/17/13 11:01 PM, Christian Groves wrote: >> Hello Mary, >> >> I did a review of the requirements and Appendix to see if they are met. >> My comments are below. Sorry for the length of the email but I figured >> it would be easier for people to read my comment [CNG] along with the >> requirement. >> >> REQMT-1:The solution MUST support a description of the spatial >> >> arrangement of source video images sent in video streams >> >> which enables a satisfactory reproduction at the receiver >> >> of the original scene.This applies to each site in a >> >> point to point or a multipoint meeting and refers to the >> >> spatial ordering within a site, not to the ordering of >> >> images between sites. >> >> [CNG] Supported via Capture Area attribute. >> >> Use case point to point symmetric, and all other use cases. >> >> REQMT-1a:The solution MUST support a means of allowing >> >> the preservation of the order of images in the >> >> captured scene.For example, if John is to >> >> Susan's right in the image capture, John is >> >> also to Susan's right in the rendered image. >> >> [CNG] Supported via Capture Area attribute. >> >> REQMT-1b:The solution MUST support a means of allowing >> >> the preservation of order of images in the >> >> scene in two dimensions - horizontal and >> >> vertical. >> >> [CNG] Supported via Capture Area attribute. >> >> REQMT-1c:The solution MUST support a means to identify >> >> the point of capture of individual video >> >> captures in three dimensions. >> >> [CNG] Supported via Point of capture attribute. >> >> REQMT-1d:The solution MUST support a means to identify >> >> the extent of individual video captures in >> >> three dimensions. >> >> [CNG] Partial Capture area attribute allows the specification of a >> plane of capture in 3 dimensions. However depth of the capture (needed >> for a 3D area) is not supported. >> >> REQMT-2:The solution MUST support a description of the spatial >> >> arrangement of captured source audio sent in audio streams >> >> which enables a satisfactory reproduction at the receiver >> >> in a spatially correct manner.This applies to each site >> >> in a point to point or a multipoint meeting and refers to >> >> the spatial ordering within a site, not the ordering of >> >> channels between sites. >> >> [CNG] Supported Via Capture Area attribute. >> >> Use case point to point symmetric, and all use cases, >> >> especially heterogeneous. >> >> REQMT-2a:The solution MUST support a means of preserving >> >> the spatial order of audio in the captured >> >> scene.For example, if John sounds as if he is >> >> at Susan's right in the captured audio, John >> >> voice is also placed at Susan's right in the >> >> rendered image. >> >> [CNG] Supported Via Capture Area attribute. >> >> REQMT-2b:The solution MUST support a means to identify >> >> the number and spatial arrangement of audio >> >> channels including monaural, stereophonic >> >> (2.0), and 3.0 (left, center, right) audio >> >> channels. >> >> [CNG] Partial the Audio Channel Format attribute currently only >> supports 搈ono and 搒tereo. It doesn抰 support the 3.0 format. >> >> REQMT-2c:The solution MUST NOT preclude the use of >> >> binaural audio.[Edt. This is an outstanding >> >> issue.Text will be changed when the issue is >> >> resolved.] >> >> [CNG] Partial? Binaural isn抰 mentioned in the framework so isn抰 >> precluded as such. There is no indication in CLUE recording a binaural >> capture. >> >> REQMT-2d:The solution MUST support a means to identify >> >> the point of capture of individual audio >> >> captures in three dimensions. >> >> [CNG] Supported via Point of capture attribute. >> >> REQMT-2e:The solution MUST support a means to identify >> >> the extent of individual audio captures in >> >> three dimensions. >> >> [CNG] Partial The Capture area attribute is based on capturing a plane >> in Cartesian space. There is no depth parameter. Whether the plane >> concept holds for audio like it does video needs further thought. >> >> REQMT-3:The solution MUST support a mechanism to enable a >> >> satisfactory spatial matching between audio and video >> >> streams coming from the same endpoints. >> >> [CNG] Supported - The given that an Advertiser places captures in a >> particular scene it is possible to indicate audio and video streams are >> from the same endpoint. >> >> Use case is point to point symmetric, and all use cases. >> >> REQMT-3a:The solution MUST enable individual audio >> >> streams to be associated with one or more video >> >> image captures, and individual video image >> >> captures to be associated with one or more >> >> audio captures, for the purpose of rendering >> >> proper position. >> >> [CNG] Supported (Partial?) It is possible to deduce that audio and >> video relate to the same capture area in a scene by analysing the >> Capture Area parameters. It is possible to relate individual audio >> captures to video captures if the Advertisement is constructed in a >> limited way. However its not possible to deduce the relationships >> between individual captures by utilising the Scene, CSE and capture >> concepts. CSE only relate to one media type. So it抯 not possible to >> link audio CSEs to video CSEs. >> >> REQMT-3b:The solution MUST enable individual audio >> >> streams to be rendered in any desired spatial >> >> position. >> >> [CNG] Supported? I think its assumed that a Consumer can do whatever >> it likes with respect to rendering decisions. Ultimately that抯 local >> policy. >> >> Edt: Rendering is an open issue. Text will >> >> be changed when it is resolved.] >> >> REQMT-4:The solution MUST enable interoperability between >> >> endpoints that have a different number of similar devices. >> >> For example, one endpoint may have 1 screen, 1 speaker, 1 >> >> camera, 1 mic, and another endpoint may have 3 screens, 2 >> >> speakers, 3 cameras and 2 mics.Or, in a multi-point >> >> conference, one endpoint may have one screen, another may >> >> have 2 screens and a third may have 3 screens.This >> >> includes endpoints where the number of devices of a given >> >> type is zero. >> >> Use case is asymmetric point to point and multipoint. >> >> [CNG] Supported CLUE enables different capture capabilities to be >> signalled. It makes no assumption as to the rendering. >> >> REQMT-5:The solution MUST support means of enabling >> >> interoperability between telepresence endpoints where >> >> cameras are of different picture aspect ratios. >> >> [CNG] Supported CLUE doesn抰 describe 揳spect ratio but allows >> different capture areas to be defined. This is a means of describing >> aspect ratio. >> >> REQMT-6:The solution MUST provide scaling information which >> >> enables rendering of a video image at the actual size of >> >> the captured scene. >> >> [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture >> and Scene Scale allow this. >> >> REQMT-7:The solution MUST support means of enabling >> >> interoperability between telepresence endpoints where >> >> displays are of different resolutions. >> >> [CNG] Supported? CLUE allow encoding parameters to be associated with >> captures which could state the resolution of the captured image. However >> there is no way to indicate 揹isplay resolution. Perhaps the >> requirement needs to be reworded? >> >> REQMT-8:The solution MUST support methods for handling different >> >> bit rates in the same conference. >> >> [CNG] Supported CLUE allow encoding parameters to be associated with >> captures which could state the bit rate. >> >> REQMT-9:The solution MUST support means of enabling >> >> interoperability between endpoints that send and receive >> >> different numbers of media streams. >> >> Use case heterogeneous and multipoint. >> >> [CNG] Supported CLUE allows different numbers of captures to be sent. >> >> REQMT-10:The solution MUST make it possible for endpoints without >> >> support for telepresence extensions to participate in a >> >> telepresence session with those that do. >> >> [CNG] Supported The support of a CLUE channel will be negotiated >> between endpoints. From the current signalling draft it seems a basic >> set of media can be established without CLUE. Endpoints that don抰 >> support CLUE obviously won抰 be able to determine spatial information >> etc >> >> REQMT-11:The solution MUST support a mechanism for determining >> >> whether or not an endpoint or MCU is capable of >> >> telepresence extensions. >> >> [CNG] Supported? The negotiation of a CLUE channel via SDP is one >> method in the signalling draft. Another indication at the SIP level may >> be beneficial such as a feature tag. This is yet to be documented. >> >> REQMT-12:The solution MUST support a means to enable more than two >> >> sites to participate in a teleconference. >> >> Use case multipoint. >> >> [CNG] Partial This is on the agenda and there抯 basic support i.e. via >> the composed attribute and 搒cene-switch-policy CSE attribute. However >> no method is yet defined to keep the source information. >> >> REQMT-13:The solution MUST support both transcoding and switching >> >> approaches to providing multipoint conferences. >> >> [CNG] Supported CLUE supports these two methods. However further work >> is needed on the details. >> >> REQMT-14:The solution MUST support mechanisms to make possible for >> >> either or both site switching or segment switching.[Edt: >> >> This needs rewording.Deferred until layout discussion is >> >> resolved.] >> >> [CNG] Partial The 搒cene-switch-policy CSE attribute supports this to >> some level but further work is needed in this area. >> >> REQMT-15:The solution MUST support mechanisms for presentations in >> >> such a way that: >> >> *Presentations can have different sources >> >> *Presentations can be seen by all >> >> *There can be variation in placement, number and size of >> >> Presentations >> >> [CNG] Partial CLUE allows an endpoint whether the capture is related >> to a presentation or not through the use of the presentation attribute. >> The spatial attributes (i.e. capture area) allows the place and size to >> be indicated. The number can be inferred from the number of captures. >> CLUE doesn抰 have any policy on who can see the presentations. The CLUE >> Advertisement mechanism may include presentation captures to all people >> within the conference. Perhaps the 2^nd bullet can be removed or >> clarified that its not related to policy? >> >> REQMT-16:The solution MUST include extensibility mechanisms. >> >> [CNG] Supported? whilst not explicitly documented I think there抯 >> general agreement this is needed. >> >> REQMT-17:The solution must support a mechanism for allowing >> >> information about media captures to change during a >> >> conference. >> >> [CNG] Supported? Keeping the CLUE signalling channel open would allow >> for this and people seem in agreement this should be possible. Further >> detailed work is needed in the signalling draft to describe this. i.e. >> incremental vs full updates. Interaction with bearer signalling (i.e. >> SDP O/A) etc. >> >> REQMT-18:The solution MUST provide a mechanism for the secure >> >> exchange of information about the media captures. >> >> [CNG] Partial? It is assumed that CLUE will operate over a DTLS/SCTP >> however there抯 no documentation regarding CLUE security. >> >> Appendix A. open issues >> >> OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural >> >> audio is unresolved, and the "MUST NOT preclude" language in >> >> this requirement is problematic.The authors believe this >> >> requirement needs to be either changed or withdrawn, >> >> depending on how the issue is resolved. >> >> [CNG] Not supported - This is still unresolved. >> >> OPEN-2Reference to Rendering [REQMT-3b] This is the only >> >> requirement which refers to rendering.It may also be empty, >> >> since receivers can rendering audio captures as they wish. >> >> This is deferred until broader discussion on rendering >> >> requirements is concluded. >> >> [CNG] I think we should frame the requirements with regards to captures >> as that抯 the way the framework is written. Perhaps some text to say >> that rendering is based on the receivers local policy. >> >> OPEN-3Conference modes [REQMT-14] This wording of this requirement >> >> is problematic in part because the conference modes (site >> >> switching and segment switching) are not defined.It at >> >> least needs rewording.This is deferred until broader >> >> discussion on layout is concluded. >> >> [CNG] Yes this is still open. >> >> OPEN-4Need to capture requirement that attributes can change at any >> >> time during the call. >> >> [CNG] Yes although it seems REQMT-17 covers this. >> >> OPEN-5Need to add requirement for three dimensions in the right >> >> place >> >> [CNG] Requirements 1d and 2e do capture an aspect of 3D. >> >> OPEN-6Multi-view, is there a requirement needed? >> >> [CNG] Even if there抯 no requirement we appear to support it because we >> allow both the capture area and capture point to be sent for captures. >> An Advertiser could describe multiple capture points capturing the same >> area of capture. >> >> >> Regards, Christian >> >> On 17/07/2013 6:07 AM, Mary Barnes wrote: >>> There really were no changes other than to refresh this draft. I was >>> going to extend the security section with more detail, but I really >>> can't add much more detail without referencing things that are defined >>> in the framework. So, I think the next step is for me to work with >>> Mark on the security for the framework. >>> >>> There are some open issues identified in the appendix of this document >>> that we need to figure out whether they are issues that need >>> resolution for this document. I will open issues in the tracker and we >>> can discuss each one and perhaps make some decisions before Berlin. >>> >>> We also need to consider whether the current framework meets these >>> requirements. If some requirements are not met, we need to decide >>> whether it's because they'll be met by the solution documents or won't >>> be met at all. In which case, we need to decide whether we actually >>> need them for the solution. >>> >>> Regards, >>> Mary. >>> >>> >>> On Tue, Jul 16, 2013 at 11:29 AM, >> > wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence Working Group of the IETF. >>> >>> Title : Requirements for Telepresence Multi-Streams >>> Author(s) : Allyn Romanow >>> Stephen Botzko >>> Mary Barnes >>> Filename : draft-ietf-clue-telepresence-requirements-04.txt >>> Pages : 14 >>> Date : 2013-07-15 >>> >>> 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 datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements >>> >>> >>> >>> There's also a htmlized version available at: >>> >>> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 >>> >>> A diff from the previous version is available at: >>> >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04 >>> >>> >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft >>> >>> directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Jul 22 08:09:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C110F21E80B0 for ; Mon, 22 Jul 2013 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srjiefjt9nHQ for ; Mon, 22 Jul 2013 08:09:48 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0C11E8118 for ; Mon, 22 Jul 2013 08:09:47 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id 3QKf1m0021ei1Bg54T9mx8; Mon, 22 Jul 2013 15:09:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 3T9m1m0103ZTu2S3kT9mRg; Mon, 22 Jul 2013 15:09:46 +0000 Message-ID: <51ED4B39.1000605@alum.mit.edu> Date: Mon, 22 Jul 2013 11:09:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374505786; bh=rNx/G6FFK/UYVv1n0u3Sj6Rr1W133pMHoS5qNLHjwfI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ia0GdUrOiJzb+3BVcVDp63PdIy38Edkmfryrex7fxrR//LN6J/R47AtxnbI+TEVeG CThr6T6/syGchUkiSaUZvTb21Qr1Onf0ZxirhPoovrMYEakeHMkKAB7/cs29Efrzvc +/2XFFCwyo9g6Fc6nKTlPmqB5PRH9dD7HIQgKnTjsj3IXKOrp1/2c3lp+BAA//hd5p zHHvqPE2xHBkUyqIH4f5odCEw0bI5wAZrD3U1IKSsYcUa5Lcj3YrlSfkB6y4y6Cin0 efYNEJiKjQx9XC62G/DpLhAZC+UDnmv6jHNx/ePFBu8tXf1ZRf1cUskxltbtMyITxM 7aUClniBLmgkw== Subject: [clue] draft-ietf-clue-framework-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: Mon, 22 Jul 2013 15:09:53 -0000 A couple of nits for this version of the draft: Section 6.1.1 - definition of Description: The definition has been copied from that for Capture Scene. It isn't quite right in this context. It should be: "Human-readable description of the Capture," ... Section 6.2.2 - definition of Description: The definition has been copied from that for Capture Scene. It isn't quite right in this context. It should be: "Human-readable description of the Capture Scene Entry," ... Thanks, Paul From roberta.presta@unina.it Mon Jul 22 08:20:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EEB21E808E for ; Mon, 22 Jul 2013 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIbW-Xf1Tlxz for ; Mon, 22 Jul 2013 08:20:30 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3287911E8111 for ; Mon, 22 Jul 2013 08:20:29 -0700 (PDT) Received: from [127.0.0.1] ([100.71.11.111]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r6MFKQxH002773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jul 2013 17:20:27 +0200 Message-ID: <51ED4DBC.3030602@unina.it> Date: Mon, 22 Jul 2013 17:20:28 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> <51E75C69.2040301@nteczone.com> <51E80412.6050700@alum.mit.edu> In-Reply-To: <51E80412.6050700@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130721-1, 21/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 15:20:36 -0000 Hi all, to summarize: - no more as capture scene entry attribute - the switching policy becomes a media capture attribute - no more capture parameters in the capture encoding definition Right? It sounds definitely simpler than before. Thanks, Roberta Il 18/07/2013 17:04, Paul Kyzivat ha scritto: > I also waffle on this. On one hand this seems like a syntactic trick > to reduce the size of advertisements, and that might be a good thing. > But it does have these unintended consequences. > > IMO we would be better off to follow the KISS principle for now. > If that proves to be inadequate then it can be addressed later. > > Thanks, > Paul (as individual) > > On 7/17/13 11:09 PM, Christian Groves wrote: >> Hello Mark, >> >> Actually I'm torn on this one. Being able to provide a list of values >> and have the Consumer choose seems like a good capability to be built >> into the protocol. However the implementation becomes problematic and >> adds complications. I had thought about the Consumer appending the >> mediaCaptureID i.e. 1a, 1b, 1c if it wants multiple instances but how >> would that work with STS? Also what would be the interaction when there >> are multiple set of attributes that have multiple values? Without a >> simple way to introduce it may be simpler to KISS and remove the >> captureParameters element. However if someone can come up with a way to >> support it I'm all ears :-). >> >> Regards, Christian >> >> On 18/07/2013 11:40 AM, Duckworth, Mark wrote: >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of >>>> Christian Groves >>>> Sent: Wednesday, July 17, 2013 9:16 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] data model for specifying attribute value in >>>> Configure >>>> message >>>> >>>> Hello Mark, >>>> >>>> What is needed is a structure that only allows one set of >>>> captureParameters >>>> per mediaCaptureID AND that the chosen set of captureParameters are >>>> used >>>> in all CaptureEncodings that reference the mediaCaptureID. This >>>> guarantees >>>> uniqueness. >>> [Duckworth, Mark] Yes, this is exactly what I was trying to suggest. >>> >>>> Having such a restriction does have side effects. For example: if the >>>> Provider >>>> indicates the support of segment and site switched for one >>>> CaptureID and >>>> the consumer wants both types of Captures in different capture >>>> encodings >>>> then this would not be possible. For this to be possible the Provider >>>> would >>>> have to Advertise one CaptureID with "segment" and another CaptureID >>>> with "site". If this is the case then the question is, is there any >>>> point in having >>>> a list of values in the first place? >>> [Duckworth, Mark] It sounds like you and Paul are both suggesting we >>> remove this "advertise a choice of values for the Consumer to choose >>> from" mechanism from the scene-switch-policy attribute. Instead, just >>> use it like all the other attributes where the Advertisement indicates >>> the attribute and its value. Then we could also simplify the data >>> model, removing the captureParameters element. That would be fine >>> with me. >>> >>>> Regards, Christian >>>> >>>> >>>> On 18/07/2013 1:45 AM, Duckworth, Mark wrote: >>>>> Hi Christian, >>>>> >>>>> I think I understand your point, and it does seem like an issue in >>>>> the data- >>>> model-schema-00 document, section 22. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> type="captureParametersType" minOccurs="0"/> >>>>> >>> type="encodingParametersType" minOccurs="0"/> >>>>> >>>>> >>>>> >>>>> This structure requires the captureParameters to be specified for >>>>> each >>>> captureEncodingType, but this isn't what we want. I think it would >>>> be better >>>> to have a structure that specifies a mediaCaptureID just once, with >>>> just one >>>> corresponding captureParameters element, but with a list of >>>> encodingID and >>>> encodingParameters to represent the multiple encodings of the single >>>> media >>>> capture. >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>>>> Of Christian Groves >>>>>> Sent: Sunday, July 14, 2013 11:06 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>> Configure message >>>>>> >>>>>> Hello Mark, >>>>>> >>>>>> I don't think the rule regarding CSE helps. The configure only lists >>>>>> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having >>>>>> parameters in the Configure is that effectively a CaptureID no >>>>>> longer >>>>>> lists a unique capture. You could in theory have a CaptureID with >>>>>> different sets of attributes. An Advertisement could offer a >>>>>> CaptureID with multiple values and a set of encodings. A consumer >>>>>> could in theory return the same CaptureID multiple times with >>>>>> different >>>> values and the same encoding ID. >>>>>> This would lead to the same CaptureEncoding which would cause >>>>>> referencing issues. >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>>>>>> Paul, I agree it doesn't make sense to include different values of >>>>>>> the >>>>>> attribute for the same capture. This is related to the statement in >>>>>> the framework in section 6.2.2 "The Consumer must choose the same >>>>>> value for all the Media Captures in the Capture Scene Entry." So >>>>>> for >>>>>> me, the question is should we devise an XML schema for this such >>>>>> that >>>>>> it is impossible for the Consumer to construct an inconsistent >>>>>> message? Or is it okay to have a schema with potentially redundant >>>>>> information, thus enabling the possibility for the values to be >>>>>> inconsistent? My proposal allows the inconsistency, and I agree it >>>>>> would be better to avoid the redundancy and possibility of >>>>>> inconsistency. >>>> I could make another proposal along those lines later. >>>>>>> Are you saying there are also other problems with attributes that >>>>>>> can be >>>>>> specified in the Configure message? What about specifying the >>>>>> encoding parameters, we agreed on that before didn't we? That is >>>>>> very similar to specifying attribute values. >>>>>>> Mark >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>>>> Behalf Of Paul Kyzivat >>>>>>>> Sent: Friday, July 12, 2013 5:09 PM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>>>> Configure message >>>>>>>> >>>>>>>> I've brought this up before, but I'll try again: >>>>>>>> >>>>>>>> As currently conceived, this mechanism has problems. >>>>>>>> >>>>>>>> Specifically, these attributes apply to captures, not >>>>>>>> capture-encodings. >>>>>>>> >>>>>>>> Suppose I configure two different encodings of the same capture, >>>>>>>> and supply different attributes to each. (E.g. one with site >>>>>>>> switching and one with scene >>>>>>>> switching.) >>>>>>>> >>>>>>>> At that point, what is the meaning of the capture? I have two >>>>>>>> encodings which may be showing entirely different content. IMO >>>>>>>> this >>>>>>>> is >>>>>> nonsense. >>>>>>>> So I think there is a problem with attributes that can be >>>>>>>> specified >>>>>>>> in the configure. There are a variety of possible solutions. The >>>>>>>> simplest is simply to disallow them. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>>>>>> I think the data model is intended to support building a >>>>>>>>> Configure >>>>>>>>> message by using a list of captureEncoding elements. If so, >>>>>>>>> there >>>>>>>>> also needs to be a way to add parameter values of items where the >>>>>>>>> Provider has offered a choice. >>>>>>>>> >>>>>>>>> From the framework: >>>>>>>>> >>>>>>>>> For each Media Capture in the message, the Consumer may >>>>>>>>> also >>>>>>>>> >>>>>>>>> specify the value of any attributes for which the Provider >>>>>>>>> has >>>>>>>>> >>>>>>>>> offered a choice, for example the value for the >>>>>>>>> Scene-switch-policy >>>>>>>>> >>>>>>>>> attribute. >>>>>>>>> >>>>>>>>> Currently, I think Scene-switch-policy is the only attribute in >>>>>>>>> this category. >>>>>>>>> >>>>>>>>> Does it make sense to add an element to do this into the >>>>>>>>> captureEncodingType? This is similar to item 11 in my other list >>>>>>>>> of comments http://www.ietf.org/mail- >>>>>>>> archive/web/clue/current/msg02666.html. >>>>>>>>> Mark >>>>>>>>> >>> _______________________________________________ >>> clue mailing 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 roberta.presta@unina.it Mon Jul 22 08:33:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64921E80AF for ; Mon, 22 Jul 2013 08:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OcTDhKxREnj for ; Mon, 22 Jul 2013 08:33:19 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9921F9DFA for ; Mon, 22 Jul 2013 08:33:05 -0700 (PDT) Received: from [127.0.0.1] ([100.71.11.111]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6MFX3Gp001447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 17:33:03 +0200 Message-ID: <51ED50B0.70400@unina.it> Date: Mon, 22 Jul 2013 17:33:04 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9D52@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601BC9D52@CRPMBOXPRD07.polycom.com> Content-Type: multipart/alternative; boundary="------------080700070809060908030707" X-Antivirus: avast! (VPS 130721-1, 21/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] comments on data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 15:33:24 -0000 This is a multi-part message in MIME format. --------------080700070809060908030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mark, thanks for your comments. We have applied all your suggestions to the -01 version of the draft (still a work in progress). Cheers, Roberta Il 12/07/2013 20:34, Duckworth, Mark ha scritto: > > Just a few minor comments on the data model draft: > > 1 -- section 10.2 "each media capture must be associated with one and > only capture scene" should be "each media capture must be associated > with one and only <> capture scene" > > 2 -- "definible" should be "definable" in several places > > 3 -- should the simultaneousSetType include a mediaType element, > similar to how a sceneEntryType includes a mediaType? I think so, to > make it clear that a simultaneous set includes media captures of only > a particular media type. > > I will have a separate list of comments about consistency of data > model and framework. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------080700070809060908030707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Mark,

thanks for your comments.
We have applied all your suggestions to the -01 version of the draft (still a work in progress).
Cheers,


Roberta



Il 12/07/2013 20:34, Duckworth, Mark ha scritto:

Just a few minor comments on the data model draft:

 

1 – section 10.2 “each media capture must be associated with one and only capture scene” should be “each media capture must be associated with one and only <<one>> capture scene”

 

2 – “definible" should be “definable” in several places

 

3 – should the simultaneousSetType include a mediaType element, similar to how a sceneEntryType includes a mediaType?  I think so, to make it clear that a simultaneous set includes media captures of only a particular media type.

 

I will have a separate list of comments about consistency of data model and framework.

 

Mark



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

--------------080700070809060908030707-- From pkyzivat@alum.mit.edu Mon Jul 22 08:41:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2358911E812B for ; Mon, 22 Jul 2013 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vBbLX0xZkMl for ; Mon, 22 Jul 2013 08:41:21 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E697B11E8129 for ; Mon, 22 Jul 2013 08:41:20 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id 3PoU1m00D27AodY51ThL2U; Mon, 22 Jul 2013 15:41:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 3ThK1m01R3ZTu2S3fThKDJ; Mon, 22 Jul 2013 15:41:20 +0000 Message-ID: <51ED529F.8020504@alum.mit.edu> Date: Mon, 22 Jul 2013 11:41:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374507680; bh=nZCGj/bRS8TtpfWpWGbUGQ77bEwkgnI9FNHtCL8Oj6Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hKwTEP/Luxh4MixSTjP1Y2zq0zcAA8N95myJ9wXvKSpSnrU2ymjmbAPrXvdMvPQ95 4FHMLSpN5KthcTPzI7jI4PQAocLOSXxHqTCHKBH+lb2UuwgbZFr0oL7fayMx+w16jm bTgdMcwUDnRybr7zcZrd+3HERgE0Ph/UTVEESSPbPtTPdP7t95laqNFxeaNZTAHQCD 5EhjrZgDcLCTidpoxbZBS4e/bc3ybv89nA7vUvw/9rNeuBAgQUNoN7rsZb0wAAQ1TW NdgYj7uEd6NoyVeY/Tx2MALYCM1X3/op8+Ul56ktUGBw3+j/pp5bKZBNypNGhvPZ0S J8QFP/MKOw3Zg== Subject: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:41:27 -0000 A couple of things I picked up while reviewing this version: Section 3 & Section 22: The schema was updated so captureEncodingType references encodingParametersType, but there is a typo (cut/paste error I guess) so that the intended definition of encodingParametersType actually redefines captureParametersType. Section 10.7 : ... The higher the importance, the lower the contained value. When media captures are marked with a "0" priority value, it means that they are "not subject to priority". [edt's note: discussion needed] IMO it makes no sense for some captures to be subject to priority and others to not be subject to priority. What would that mean? The only thing I can see is that those are *mandatory* to render. But we can't really mandate that. If you can't do it we can't force you. So the best it could mean is "really really important" to render. But that is the same as having the highest priority. So I suggest that zero is just the highest priority - no more, no less. And I suggest we also make zero the *default* priority, so that all captures have one, implicitly or explicitly. Then, if you don't mention priority at all, then all captures are equal. And you can just add priority for those captures that are less important. Equivalently, we could leave priority optional, and specify that the absence of a priority implicitly means the highest priority. Then the presence of priority means a lower priority. But I think this formulation is a little more confusing to explain. Section 10.10. : is an optional element indicating wheter or not the capture device originating the capture moves during the telepresence session. ... We can't know for sure that it will move, only that it may. Also a typo. So: s/moves/may move/ s/wheter/whether/ Thanks, Paul From pkyzivat@alum.mit.edu Mon Jul 22 09:54:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7245711E815E for ; Mon, 22 Jul 2013 09:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtX63OCowkwT for ; Mon, 22 Jul 2013 09:54:29 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3310C11E80E7 for ; Mon, 22 Jul 2013 09:49:47 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id 3RqS1m0061YDfWL59UpnMf; Mon, 22 Jul 2013 16:49:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 3Upm1m01J3ZTu2S3gUpmDS; Mon, 22 Jul 2013 16:49:47 +0000 Message-ID: <51ED62AA.9060802@alum.mit.edu> Date: Mon, 22 Jul 2013 12:49:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374511787; bh=bCe7OVBG1j3x8QTuX40mToR9ZbKMLmi+1IPyJJhwW3c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AuYwpWDg2leJcD9o9rvW7p5A580LS88qXVQdLZGgD654s7I1s20eiwZBfBRaVqiPA YbpPASiFjWJQrB7moG2nY89+ZjRF8fs3ht0FA9PFSl0BCs58CKlHnXQwLcbEqYSyH8 /V0OuLYAmMml6qZJ1WQOCoNoxeKD+k6hKNaZKjgPNOFUUkC8hYIENX4l4sbgJS4gOP hP7ny8r5O4SGA9UWL1yHHmG3S9r/ANZrHmcOTO69pkyvrSJPSu9AWgSR6QFNIEMX4Q YUAy6CAaRsPGyASF64IPyLkWgsU6GMph0ZneJ7gKxj/eBrjRDmYcO2KUosXUcIwyKW D8zkWw40Jl4NQ== Subject: [clue] draft-duckworth-clue-switching-example-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 16:54:43 -0000 Section 3.2 (Advertising multiple scenes): While I understand what you are trying to do, I can't figure out how to make this approach work in a sensible way. What logic would the MCU use to assign actual captures to the switched captures in the multiple scenes? It could use site switching: the site of the most recent speaker in scene 1, 2nd most recent speaker in Scene 2, etc. As long as each site has three cameras that would work fine. But in the given example that isn't so. If the 2nd most recently speaking site only has one capture, and the 3rd most recently speaking site has three captures, does it leave VC5 and VC6 empty? That doesn't seem like an ideal choice. Or does it back fill? (Put the most recently speaking four sites into Scenes 1...4. Then put the 5th most recently speaking site into the first captures in any of the sites that are still open, etc.) This would *work*, but it would violate the idea that the scenes are in priority order. So a receiving site that couldn't take them all might get some lower priority captures while missing some higher priority ones. Section 4: A consumer that can handle all 12 captures isn't the interesting one to consider here. More interesting are endpoints E,F,G. Lets consider F: It can handle 8 captures: two big and 6 small. Or maybe one big and 12 small. The quality of the result depends upon the interaction between how the advertiser chooses to distribute sites among its advertised captures and the choices the consumer makes to distribute those among displays. And it doesn't look like there is enough information to allow the consumer to do the best possible job. But I think we need to work the examples to see this. Section 4.1 (One big scene): Issue: If the single screen endpoint wants to show 1 large image and three PiPs, then it must ask to receive 4 captures. But how could it ask for one capture that represents the whole scene, plus 3 others that are additional lower priority, and that the 3 others shouldn't have a spatial relationship with the one large one? The "Area of Display" idea would solve this issue. A 2 screen consumer would be similar to a single screen endpoint, regarding this issue. I think your example doesn't support this case. I thought the captures, while switched, each represented a single camera. I'm not sure what kind of advertisement would cover what you are questioning. Thanks, Paul From pkyzivat@alum.mit.edu Mon Jul 22 11:03:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4175911E80FB for ; Mon, 22 Jul 2013 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgxq5RQ3wo4w for ; Mon, 22 Jul 2013 11:03:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3F11E80D2 for ; Mon, 22 Jul 2013 11:03:42 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id 3UTY1m0071GhbT851W3iMu; Mon, 22 Jul 2013 18:03:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 3W3i1m0063ZTu2S3TW3ijr; Mon, 22 Jul 2013 18:03:42 +0000 Message-ID: <51ED73FD.2010604@alum.mit.edu> Date: Mon, 22 Jul 2013 14:03:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D601BC9E2A@CRPMBOXPRD07.polycom.com> <51E0705E.4040305@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601BC9E7B@CRPMBOXPRD07.polycom.com> <51E36725.80002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A3BF@CRPMBOXPRD07.polycom.com> <51E741C3.6030401@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D601D2A6E5@CRPMBOXPRD07.polycom.com> <51E75C69.2040301@nteczone.com> <51E80412.6050700@alum.mit.edu> <51ED4DBC.3030602@unina.it> In-Reply-To: <51ED4DBC.3030602@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374516222; bh=G31f6yMRyQVGw+YtD0LInCIeBwklI4ymsiGpvvDExHc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qOZ+54Rrg0fG6kM8stEWNgZpXIUK8+aa6lYwwlhqlKgjyERlHVFq6OPHPHS9vGj6e zhSaaUz3Stv1pWk5zUkC1YB/QnG/oEiRy1TZH3p+bXeHVbv0Q5iQKRJYqybx2HgaYU Q+SwcTWfuJugWzO38GuWJLrsu+0nxlCQtAq4W2QdYfWNG3GGqwqD0YCnwmDrOOxg8M DAB9cPjdvRP73DRC0jf/NJLH3ndS0FZGxIcLWhoI35lQjVOXwpeLdXIa9gvGRe7KWa YND8B/nP7JdDkzyghV8ThVqzppjGlrRD9r6+V65pPv1e/ut1zEJLom2bbSkcrvz12I a3+MvjfE4xxXg== Subject: Re: [clue] data model for specifying attribute value in Configure message X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 18:03:49 -0000 On 7/22/13 11:20 AM, Roberta Presta wrote: > Hi all, > > to summarize: > - no more as capture scene entry attribute > - the switching policy becomes a media capture attribute > - no more capture parameters in the capture encoding definition > Right? > It sounds definitely simpler than before. Buts lets see if we have consensus before changing text again. Thanks, Paul > Thanks, > > Roberta > > Il 18/07/2013 17:04, Paul Kyzivat ha scritto: >> I also waffle on this. On one hand this seems like a syntactic trick >> to reduce the size of advertisements, and that might be a good thing. >> But it does have these unintended consequences. >> >> IMO we would be better off to follow the KISS principle for now. >> If that proves to be inadequate then it can be addressed later. >> >> Thanks, >> Paul (as individual) >> >> On 7/17/13 11:09 PM, Christian Groves wrote: >>> Hello Mark, >>> >>> Actually I'm torn on this one. Being able to provide a list of values >>> and have the Consumer choose seems like a good capability to be built >>> into the protocol. However the implementation becomes problematic and >>> adds complications. I had thought about the Consumer appending the >>> mediaCaptureID i.e. 1a, 1b, 1c if it wants multiple instances but how >>> would that work with STS? Also what would be the interaction when there >>> are multiple set of attributes that have multiple values? Without a >>> simple way to introduce it may be simpler to KISS and remove the >>> captureParameters element. However if someone can come up with a way to >>> support it I'm all ears :-). >>> >>> Regards, Christian >>> >>> On 18/07/2013 11:40 AM, Duckworth, Mark wrote: >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of >>>>> Christian Groves >>>>> Sent: Wednesday, July 17, 2013 9:16 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>> Configure >>>>> message >>>>> >>>>> Hello Mark, >>>>> >>>>> What is needed is a structure that only allows one set of >>>>> captureParameters >>>>> per mediaCaptureID AND that the chosen set of captureParameters are >>>>> used >>>>> in all CaptureEncodings that reference the mediaCaptureID. This >>>>> guarantees >>>>> uniqueness. >>>> [Duckworth, Mark] Yes, this is exactly what I was trying to suggest. >>>> >>>>> Having such a restriction does have side effects. For example: if the >>>>> Provider >>>>> indicates the support of segment and site switched for one >>>>> CaptureID and >>>>> the consumer wants both types of Captures in different capture >>>>> encodings >>>>> then this would not be possible. For this to be possible the Provider >>>>> would >>>>> have to Advertise one CaptureID with "segment" and another CaptureID >>>>> with "site". If this is the case then the question is, is there any >>>>> point in having >>>>> a list of values in the first place? >>>> [Duckworth, Mark] It sounds like you and Paul are both suggesting we >>>> remove this "advertise a choice of values for the Consumer to choose >>>> from" mechanism from the scene-switch-policy attribute. Instead, just >>>> use it like all the other attributes where the Advertisement indicates >>>> the attribute and its value. Then we could also simplify the data >>>> model, removing the captureParameters element. That would be fine >>>> with me. >>>> >>>>> Regards, Christian >>>>> >>>>> >>>>> On 18/07/2013 1:45 AM, Duckworth, Mark wrote: >>>>>> Hi Christian, >>>>>> >>>>>> I think I understand your point, and it does seem like an issue in >>>>>> the data- >>>>> model-schema-00 document, section 22. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> type="captureParametersType" minOccurs="0"/> >>>>>> >>>> type="encodingParametersType" minOccurs="0"/> >>>>>> >>>>>> >>>>>> >>>>>> This structure requires the captureParameters to be specified for >>>>>> each >>>>> captureEncodingType, but this isn't what we want. I think it would >>>>> be better >>>>> to have a structure that specifies a mediaCaptureID just once, with >>>>> just one >>>>> corresponding captureParameters element, but with a list of >>>>> encodingID and >>>>> encodingParameters to represent the multiple encodings of the single >>>>> media >>>>> capture. >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>>>>> Of Christian Groves >>>>>>> Sent: Sunday, July 14, 2013 11:06 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>>> Configure message >>>>>>> >>>>>>> Hello Mark, >>>>>>> >>>>>>> I don't think the rule regarding CSE helps. The configure only lists >>>>>>> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having >>>>>>> parameters in the Configure is that effectively a CaptureID no >>>>>>> longer >>>>>>> lists a unique capture. You could in theory have a CaptureID with >>>>>>> different sets of attributes. An Advertisement could offer a >>>>>>> CaptureID with multiple values and a set of encodings. A consumer >>>>>>> could in theory return the same CaptureID multiple times with >>>>>>> different >>>>> values and the same encoding ID. >>>>>>> This would lead to the same CaptureEncoding which would cause >>>>>>> referencing issues. >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 13/07/2013 7:44 AM, Duckworth, Mark wrote: >>>>>>>> Paul, I agree it doesn't make sense to include different values of >>>>>>>> the >>>>>>> attribute for the same capture. This is related to the statement in >>>>>>> the framework in section 6.2.2 "The Consumer must choose the same >>>>>>> value for all the Media Captures in the Capture Scene Entry." So >>>>>>> for >>>>>>> me, the question is should we devise an XML schema for this such >>>>>>> that >>>>>>> it is impossible for the Consumer to construct an inconsistent >>>>>>> message? Or is it okay to have a schema with potentially redundant >>>>>>> information, thus enabling the possibility for the values to be >>>>>>> inconsistent? My proposal allows the inconsistency, and I agree it >>>>>>> would be better to avoid the redundancy and possibility of >>>>>>> inconsistency. >>>>> I could make another proposal along those lines later. >>>>>>>> Are you saying there are also other problems with attributes that >>>>>>>> can be >>>>>>> specified in the Configure message? What about specifying the >>>>>>> encoding parameters, we agreed on that before didn't we? That is >>>>>>> very similar to specifying attribute values. >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>>>>> Behalf Of Paul Kyzivat >>>>>>>>> Sent: Friday, July 12, 2013 5:09 PM >>>>>>>>> To: clue@ietf.org >>>>>>>>> Subject: Re: [clue] data model for specifying attribute value in >>>>>>>>> Configure message >>>>>>>>> >>>>>>>>> I've brought this up before, but I'll try again: >>>>>>>>> >>>>>>>>> As currently conceived, this mechanism has problems. >>>>>>>>> >>>>>>>>> Specifically, these attributes apply to captures, not >>>>>>>>> capture-encodings. >>>>>>>>> >>>>>>>>> Suppose I configure two different encodings of the same capture, >>>>>>>>> and supply different attributes to each. (E.g. one with site >>>>>>>>> switching and one with scene >>>>>>>>> switching.) >>>>>>>>> >>>>>>>>> At that point, what is the meaning of the capture? I have two >>>>>>>>> encodings which may be showing entirely different content. IMO >>>>>>>>> this >>>>>>>>> is >>>>>>> nonsense. >>>>>>>>> So I think there is a problem with attributes that can be >>>>>>>>> specified >>>>>>>>> in the configure. There are a variety of possible solutions. The >>>>>>>>> simplest is simply to disallow them. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/12/13 4:54 PM, Duckworth, Mark wrote: >>>>>>>>>> I think the data model is intended to support building a >>>>>>>>>> Configure >>>>>>>>>> message by using a list of captureEncoding elements. If so, >>>>>>>>>> there >>>>>>>>>> also needs to be a way to add parameter values of items where the >>>>>>>>>> Provider has offered a choice. >>>>>>>>>> >>>>>>>>>> From the framework: >>>>>>>>>> >>>>>>>>>> For each Media Capture in the message, the Consumer may >>>>>>>>>> also >>>>>>>>>> >>>>>>>>>> specify the value of any attributes for which the Provider >>>>>>>>>> has >>>>>>>>>> >>>>>>>>>> offered a choice, for example the value for the >>>>>>>>>> Scene-switch-policy >>>>>>>>>> >>>>>>>>>> attribute. >>>>>>>>>> >>>>>>>>>> Currently, I think Scene-switch-policy is the only attribute in >>>>>>>>>> this category. >>>>>>>>>> >>>>>>>>>> Does it make sense to add an element to do this into the >>>>>>>>>> captureEncodingType? This is similar to item 11 in my other list >>>>>>>>>> of comments http://www.ietf.org/mail- >>>>>>>>> archive/web/clue/current/msg02666.html. >>>>>>>>>> Mark >>>>>>>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Jul 22 17:41:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB7011E81C8 for ; Mon, 22 Jul 2013 17:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2k5cjirxHjl for ; Mon, 22 Jul 2013 17:41:33 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75B11E81C3 for ; Mon, 22 Jul 2013 17:41:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAK/Q7VF20Zg7/2dsb2JhbAANToM4wQCBLIMYAQEBBAEBATUbGxsLGAklDwIWMBMGAgEBiBimEJI+BJAdFoNoA6xO Received: from ppp118-209-152-59.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.152.59]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Jul 2013 10:11:30 +0930 Message-ID: <51EDD134.20206@nteczone.com> Date: Tue, 23 Jul 2013 10:41:24 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> In-Reply-To: <51ED529F.8020504@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 00:41:34 -0000 Hello Paul, I agree that a default is needed. The reason for a "no priority" I saw a case where an Advertiser for example may offer prioritised audio but choose not to prioritise video or vice versa. Rather than prioritise audio over video or vice versa which would effectively happen if all captures had a default priority level. Regards, Christian On 23/07/2013 1:41 AM, Paul Kyzivat wrote: > A couple of things I picked up while reviewing this version: > > Section 3 & Section 22: > > The schema was updated so captureEncodingType references > encodingParametersType, but there is a typo (cut/paste error I guess) > so that the intended definition of encodingParametersType actually > redefines captureParametersType. > > Section 10.7 : > > ... The higher the > importance, the lower the contained value. When media captures are > marked with a "0" priority value, it means that they are "not subject > to priority". > > [edt's note: discussion needed] > > IMO it makes no sense for some captures to be subject to priority and > others to not be subject to priority. What would that mean? The only > thing I can see is that those are *mandatory* to render. But we can't > really mandate that. If you can't do it we can't force you. So the > best it could mean is "really really important" to render. But that is > the same as having the highest priority. > > So I suggest that zero is just the highest priority - no more, no less. > > And I suggest we also make zero the *default* priority, so that all > captures have one, implicitly or explicitly. Then, if you don't > mention priority at all, then all captures are equal. And you can just > add priority for those captures that are less important. > > Equivalently, we could leave priority optional, and specify that the > absence of a priority implicitly means the highest priority. Then the > presence of priority means a lower priority. But I think this > formulation is a little more confusing to explain. > > Section 10.10. : > > is an optional element indicating wheter or not the > capture device originating the capture moves during the telepresence > session. ... > > We can't know for sure that it will move, only that it may. Also a > typo. So: > > s/moves/may move/ > s/wheter/whether/ > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Jul 22 19:48:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BADD11E81D5 for ; Mon, 22 Jul 2013 19:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvYTyJlH4Dlg for ; Mon, 22 Jul 2013 19:48:11 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDE411E8183 for ; Mon, 22 Jul 2013 19:48:10 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id 3ekU1m00117dt5G59eoAgG; Tue, 23 Jul 2013 02:48:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 3eo91m01M3ZTu2S3ZeoAu6; Tue, 23 Jul 2013 02:48:10 +0000 Message-ID: <51EDEEE9.6030408@alum.mit.edu> Date: Mon, 22 Jul 2013 22:48:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> In-Reply-To: <51EDD134.20206@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374547690; bh=ZY9Cy4YnOXTyvlDLMZ5/ZgTp/Mr0RnT82cY8gAzPwws=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N0SAsd2T0LPzOPnezjnrI31CRMRuRLnEIj5Uqzb1AwWrkSP8EI5ce1dxHnfvld3jn IaeGaUr9dBKI/laZI+SWfqB/sK7SYLRHEGM6DW2IImr7dW4e7bJ9a0NhwM7h5alZrx /sNoYvo1e2qW5aVcuAnI1oh3pyCuWhZRdAPV8qKoLDbit6QFT1a5TICm2aPaFmlx7b 7EDJloShurIyNVyyEFs9ybS64ig0QYxcmSPes2Hk76p2zA9XtOx26PSWx/Qw0AVqlP 6b+ous5nMfmE3pUa+XTV4ZvfKZHxCN8BwWMgSyAkgfo9rYBE1mr2FIgBRle4h181q+ C3XAD+vyaaO5w== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:48:16 -0000 On 7/22/13 8:41 PM, Christian Groves wrote: > Hello Paul, > > I agree that a default is needed. > > The reason for a "no priority" I saw a case where an Advertiser for > example may offer prioritised audio but choose not to prioritise video > or vice versa. Rather than prioritise audio over video or vice versa > which would effectively happen if all captures had a default priority > level. Audio and video don't "compete" with one another. I can't see how the priority processing of one would interact with the other. Perhaps we need to say something that audio and video are independently prioritized. Thanks, Paul > Regards, Christian > > On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >> A couple of things I picked up while reviewing this version: >> >> Section 3 & Section 22: >> >> The schema was updated so captureEncodingType references >> encodingParametersType, but there is a typo (cut/paste error I guess) >> so that the intended definition of encodingParametersType actually >> redefines captureParametersType. >> >> Section 10.7 : >> >> ... The higher the >> importance, the lower the contained value. When media captures are >> marked with a "0" priority value, it means that they are "not subject >> to priority". >> >> [edt's note: discussion needed] >> >> IMO it makes no sense for some captures to be subject to priority and >> others to not be subject to priority. What would that mean? The only >> thing I can see is that those are *mandatory* to render. But we can't >> really mandate that. If you can't do it we can't force you. So the >> best it could mean is "really really important" to render. But that is >> the same as having the highest priority. >> >> So I suggest that zero is just the highest priority - no more, no less. >> >> And I suggest we also make zero the *default* priority, so that all >> captures have one, implicitly or explicitly. Then, if you don't >> mention priority at all, then all captures are equal. And you can just >> add priority for those captures that are less important. >> >> Equivalently, we could leave priority optional, and specify that the >> absence of a priority implicitly means the highest priority. Then the >> presence of priority means a lower priority. But I think this >> formulation is a little more confusing to explain. >> >> Section 10.10. : >> >> is an optional element indicating wheter or not the >> capture device originating the capture moves during the telepresence >> session. ... >> >> We can't know for sure that it will move, only that it may. Also a >> typo. So: >> >> s/moves/may move/ >> s/wheter/whether/ >> >> 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 Christian.Groves@nteczone.com Mon Jul 22 21:00:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843111E81DC for ; Mon, 22 Jul 2013 21:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceVWZRaDM99C for ; Mon, 22 Jul 2013 21:00:20 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78011E8183 for ; Mon, 22 Jul 2013 21:00:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAKT+7VF20Zg7/2dsb2JhbAANToM7wQOBLIMYAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiBimEZJNBJAdg34DrE4 Received: from ppp118-209-152-59.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.152.59]) by ipmail04.adl6.internode.on.net with ESMTP; 23 Jul 2013 13:30:09 +0930 Message-ID: <51EDFFC4.1090803@nteczone.com> Date: Tue, 23 Jul 2013 14:00:04 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> In-Reply-To: <51EDEEE9.6030408@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 04:00:20 -0000 Hello Paul, "Audio and video don't "compete" with one another." Currently priorities can be set across all capture types. E.g. I can say that's more important for you to get an audio stream and a presentation stream than it is to get the video if you have to choose because of some bandwidth/display/etc contraint. It wouldn't be possible if you consider priority to be scoped to a single media. Regards, Christian On 23/07/2013 12:48 PM, Paul Kyzivat wrote: > On 7/22/13 8:41 PM, Christian Groves wrote: >> Hello Paul, >> >> I agree that a default is needed. >> >> The reason for a "no priority" I saw a case where an Advertiser for >> example may offer prioritised audio but choose not to prioritise video >> or vice versa. Rather than prioritise audio over video or vice versa >> which would effectively happen if all captures had a default priority >> level. > > Audio and video don't "compete" with one another. I can't see how the > priority processing of one would interact with the other. > > Perhaps we need to say something that audio and video are > independently prioritized. > > Thanks, > Paul > >> Regards, Christian >> >> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>> A couple of things I picked up while reviewing this version: >>> >>> Section 3 & Section 22: >>> >>> The schema was updated so captureEncodingType references >>> encodingParametersType, but there is a typo (cut/paste error I guess) >>> so that the intended definition of encodingParametersType actually >>> redefines captureParametersType. >>> >>> Section 10.7 : >>> >>> ... The higher the >>> importance, the lower the contained value. When media captures are >>> marked with a "0" priority value, it means that they are "not >>> subject >>> to priority". >>> >>> [edt's note: discussion needed] >>> >>> IMO it makes no sense for some captures to be subject to priority and >>> others to not be subject to priority. What would that mean? The only >>> thing I can see is that those are *mandatory* to render. But we can't >>> really mandate that. If you can't do it we can't force you. So the >>> best it could mean is "really really important" to render. But that is >>> the same as having the highest priority. >>> >>> So I suggest that zero is just the highest priority - no more, no less. >>> >>> And I suggest we also make zero the *default* priority, so that all >>> captures have one, implicitly or explicitly. Then, if you don't >>> mention priority at all, then all captures are equal. And you can just >>> add priority for those captures that are less important. >>> >>> Equivalently, we could leave priority optional, and specify that the >>> absence of a priority implicitly means the highest priority. Then the >>> presence of priority means a lower priority. But I think this >>> formulation is a little more confusing to explain. >>> >>> Section 10.10. : >>> >>> is an optional element indicating wheter or not the >>> capture device originating the capture moves during the telepresence >>> session. ... >>> >>> We can't know for sure that it will move, only that it may. Also a >>> typo. So: >>> >>> s/moves/may move/ >>> s/wheter/whether/ >>> >>> 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 roberta.presta@unina.it Tue Jul 23 04:39:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBC311E821C for ; Tue, 23 Jul 2013 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkDYef90VrAY for ; Tue, 23 Jul 2013 04:39:40 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 997F211E8180 for ; Tue, 23 Jul 2013 04:39:37 -0700 (PDT) Received: from [127.0.0.1] ([100.71.11.111]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6NBdYjp032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jul 2013 13:39:36 +0200 Message-ID: <51EE6B77.2060601@unina.it> Date: Tue, 23 Jul 2013 13:39:35 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> In-Reply-To: <51EDFFC4.1090803@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130723-0, 23/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:39:44 -0000 Hi all, another possibility is the following. Priority is an optional attribute. When it is absent, it is intended to be "the lowest priority". When it is present, you have to order the priority values in a way that the most important capture has the lowest numeric value. For example, if I have - the audio of the lecturer AC0, - the video of the lecturer VC0, - the video of the slides VC1, - the video of the overall room VC2 and I want to prioritize the audio of the lecturer, and then the video of the slides, I can set the priority values as follows: - AC0, priority = 1 - VC1, priority = 2 - other captures, no priority The media consumer will know that: - the most important capture is AC0 - the second one is VC1 - all the other captures have the same level of importance, which is lower than the one of AC0 and VC1. What is your feeling about it? Cheers, Roberta Il 23/07/2013 06:00, Christian Groves ha scritto: > Hello Paul, > > "Audio and video don't "compete" with one another." Currently > priorities can be set across all capture types. E.g. I can say that's > more important for you to get an audio stream and a presentation > stream than it is to get the video if you have to choose because of > some bandwidth/display/etc contraint. It wouldn't be possible if you > consider priority to be scoped to a single media. > > Regards, Christian > > On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >> On 7/22/13 8:41 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> I agree that a default is needed. >>> >>> The reason for a "no priority" I saw a case where an Advertiser for >>> example may offer prioritised audio but choose not to prioritise video >>> or vice versa. Rather than prioritise audio over video or vice versa >>> which would effectively happen if all captures had a default priority >>> level. >> >> Audio and video don't "compete" with one another. I can't see how the >> priority processing of one would interact with the other. >> >> Perhaps we need to say something that audio and video are >> independently prioritized. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>> A couple of things I picked up while reviewing this version: >>>> >>>> Section 3 & Section 22: >>>> >>>> The schema was updated so captureEncodingType references >>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>> so that the intended definition of encodingParametersType actually >>>> redefines captureParametersType. >>>> >>>> Section 10.7 : >>>> >>>> ... The higher the >>>> importance, the lower the contained value. When media captures are >>>> marked with a "0" priority value, it means that they are "not >>>> subject >>>> to priority". >>>> >>>> [edt's note: discussion needed] >>>> >>>> IMO it makes no sense for some captures to be subject to priority and >>>> others to not be subject to priority. What would that mean? The only >>>> thing I can see is that those are *mandatory* to render. But we can't >>>> really mandate that. If you can't do it we can't force you. So the >>>> best it could mean is "really really important" to render. But that is >>>> the same as having the highest priority. >>>> >>>> So I suggest that zero is just the highest priority - no more, no >>>> less. >>>> >>>> And I suggest we also make zero the *default* priority, so that all >>>> captures have one, implicitly or explicitly. Then, if you don't >>>> mention priority at all, then all captures are equal. And you can just >>>> add priority for those captures that are less important. >>>> >>>> Equivalently, we could leave priority optional, and specify that the >>>> absence of a priority implicitly means the highest priority. Then the >>>> presence of priority means a lower priority. But I think this >>>> formulation is a little more confusing to explain. >>>> >>>> Section 10.10. : >>>> >>>> is an optional element indicating wheter or not the >>>> capture device originating the capture moves during the >>>> telepresence >>>> session. ... >>>> >>>> We can't know for sure that it will move, only that it may. Also a >>>> typo. So: >>>> >>>> s/moves/may move/ >>>> s/wheter/whether/ >>>> >>>> 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 trac+clue@trac.tools.ietf.org Tue Jul 23 07:19:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F85211E8222 for ; Tue, 23 Jul 2013 07:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uQecM0a8P2s for ; Tue, 23 Jul 2013 07:19:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3411E822F for ; Tue, 23 Jul 2013 07:19:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:46919 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1dQv-0003VY-La; Tue, 23 Jul 2013 16:19:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 14:19:21 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/37 Message-ID: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723141936.26F3411E822F@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 07:19:36 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:19:37 -0000 #37: OPEN 1: Binaural Audio [REQMT-2C] The need to support of binaural audio is unresolved, and the "MUST NOT preclude" language in this requirement is problematic. The authors believe this requirement needs to be either changed or withdrawn, depending on how the issue is resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From pkyzivat@alum.mit.edu Tue Jul 23 07:45:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B4321E8051 for ; Tue, 23 Jul 2013 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDdfUvhWJeEh for ; Tue, 23 Jul 2013 07:45:15 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7711E823D for ; Tue, 23 Jul 2013 07:45:14 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta12.westchester.pa.mail.comcast.net with comcast id 3pQE1m0020mv7h05CqlDiM; Tue, 23 Jul 2013 14:45:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 3qlD1m01E3ZTu2S3XqlDNX; Tue, 23 Jul 2013 14:45:13 +0000 Message-ID: <51EE96F8.3000001@alum.mit.edu> Date: Tue, 23 Jul 2013 10:45:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374590713; bh=BS4NXsq5f81AzgQOJzj1xRPNSJV8/SDVsHnDbDv5YGU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dvQlBLJ3fwAa0I73rCjto8KcxyAzdL+WjxNeXYzt6FVepRXW5aPrBfWBcXZAgLsGp zkmTgmusdJIPBSY8xYIvd8YUv5S3OvaXMYb7KS5zFxDauDXXl3P8wabnVgfc//LUSj i5R/Wp2+GqzmlZdSH3HfjCpcjFRrMKGxWAFoR2Hd1uVyCgutOYcYsWCf9a+CdmjWqz QwMTzWoj6cpeqszsOt/QOi9sO+K3nS5Pcrl7Q2Dm78hEo+hBuP5nk1o3Tb2hcxhwDm V80vTf7J2ywI3zN+BPBrpB325fm8Tgm0RburwWNNAPfA9Lpls4kMTg5aktBhb4PGau kZ2NxNW+OSE+w== Subject: [clue] clue signaling session in Berlin X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 14:45:20 -0000 Clueful, I have posted some slides regarding signaling with the clue meeting materials: https://pub.ietf.org/proceedings/87/clue/ Those are subject to change. I request everyone to please review these before the meeting and let me know if you have any suggestions for how to improve them to facilitate making progress on signaling. What I hope to get out of this session are people, or groups of people, who agree to drive the completion of these topics. Please think about these topics, look at the draft, and think about which of these topics you care about. It will be great if we can get some discussion going on some of these topics even before the meeting. Thanks, Paul From mary.ietf.barnes@gmail.com Tue Jul 23 08:00:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97411E823A for ; Tue, 23 Jul 2013 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.8 X-Spam-Level: X-Spam-Status: No, score=-100.8 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-TjipYPoBb0 for ; Tue, 23 Jul 2013 08:00:35 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F111E8273 for ; Tue, 23 Jul 2013 08:00:20 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1681653qab.9 for ; Tue, 23 Jul 2013 08:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eUH0hQ02M3LeaDfnk/MTbB/Bf59isRB/AoLjgvruN/A=; b=gGymf/nPXUEfGZB/8sVeTNs28ovTvhHaCy6J7w+dE7PLB0kmfP2/EBHMlGS4M/HGrJ KjEnMhyeu9DWM3tL6BLp9Px1JMZB2/DL2Jv7rjBr20lA+k2XoVavM6i3HBdyZykvoVB5 +AWepvm3m8ZC5u2RNjILZSSPO9tIHX6BJvf1rrvt/3FgsO7+NpXmjNatZg0ADmSdDYrR tHy2H6xd//zbpLe8P27sIYpDMHQGUCwxipb/59u9ACx65en9kp7mQv3IhdjcnicAvoIZ yEad+AHzDPD1ZJVlucqfYH5O42c+968KsdFtYFrG1iJWAH6UN1SLrp/v46VpF/l+lyDp kVOA== MIME-Version: 1.0 X-Received: by 10.49.71.99 with SMTP id t3mr22043263qeu.46.1374591619254; Tue, 23 Jul 2013 08:00:19 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 08:00:19 -0700 (PDT) In-Reply-To: <51EE96F8.3000001@alum.mit.edu> References: <51EE96F8.3000001@alum.mit.edu> Date: Tue, 23 Jul 2013 10:00:19 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b677f582d4d3904e22f0d7f Cc: CLUE Subject: Re: [clue] clue signaling session in Berlin X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 15:00:39 -0000 --047d7b677f582d4d3904e22f0d7f Content-Type: text/plain; charset=ISO-8859-1 It would also be very helpful if folks are commenting on a specific slide/topic to add an appropriate subject line. That will make it a whole lot easier to track the specific discussions. Thanks, Mary. On Tue, Jul 23, 2013 at 9:45 AM, Paul Kyzivat wrote: > Clueful, > > I have posted some slides regarding signaling with the clue meeting > materials: https://pub.ietf.org/**proceedings/87/clue/ > > Those are subject to change. I request everyone to please review these > before the meeting and let me know if you have any suggestions for how to > improve them to facilitate making progress on signaling. > > What I hope to get out of this session are people, or groups of people, > who agree to drive the completion of these topics. Please think about these > topics, look at the draft, and think about which of these topics you care > about. > > It will be great if we can get some discussion going on some of these > topics even before the meeting. > > Thanks, > Paul > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7b677f582d4d3904e22f0d7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would also be very helpful if folks are commenting on a= specific slide/topic to add an appropriate subject line. =A0That will make= it a whole lot easier to track the specific discussions.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:45 AM, Paul Kyzivat <p= kyzivat@alum.mit.edu> wrote:
Clueful,

I have posted some slides regarding signaling with the clue meeting materia= ls: https://pub.ietf.org/proceedings/87/clue/

Those are subject to change. I request everyone to please review these befo= re the meeting and let me know if you have any suggestions for how to impro= ve them to facilitate making progress on signaling.

What I hope to get out of this session are people, or groups of people, who= agree to drive the completion of these topics. Please think about these to= pics, look at the draft, and think about which of these topics you care abo= ut.

It will be great if we can get some discussion going on some of these topic= s even before the meeting.

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

--047d7b677f582d4d3904e22f0d7f-- From trac+clue@trac.tools.ietf.org Tue Jul 23 08:02:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59611E8282 for ; Tue, 23 Jul 2013 08:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SZJsnZiZpKg for ; Tue, 23 Jul 2013 08:02:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9476111E8276 for ; Tue, 23 Jul 2013 08:01:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:50737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1e5v-0007eA-N2; Tue, 23 Jul 2013 17:01:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:01:43 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/38 Message-ID: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150147.9476111E8276@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:01:47 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:02:49 -0000 #38: OPEN-2 Reference to Rendering [REQMT-3b] This is the only requirement which refers to rendering. It may also be empty, since receivers can render audio captures as they wish. This is deferred until broader discussion on rendering requirements is concluded. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jul 23 08:02:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1BE11E8285 for ; Tue, 23 Jul 2013 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhlrPMyXKNwW for ; Tue, 23 Jul 2013 08:02:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B091E11E8286 for ; Tue, 23 Jul 2013 08:02:50 -0700 (PDT) Received: from localhost ([127.0.0.1]:50891 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1e6w-0000sT-2z; Tue, 23 Jul 2013 17:02:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:02:46 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/39 Message-ID: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150250.B091E11E8286@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:02:50 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #39: OPEN-3 Conference modes [REQMT-14] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:02:58 -0000 #39: OPEN-3 Conference modes [REQMT-14] This wording of this requirement is problematic in part because the conference modes (site switching and segment switching) are not defined. It at least needs rewording. This is deferred until broader discussion on layout is concluded. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: defect | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jul 23 08:03:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991111E8276 for ; Tue, 23 Jul 2013 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp-PgRRJC-9G for ; Tue, 23 Jul 2013 08:03:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 214F011E8275 for ; Tue, 23 Jul 2013 08:03:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:51101 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1e7o-0008Pk-LH; Tue, 23 Jul 2013 17:03:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:03:40 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/38#comment:1 Message-ID: <083.ffd08dd0c6210f560284318d7cabe4c6@trac.tools.ietf.org> References: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150344.214F011E8275@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:03:44 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:03:44 -0000 #38: OPEN-2 Reference to Rendering [REQMT-3b] Changes (by mary.ietf.barnes@gmail.com): * severity: - => Active WG Document -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jul 23 08:05:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8711E8285 for ; Tue, 23 Jul 2013 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yplFLwfDM9+c for ; Tue, 23 Jul 2013 08:05:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA711E827E for ; Tue, 23 Jul 2013 08:05:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:51374 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1e94-0006Ov-3n; Tue, 23 Jul 2013 17:04:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:04:58 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/40 Message-ID: <068.a8190a00ee0b53b4b9ba1ca7a491ddb0@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150500.ACCA711E827E@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:05:00 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #40: OPEN-4 New Requirement - attribute changes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:05:04 -0000 #40: OPEN-4 New Requirement - attribute changes Need to capture requirement that attributes can change at any time during the call. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: task | requirements@tools.ietf.org Priority: minor | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jul 23 08:05:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1192F11E8276 for ; Tue, 23 Jul 2013 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHPlweaeUtIh for ; Tue, 23 Jul 2013 08:05:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4BF11E8275 for ; Tue, 23 Jul 2013 08:05:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:51553 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1e9o-0003QW-7o; Tue, 23 Jul 2013 17:05:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:05:44 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/41 Message-ID: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150553.3E4BF11E8275@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:05:53 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #41: OPEN-5. New Requirement - 3D X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:05:54 -0000 #41: OPEN-5. New Requirement - 3D Need to add requirement for three dimensions in the right place -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Jul 23 08:07:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26D011E8275 for ; Tue, 23 Jul 2013 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5mAwTmmRkjS for ; Tue, 23 Jul 2013 08:07:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 20A4411E823D for ; Tue, 23 Jul 2013 08:07:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:51667 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V1eAk-0003uk-Fl; Tue, 23 Jul 2013 17:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 23 Jul 2013 15:06:42 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/42 Message-ID: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130723150711.20A4411E823D@ietfa.amsl.com> Resent-Date: Tue, 23 Jul 2013 08:07:11 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:07:11 -0000 #42: OPEN-6. Multi-view Is there a requirement needed? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Tue Jul 23 10:05:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4111E82EC for ; Tue, 23 Jul 2013 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAj8ZW1lNLI8 for ; Tue, 23 Jul 2013 10:05:42 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC4311E82E7 for ; Tue, 23 Jul 2013 10:05:39 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bv4so1736736qab.8 for ; Tue, 23 Jul 2013 10:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bCvblM/Vev529Qs85wIjpWqnuGJQCfzR2VbGG+rpQaA=; b=hqHUyeWiaj9fizL9082F6OlsScRxB0wMeWYMz7AbNiEGkZ+fg/6sX6QISN4jSw5krj 2yxoMHr3cQ0oQTs0Crm2W3HUlYeMvBPCReD+AFSrzUCLYWaT+RvEXRziVIIhEZxOfvwn wXyTabPvRbYsWddkhZYMSHPdq7fa3VSel9geS/8vaVZ3ivIO1gvRSAVB+csvK/CPikPy qhvkt6KKMVOYJAl8gxr9/xEj6eBgJfUY4yO1HqQgM5bllVixsdiz60+sxsnCeTpKhLBH 4yWsuEt9txIn1KrGprWYhwcsv1wZZSFTp9oXaDkQP/B+By9zUwLRFdk1XHC1JP5uqNvJ o9Ig== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr7194298qaj.57.1374599138879; Tue, 23 Jul 2013 10:05:38 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:05:38 -0700 (PDT) In-Reply-To: <068.a8190a00ee0b53b4b9ba1ca7a491ddb0@trac.tools.ietf.org> References: <068.a8190a00ee0b53b4b9ba1ca7a491ddb0@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:05:38 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3e0e461ade604e230cdd9 Subject: Re: [clue] #40: OPEN-4 New Requirement - attribute changes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:05:43 -0000 --001a11c3e0e461ade604e230cdd9 Content-Type: text/plain; charset=ISO-8859-1 I would like to propose that we close this issue. I do not believe we need anything beyond REQMT-17, which first appeared in the -02 version. The issue was first added in the -01, so I'm suspecting that the issue list just wasn't updated. REQMT-17: The solution must support a mechanism for allowing information about media captures to change during a conference. If no one raises an issue (with a detailed reason) about closing this one by August 12th, 2013, I'll close it. Mary. On Tue, Jul 23, 2013 at 10:04 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #40: OPEN-4 New Requirement - attribute changes > > Need to capture requirement that attributes can change at any > time during the call. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: task | requirements@tools.ietf.org > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --001a11c3e0e461ade604e230cdd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would like to propose that we close this issue. =A0I do = not believe we need anything beyond REQMT-17, which first appeared in the -= 02 version. =A0The issue was first added in the -01, so I'm suspecting = that the issue list just wasn't updated.

REQMT-17: =A0The solution must support a mechanism for allowi= ng
=A0 =A0 =A0 =A0 =A0 =A0 =A0 information about media captures t= o change during a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 conference.


If no one raises an issue (with a = detailed reason) about closing this one by August 12th, 2013, I'll clos= e it.

= Mary.=A0


On Tue, Jul 23, 2013 at 10:04 AM, clue issue tracker <trac+clue@trac.tools.ietf.org> wrote:
#40: OPEN-4 =A0New Requirement - attribute c= hanges

=A0Need to capture requirement that attributes can change at any
=A0time during the call.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0task =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0requirements@tools.ietf.org =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/40&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--001a11c3e0e461ade604e230cdd9-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:17:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331FF11E823F for ; Tue, 23 Jul 2013 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 269dyeMose7k for ; Tue, 23 Jul 2013 10:17:24 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 319DD11E81A9 for ; Tue, 23 Jul 2013 10:17:24 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so1589956qab.17 for ; Tue, 23 Jul 2013 10:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/AS4iHXqyhGVVVvGmnptLhD5gnlHxQP+8wTOwlGefgg=; b=hMToMMD4wnAABkoZ5vRAhszgYuTKEEjuXZ8iL/+MsJRa3flsnG/V2/lPhMM2bx0Y7C N44z/boSHjCuRzV59U8zEAFfZZ/K8VIof7yF4yyElVX7K5ubp8bZV4vam1lrMUytE0MW 7D+A1rrI6eE/cK6QwFfNYTVshJYfQnKdjmu7rOO7ybuExvKq4dxJrCx6DSbcHOmykAKm NpgPkllWy2rkpQ4wbdsrNLjdUqejtJYm1CQ75u0JL+BDseTn6koXQaTKLfYg30lcUHw5 Ow3L4IeCKkyYtqAinGH2g6QTHKMnq8hzRESagfDzaobeEyFRKUZvX592m2yeyEqCZMtX xCyw== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr39489224qeb.8.1374599843609; Tue, 23 Jul 2013 10:17:23 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:17:23 -0700 (PDT) In-Reply-To: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:17:23 -0500 Message-ID: From: Mary Barnes To: clue issue tracker Content-Type: multipart/alternative; boundary=047d7bdcace463027104e230f71a Cc: CLUE , draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:17:25 -0000 --047d7bdcace463027104e230f71a Content-Type: text/plain; charset=ISO-8859-1 My suggestion is to define the terms "site switching" and "segment switching" in this document using terminology consistent with this document. NOte, that these terms don't explicitly appear in the terminology section of the framework, however, they are clearly described in 6.2.2. So I think we can borrow some of that text and add a definition to the requirements document and close this issue. My suggestion is something like: Site-switching: there is a fixed relation between the cameras in each room and the displays in remote rooms. The room or participants being shown is switched from time to time based on who is speaking or by manual control. Segment-switching: there is a variable relation between the cameras in each room and the displays in different rooms. Rather than sending all the images from a room, only the image with the active speaker is sent from a specific room. Therefore the screens in each site are usually displaying images from different remote sites - the current speaker at site A and the previous ones. Please make suggestions if you have alternative wording. I'd like to get this issue closed no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #39: OPEN-3 Conference modes [REQMT-14] > > This wording of this requirement > is problematic in part because the conference modes (site > switching and segment switching) are not defined. It at > least needs rewording. This is deferred until broader > discussion on layout is concluded. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: defect | requirements@tools.ietf.org > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --047d7bdcace463027104e230f71a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My suggestion is to define the terms "site switching&= quot; and "segment switching" in this document using terminology = consistent with this document. =A0NOte, that these terms don't explicit= ly appear in the terminology section of the framework, however, they are cl= early described in 6.2.2. =A0So I think we can borrow some of that text and= add a definition to the requirements document and close this issue. =A0My = suggestion is something like:

Site-switching:=A0there is a fixed relation between the cameras in = each room = and the displays in remote rooms. The room or participants being shown is swi= tched from time to time based on who is speaking or by manual control.<= /font>

Segment-switching: there is a variable relation between the cameras i= n each room and the displays in different rooms. Rather than sending all the i= mages from a room, only the image with the active speaker is sent from a sp= ecific room. Therefore the screens in each site are usually displaying images = from different remote sites - the current speaker at site A an= d the previous ones.

Please make suggestions if you have alternative wording. I'd like= to get this issue closed no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 10:02 AM, clue i= ssue tracker <trac+clue@trac.tools.ietf.org> wro= te:
#39: OPEN-3 =A0Conference modes [REQMT-14]
=A0This wording of this requirement
=A0is problematic in part because the conference modes (site
=A0switching and segment switching) are not defined. =A0It at
=A0least needs rewording. =A0This is deferred until broader
=A0discussion on layout is concluded.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0requirements@tools.ietf.org
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/39&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--047d7bdcace463027104e230f71a-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:26:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A6111E8300 for ; Tue, 23 Jul 2013 10:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE07-Pxylozh for ; Tue, 23 Jul 2013 10:26:48 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 954F111E8126 for ; Tue, 23 Jul 2013 10:26:48 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so4480949qcx.35 for ; Tue, 23 Jul 2013 10:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QOR3yYuDrwjmba5zv5Cdfd6reHzPPHyQ7T4/HPP4FNA=; b=w83a66UH2tQO0eK4iOg9InYCmKNC3Siz/T38MkgAl9lPiOyo1QvCLObxwIF+1OrlgT 01oziX3H62zjkPWl5KzfsP1nyO7Ng8Jf6xuYKAzRIVC97n/D1nUcp2fe3KIJvtFRRTRD 4EwDDDfVkcTLEDI+iBGUD9xVGRhqS3ABqL6rbhPzA3QxI3nE7BaDH5lNwejP9DKTlnzl ff1kId2qYvMwFZQlhMbxrZH6uOqJIZ5xm0VNd0BlOv7JtOG/mmjhyU+0NXuRpjmQ/msI bzKPPpHFhtZdsFh5+J82+tYQnSBy8azVkB8lejXLsw17suzVGK2wN4OvxcXLrEHAJwC2 7OqQ== MIME-Version: 1.0 X-Received: by 10.229.163.4 with SMTP id y4mr9315125qcx.4.1374600408053; Tue, 23 Jul 2013 10:26:48 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:26:47 -0700 (PDT) In-Reply-To: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> References: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:26:47 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04446a1307bd7704e2311992 Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:26:49 -0000 --f46d04446a1307bd7704e2311992 Content-Type: text/plain; charset=ISO-8859-1 I see two ways to resolve this one. We either change the word "render" to something more specific OR define the term "Render" in this document. Render is defined in the FW as: Render: the process of generating a representation from a media, such as displayed motion video or sound emitted from loudspeakers. My suggestion to resolve this one is to just change the replace the word "render" to something more general. Perhaps changing the requirement as follows: OLD: REQMT-3b: The solution MUST enable individual audio streams to be rendered in any desired spatial position. NEW: REQMT-3b: The solution MUST enable individual audio streams to be emitted from a specific speaker based on spatial information. Please provide comments on this proposed change no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 10:01 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #38: OPEN-2 Reference to Rendering [REQMT-3b] > > This is the only > requirement which refers to rendering. It may also be empty, > since receivers can render audio captures as they wish. > This is deferred until broader discussion on rendering > requirements is concluded. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: enhancement | requirements@tools.ietf.org > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: - | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --f46d04446a1307bd7704e2311992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I see two ways to resolve this one. =A0We either change th= e word "render" to something more specific OR define the term &qu= ot;Render" in this document. =A0Render is defined in the FW as:
Render: the process of generating a representation from a media,
   such as displayed motion video or sound emitted from loudspeakers.
=
My suggestion to resolve this one is to just change the r= eplace the word "render" to something more general. =A0Perhaps ch= anging the requirement as follows:

OLD:=A0
REQMT-3b: =A0The solution MUST e= nable individual audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0streams to be rendered in any desired spatial
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0position.

NEW:=A0
REQMT-3b: =A0The solution = MUST enable individual audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0streams to be emitted from a specific speaker based on=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spatial informat= ion.

Please provide comments on this proposed change n= o later than August 12, 2013.

Thanks,
Ma= ry.


On T= ue, Jul 23, 2013 at 10:01 AM, clue issue tracker <trac+clue@tr= ac.tools.ietf.org> wrote:
#38: OPEN-2 =A0Reference to Rendering [REQMT= -3b]

=A0This is the only
=A0requirement which refers to rendering. =A0It may also be empty,
=A0since receivers can render audio captures as they wish.
=A0This is deferred until broader discussion on rendering
=A0requirements is concluded.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keyw= ords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/38&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--f46d04446a1307bd7704e2311992-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:29:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348111E830C for ; Tue, 23 Jul 2013 10:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l26EQbD0EHjf for ; Tue, 23 Jul 2013 10:29:39 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0591B11E8306 for ; Tue, 23 Jul 2013 10:29:38 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id k14so4456694qcv.34 for ; Tue, 23 Jul 2013 10:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g1Midp+T5dkNal4TInJ38Tb5YykyIdxqvgwIXZMTuCI=; b=EGJ24WI95ljfi6Pz32AtNh+8/PIdb6h9YdZ+iRGv2Lfo5hmCBbVfucguyhwHNtIerd ssRWiE4fc2LCYtS9JUxtJ2hIFduk8TsX/YbaJvj5YxqfRRDiqdv2p5vyzi6NZkEpG9ii C500pcFta16+gnQreUd2wyTp7g9Y3uqztp4PNYeSCa1SXi4elgygEmlyaB8TOYeAO1en fNdsS8ujrmiOosIyrysOGvln1BWMOw4/pDAhp2cI8Nahbbl0slTW61AvyWvByA22tfdL XtM06rWx916U7M+RNMl12IsehB1booCK+I0daSVcUjgOEjl6fctXmU6wR3nFbGJaD5yB c5WQ== MIME-Version: 1.0 X-Received: by 10.49.26.202 with SMTP id n10mr39614253qeg.60.1374600578446; Tue, 23 Jul 2013 10:29:38 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:29:38 -0700 (PDT) In-Reply-To: <92959912-ABDB-4406-98D1-C30A5AA702FC@unina.it> References: <51EE96F8.3000001@alum.mit.edu> <92959912-ABDB-4406-98D1-C30A5AA702FC@unina.it> Date: Tue, 23 Jul 2013 12:29:38 -0500 Message-ID: From: Mary Barnes To: Simon Pietro Romano Content-Type: multipart/alternative; boundary=047d7b6d970c2fba0d04e2312372 Cc: CLUE Subject: Re: [clue] clue signaling session in Berlin X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:29:40 -0000 --047d7b6d970c2fba0d04e2312372 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah - he sent the link for the WG chair submission page. Try this one: http://www.ietf.org/proceedings/87/slides/slides-87-clue-0.pptx Mary. On Tue, Jul 23, 2013 at 12:23 PM, Simon Pietro Romano wr= ote: > Hi Paul, > > it looks like we need to be authenticated by the server in order to get > the slides. > > Simon > > Il giorno 23/lug/2013, alle ore 16:45, Paul Kyzivat ha scritto: > > Clueful, > > I have posted some slides regarding signaling with the clue meeting > materials: https://pub.ietf.org/proceedings/87/clue/ > > Those are subject to change. I request everyone to please review these > before the meeting and let me know if you have any suggestions for how to > improve them to facilitate making progress on signaling. > > What I hope to get out of this session are people, or groups of people, > who agree to drive the completion of these topics. Please think about the= se > topics, look at the draft, and think about which of these topics you care > about. > > It will be great if we can get some discussion going on some of these > topics even before the meeting. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_= / > > > > > > --047d7b6d970c2fba0d04e2312372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah - he sent the link for the WG chair submission page. = =A0Try this one:=A0

Mary.

<= br>
On Tue, Jul 23, 2013 at 12:23 PM, Simon Pietr= o Romano <spromano@unina.it> wrote:
Hi Paul,=

it looks like we need to be authenticated by the server= in order to get the slides.

Simon

Il giorno 23/lug/2013, al= le ore 16:45, Paul Kyzivat ha scritto:

Clueful,

I have posted some slides regard= ing signaling with the clue meeting materials: https://pub.ietf.org/proceeding= s/87/clue/

Those are subject to change. I request everyone to please review these = before the meeting and let me know if you have any suggestions for how to i= mprove them to facilitate making progress on signaling.

What I hope = to get out of this session are people, or groups of people, who agree to dr= ive the completion of these topics. Please think about these topics, look a= t the draft, and think about which of these topics you care about.

It will be great if we can get some discussion going on some of these t= opics even before the meeting.

= Thanks,
Paul
___= ____________________________________________
clue mailing list
clu= e@ietf.org
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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0( O-O )
=A0 =A0~~~~~~~~= ~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Simon Pietro Romano
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Universita' di Napoli Federico II
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0Computer Engineering Department=A0
=A0 =A0 =A0=A0 =A0 =A0 =A0 Phone: = +39 081 7683823 -- Fax: +39 081 7683816
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0e-mail: spromano@unina.it

=A0 =A0 <<Molti mi dicono che lo scoraggiame= nto =CB l'alibi degli=A0
=A0=A0 =A0idioti. Ci rif= letto un istante; e mi scoraggio>>. Magritte.
=A0 =A0 =A0 = =A0=A0 =A0 =A0 =A0=A0 <= /span>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 ~~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~~=A0Oooo~~~~~~~~~~~~~~~~~~~~~~~~~<= /div>
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0 =A0 =A0 =A0) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= (_/






--047d7b6d970c2fba0d04e2312372-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:33:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F7611E830B for ; Tue, 23 Jul 2013 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.06 X-Spam-Level: X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ydF-PsKxuWV for ; Tue, 23 Jul 2013 10:33:40 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 33B2211E823F for ; Tue, 23 Jul 2013 10:33:40 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so4721354qeb.30 for ; Tue, 23 Jul 2013 10:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2HvyT5B23ExDaZUU0736gA7Q2BX8dLNfO6G/EYNoaTs=; b=t20IXsWc+V0/qnhgCyG7439tdZLOvAEK9S0oBwskxwmPCPuNxNSCQmm1kRwT3Y77FT qGlU3ULVUK3fsNowxtEbl8Oo3t5Zwk2BAlRzDvWgJQv8SNhFKMFz0vRMAIWVqTXZCJ75 +sPM0OvPjIJZfdflIKAS8+tkz9sXGHmSIUgGv/k/20YSwwrYdqsf5JWOVGNkctAvcRKq 16vUH3zGgQKsQNyGoumPFt4IXxNdvYQJBmjYJ8EUSqlnZgKJijKphwHtRNXNvDh1Y6yj EhzvBu9i5irqByn7ebyijHATsMVXDw//z4BUQvXhL+m9BFwRkUSGSddx2YiPwro2GqiJ /UfQ== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr7331313qaj.57.1374600819526; Tue, 23 Jul 2013 10:33:39 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:33:39 -0700 (PDT) In-Reply-To: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:33:39 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3e0e48e550204e2313115 Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:33:41 -0000 --001a11c3e0e48e550204e2313115 Content-Type: text/plain; charset=ISO-8859-1 My suggestion is to just remove this requirement. We haven't discussed it at all in the framework as far as I can tell and it's not in the use cases. I know we talked about this way, way early on. But, at this point, I think we should consider it out of scope. We have the extensibility requirement, so I think that's sufficient in terms of not precluding additional new behaviors in the future. If you have any concerns about removing this requirement and closing this issue, please respond no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 9:19 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #37: OPEN 1: Binaural Audio [REQMT-2C] > > The need to support of binaural > audio is unresolved, and the "MUST NOT preclude" language in > this requirement is problematic. The authors believe this > requirement needs to be either changed or withdrawn, > depending on how the issue is resolved. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: enhancement | requirements@tools.ietf.org > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --001a11c3e0e48e550204e2313115 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My suggestion is to just remove this requirement. =A0We ha= ven't discussed it at all in the framework as far as I can tell and it&= #39;s not in the use cases. =A0I know we talked about this way, way early o= n. But, at this point, I think we should consider it out of scope. =A0We ha= ve the extensibility requirement, so I think that's sufficient in terms= of not precluding additional new behaviors in the future.=A0

If you have any concerns about removing this requirement and= closing this issue, please respond no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:19 AM, clue is= sue tracker <trac+clue@trac.tools.ietf.org> wrot= e:
#37: OPEN 1: Binaural Audio [REQMT-2C]

=A0The need to support of binaural
=A0 audio is unresolved, and the "MUST NOT preclude" language in<= br> =A0 this requirement is problematic. =A0The authors believe this
=A0 requirement needs to be either changed or withdrawn,
=A0 depending on how the issue is resolved.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/37&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--001a11c3e0e48e550204e2313115-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:36:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73511E8307 for ; Tue, 23 Jul 2013 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l0zjVNRf3yv for ; Tue, 23 Jul 2013 10:36:20 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 574D111E823F for ; Tue, 23 Jul 2013 10:36:20 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so1607004qab.14 for ; Tue, 23 Jul 2013 10:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ng4xwGxlXebqYe5ElsqTQJ04iMKIuLiMNYhQ2/myK+I=; b=fyXw/7ZA/C0Lt2mRFJo3P+RwBogzjlxRUJ4E+paN0KGDgOufbEzWL7Otda95HmmiZx CP4OebQrSFCJRIsFxa0K759bGuiLP1peQDpUpdLnezgP9alFb2uJ85/1wDtHVoHYDg5w h3lrkntV0GrE5hULS8BCQIPEIkCwnv9wvNnsyoCmHcpVampWJGokYB5ZOCTbk/ultzrM u+bsyLwoMwFSp/tRpkjSIyDfwltGl2rjn4d7SFDG98eI+5G+EAZrMXetX4o+JsT/FUbv 4cWs0eIMQPIstTzlffdSl5r1wV14cmBAkM57Rvw2/YKztWTNHG/epcWD1BS+03T0SGOQ dzSg== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr39578344qeb.8.1374600979211; Tue, 23 Jul 2013 10:36:19 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:36:19 -0700 (PDT) In-Reply-To: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:36:19 -0500 Message-ID: From: Mary Barnes To: clue issue tracker Content-Type: multipart/alternative; boundary=047d7bdcace412ec9304e2313b03 Cc: CLUE , draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:36:21 -0000 --047d7bdcace412ec9304e2313b03 Content-Type: text/plain; charset=ISO-8859-1 I propose to just close this issue with the answer being "No". I don't know even what's meant by that term - it's not used in the FW or usecases. If you have any concerns, or you have more info about what this is intended for, please respond no later than August 12, 2013. Mary. On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #42: OPEN-6. Multi-view > > Is there a requirement needed? > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: enhancement | requirements@tools.ietf.org > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --047d7bdcace412ec9304e2313b03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I propose to just close this issue with the answer being &= quot;No". =A0I don't know even what's meant by that term - it&= #39;s not used in the FW or usecases.

If you have any co= ncerns, or you have more info about what this is intended for, please respo= nd no later than August 12, 2013.

Mary.


On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracke= r <trac+clue@trac.tools.ietf.org> wrote:
#42: OPEN-6. =A0Multi-view

=A0Is there a requirement needed?

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/42&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--047d7bdcace412ec9304e2313b03-- From mary.ietf.barnes@gmail.com Tue Jul 23 10:44:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7411E8312 for ; Tue, 23 Jul 2013 10:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TKfR92NGnVt for ; Tue, 23 Jul 2013 10:44:47 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 764A611E8306 for ; Tue, 23 Jul 2013 10:44:47 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 1so1028886qec.36 for ; Tue, 23 Jul 2013 10:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+sExmHWwHk9a31Cg3nULwyxCnV3bv9wsWt6SvDR6ACM=; b=lybp9MyZ3hHhn+hjUHmjhlzPYLFMDRuUf2mEphDGfg6nsgelmQGQsGQ83cSu6iOocC g1UoOybI69vDds1XeHdHEwzxbehczn+KQUBeObDRKuDh7yqGKtNCGxy1M1SEexmzXOz+ s2SqIbwSKsuxJsKLJWsgSH0oGKQiCY9AmhHnkmiWuIdrIHNGyph1q+i4YpWQyYDl+HL4 Ikg7P8ChszXFnbryYt15xNePzhTrRMDUWVphlYAiCS3Yx2R7y3LOgcxZzPd9aarRBi57 ogYssWqyXxwxY7tOC/gj4YJThIdMk5A6NT8mGmg4xJU7w5IIXwVxFiXvch2KZlLHJ+nD sCdQ== MIME-Version: 1.0 X-Received: by 10.229.163.4 with SMTP id y4mr9334301qcx.4.1374601486883; Tue, 23 Jul 2013 10:44:46 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 10:44:46 -0700 (PDT) In-Reply-To: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> References: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> Date: Tue, 23 Jul 2013 12:44:46 -0500 Message-ID: From: Mary Barnes To: clue issue tracker Content-Type: multipart/alternative; boundary=f46d04446a135561df04e23159f2 Cc: CLUE , draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #41: OPEN-5. New Requirement - 3D X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 17:44:48 -0000 --f46d04446a135561df04e23159f2 Content-Type: text/plain; charset=ISO-8859-1 I propose to close this issue. We don't have a use case and it hasn't been discussed in the context of the framework. This was something we talked about early on, but I do not believe it's required for our initial deliverables. If you have concerns about closing this issue, then please respond no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 10:05 AM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #41: OPEN-5. New Requirement - 3D > > Need to add requirement for three dimensions in the right > place > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: enhancement | requirements@tools.ietf.org > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > --f46d04446a135561df04e23159f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I propose to close this issue. =A0We don't have a use = case and it hasn't been discussed in the context of the framework. =A0T= his was something we talked about early on, but I do not believe it's r= equired for our initial deliverables.=A0

If you have concerns about closing this issue, then please r= espond no later than August 12, 2013.

Thanks,
Mary.=A0


On Tue, Jul 23, 2013 at 10:05 AM, clue issue tracker <= trac+clu= e@trac.tools.ietf.org> wrote:
#41: OPEN-5. =A0New Requirement - 3D

=A0Need to add requirement for three dimensions in the right
=A0place

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ietf.barnes@gmail.co= m =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/41&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--f46d04446a135561df04e23159f2-- From mary.ietf.barnes@gmail.com Tue Jul 23 11:09:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52D311E8336 for ; Tue, 23 Jul 2013 11:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.43 X-Spam-Level: X-Spam-Status: No, score=-101.43 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWAR8cNr5yaI for ; Tue, 23 Jul 2013 11:09:34 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB79411E8346 for ; Tue, 23 Jul 2013 11:09:18 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so1627271qab.14 for ; Tue, 23 Jul 2013 11:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wwNEUU22XAKmRwJFCBtcZn4WiF0aAkONEwvSWQcOcSs=; b=CdJiB0SNsOTRG/RXiNN2KepfFIoxOel1HRh6OwPFSIcq0FYC0IblMjlyUA3FmYvWSn T4q6DNdE9UT4fulfCKM1A7XwMSY1GC8igAAA/AQZrR9AQ9uq8pnu0Q/Kt8ZeXXmPszHa /v3aAjfQ3JNsLSLZgtiJ3AzDzqT5VtCpj+k8jcYGAMl7I+Y4nlZ4UZN4MYI5jFsxIDXe DbwcIYb4anSfqqJeVe17nTeu+aYiqoJ3R4ocnCritGTdgQ62d7AtorofJRfaomT0u/hk +4QrHQm3K2gSpHyhNz4zTZ3V6uSpRMf+ifHiSOvKY6hPzHif2DVWHEs+GfbVxUdihexR cLNg== MIME-Version: 1.0 X-Received: by 10.224.161.76 with SMTP id q12mr23202810qax.3.1374602957972; Tue, 23 Jul 2013 11:09:17 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 11:09:17 -0700 (PDT) In-Reply-To: <51E75A6C.3090707@nteczone.com> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> Date: Tue, 23 Jul 2013 13:09:17 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e0149528e046ac704e231b1f3 Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 18:09:38 -0000 --089e0149528e046ac704e231b1f3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks very much for your detailed review and comments with regards to whether the REQ is currently supported in the solution. I have a few comments below. Thanks, Mary As editor for the Requirements do On Wed, Jul 17, 2013 at 10:01 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > I did a review of the requirements and Appendix to see if they are met. M= y > comments are below. Sorry for the length of the email but I figured it > would be easier for people to read my comment [CNG] along with the > requirement. > > REQMT-1:The solution MUST support a description of the spatial > > arrangement of source video images sent in video streams > > which enables a satisfactory reproduction at the receiver > > of the original scene.This applies to each site in a > > point to point or a multipoint meeting and refers to the > > spatial ordering within a site, not to the ordering of > > images between sites. > > [CNG] Supported =96 via Capture Area attribute. > > Use case point to point symmetric, and all other use cases. > > REQMT-1a:The solution MUST support a means of allowing > > the preservation of the order of images in the > > captured scene.For example, if John is to > > Susan's right in the image capture, John is > > also to Susan's right in the rendered image. > > [CNG] Supported =96 via Capture Area attribute. > > REQMT-1b:The solution MUST support a means of allowing > > the preservation of order of images in the > > scene in two dimensions - horizontal and > > vertical. > > [CNG] Supported =96 via Capture Area attribute. > > REQMT-1c:The solution MUST support a means to identify > > the point of capture of individual video > > captures in three dimensions. > > [CNG] Supported =96 via Point of capture attribute. > > REQMT-1d:The solution MUST support a means to identify > > the extent of individual video captures in > > three dimensions. > > [CNG] Partial =96 Capture area attribute allows the specification of a pl= ane > of capture in 3 dimensions. However depth of the capture (needed for a 3D > area) is not supported. > [MB] Per my comments on open issue 5 from the requirements document (and Ticket # 41 in the tracker), I was proposing we not require 3D in the solution at this time. [/MB] > > REQMT-2:The solution MUST support a description of the spatial > > arrangement of captured source audio sent in audio streams > > which enables a satisfactory reproduction at the receiver > > in a spatially correct manner.This applies to each site > > in a point to point or a multipoint meeting and refers to > > the spatial ordering within a site, not the ordering of > > channels between sites. > > [CNG] Supported =96 Via Capture Area attribute. > > Use case point to point symmetric, and all use cases, > > especially heterogeneous. > > REQMT-2a:The solution MUST support a means of preserving > > the spatial order of audio in the captured > > scene.For example, if John sounds as if he is > > at Susan's right in the captured audio, John > > voice is also placed at Susan's right in the > > rendered image. > > [CNG] Supported =96 Via Capture Area attribute. > > REQMT-2b:The solution MUST support a means to identify > > the number and spatial arrangement of audio > > channels including monaural, stereophonic > > (2.0), and 3.0 (left, center, right) audio > > channels. > > [CNG] Partial =96 the Audio Channel Format attribute currently only suppo= rts > =93mono=94 and =93stereo=94. It doesn=92t support the 3.0 format [MB] So, my question to the group is do we need to support this in the current work is is this something that could be extended later. I looked fairly quickly but I also could not find a use case for 3.0[/MB] > > REQMT-2c:The solution MUST NOT preclude the use of > > binaural audio.[Edt. This is an outstanding > > issue.Text will be changed when the issue is > > resolved.] > > [CNG] Partial? =96 Binaural isn=92t mentioned in the framework so isn=92t > precluded as such. There is no indication in CLUE recording a binaural > capture. > [MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we just delete this requirement. [/MB] > > REQMT-2d:The solution MUST support a means to identify > > the point of capture of individual audio > > captures in three dimensions. > > [CNG] Supported =96 via Point of capture attribute. > > REQMT-2e:The solution MUST support a means to identify > > the extent of individual audio captures in > > three dimensions. > > [CNG] Partial =96 The Capture area attribute is based on capturing a plan= e > in Cartesian space. There is no depth parameter. Whether the plane concep= t > holds for audio like it does video needs further thought. > > REQMT-3:The solution MUST support a mechanism to enable a > > satisfactory spatial matching between audio and video > > streams coming from the same endpoints. > > [CNG] Supported - The given that an Advertiser places captures in a > particular scene it is possible to indicate audio and video streams are > from the same endpoint. > > Use case is point to point symmetric, and all use cases. > > REQMT-3a:The solution MUST enable individual audio > > streams to be associated with one or more video > > image captures, and individual video image > > captures to be associated with one or more > > audio captures, for the purpose of rendering > > proper position. > > [CNG] Supported (Partial?) =96 It is possible to deduce that audio and vi= deo > relate to the same capture area in a scene by analysing the Capture Area > parameters. It is possible to relate individual audio captures to video > captures if the Advertisement is constructed in a limited way. However it= s > not possible to deduce the relationships between individual captures by > utilising the Scene, CSE and capture concepts. CSE only relate to one med= ia > type. So it=92s not possible to link audio CSEs to video CSEs. > > REQMT-3b:The solution MUST enable individual audio > > streams to be rendered in any desired spatial > > position. > > [CNG] Supported? =96 I think its assumed that a Consumer can do whatever = it > likes with respect to rendering decisions. Ultimately that=92s local poli= cy. > > Edt: Rendering is an open issue. Text will > > be changed when it is resolved.] > > REQMT-4:The solution MUST enable interoperability between > > endpoints that have a different number of similar devices. > > For example, one endpoint may have 1 screen, 1 speaker, 1 > > camera, 1 mic, and another endpoint may have 3 screens, 2 > > speakers, 3 cameras and 2 mics.Or, in a multi-point > > conference, one endpoint may have one screen, another may > > have 2 screens and a third may have 3 screens.This > > includes endpoints where the number of devices of a given > > type is zero. > > Use case is asymmetric point to point and multipoint. > > [CNG] Supported =96 CLUE enables different capture capabilities to be > signalled. It makes no assumption as to the rendering. > > REQMT-5:The solution MUST support means of enabling > > interoperability between telepresence endpoints where > > cameras are of different picture aspect ratios. > > [CNG] Supported =96 CLUE doesn=92t describe =93aspect ratio=94 but allows > different capture areas to be defined. This is a means of describing aspe= ct > ratio. > > REQMT-6:The solution MUST provide scaling information which > > enables rendering of a video image at the actual size of > > the captured scene. > > [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture > and Scene Scale allow this. > > REQMT-7:The solution MUST support means of enabling > > interoperability between telepresence endpoints where > > displays are of different resolutions. > > [CNG] Supported? =96 CLUE allow encoding parameters to be associated with > captures which could state the resolution of the captured image. However > there is no way to indicate =93display=94 resolution. Perhaps the require= ment > needs to be reworded? > [MB] Do you have any suggestions for rewording? [/MB] > > REQMT-8:The solution MUST support methods for handling different > > bit rates in the same conference. > > [CNG] Supported =96 CLUE allow encoding parameters to be associated with > captures which could state the bit rate. > > REQMT-9:The solution MUST support means of enabling > > interoperability between endpoints that send and receive > > different numbers of media streams. > > Use case heterogeneous and multipoint. > > [CNG] Supported =96 CLUE allows different numbers of captures to be sent. > > REQMT-10:The solution MUST make it possible for endpoints without > > support for telepresence extensions to participate in a > > telepresence session with those that do. > > [CNG] Supported =96 The support of a CLUE channel will be negotiated betw= een > endpoints. From the current signalling draft it seems a basic set of medi= a > can be established without CLUE. Endpoints that don=92t support CLUE > obviously won=92t be able to determine spatial information etc=85 > > REQMT-11:The solution MUST support a mechanism for determining > > whether or not an endpoint or MCU is capable of > > telepresence extensions. > > [CNG] Supported? =96 The negotiation of a CLUE channel via SDP is one met= hod > in the signalling draft. Another indication at the SIP level may be > beneficial such as a feature tag. This is yet to be documented. > > REQMT-12:The solution MUST support a means to enable more than two > > sites to participate in a teleconference. > > Use case multipoint. > > [CNG] Partial =96 This is on the agenda and there=92s basic support i.e. = via > the composed attribute and =93scene-switch-policy=94 CSE attribute. Howev= er no > method is yet defined to keep the source information. > > REQMT-13:The solution MUST support both transcoding and switching > > approaches to providing multipoint conferences. > > [CNG] Supported =96 CLUE supports these two methods. However further work= is > needed on the details. > > REQMT-14:The solution MUST support mechanisms to make possible for > > either or both site switching or segment switching.[Edt: > > This needs rewording.Deferred until layout discussion is > > resolved.] > > [CNG] Partial =96 The =93scene-switch-policy=94 CSE attribute supports th= is to > some level but further work is needed in this area. > > REQMT-15:The solution MUST support mechanisms for presentations in > > such a way that: > > *Presentations can have different sources > > *Presentations can be seen by all > > *There can be variation in placement, number and size of > > Presentations > > [CNG] Partial =96 CLUE allows an endpoint whether the capture is related = to > a presentation or not through the use of the presentation attribute. The > spatial attributes (i.e. capture area) allows the place and size to be > indicated. The number can be inferred from the number of captures. CLUE > doesn=92t have any policy on who can see the presentations. The CLUE > Advertisement mechanism may include presentation captures to all people > within the conference. Perhaps the 2^nd bullet can be removed or clarifie= d > that its not related to policy? > [MB] I'm of a mindset to just remove that 2nd bullet. [/MB] > > REQMT-16:The solution MUST include extensibility mechanisms. > > [CNG] Supported? =96 whilst not explicitly documented I think there=92s > general agreement this is needed. > > REQMT-17:The solution must support a mechanism for allowing > > information about media captures to change during a > > conference. > > [CNG] Supported? =96 Keeping the CLUE signalling channel open would allow > for this and people seem in agreement this should be possible. Further > detailed work is needed in the signalling draft to describe this. i.e. > incremental vs full updates. Interaction with bearer signalling (i.e. SDP > O/A) etc. > > REQMT-18:The solution MUST provide a mechanism for the secure > > exchange of information about the media captures. > > [CNG] Partial? =96 It is assumed that CLUE will operate over a DTLS/SCTP > however there=92s no documentation regarding CLUE security. > [MB] There is an open action item (Ticket #33) for me to work with Mark with regards to an overview of the security solution required for CLUE. [/MB] > > Appendix A. open issues > > OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural > > audio is unresolved, and the "MUST NOT preclude" language in > > this requirement is problematic.The authors believe this > > requirement needs to be either changed or withdrawn, > > depending on how the issue is resolved. > > [CNG] Not supported - This is still unresolved. > [MB] See my suggestion here: http://www.ietf.org/mail-archive/web/clue/current/msg02753.html [/MB] OPEN-2Reference to Rendering [REQMT-3b] This is the only > > requirement which refers to rendering.It may also be empty, > > since receivers can rendering audio captures as they wish. > > This is deferred until broader discussion on rendering > > requirements is concluded. > > [CNG] I think we should frame the requirements with regards to captures a= s > that=92s the way the framework is written. Perhaps some text to say that > rendering is based on the receivers local policy. > [MB] See my suggestion here: http://www.ietf.org/mail-archive/web/clue/current/msg02751.html [/MB] > OPEN-3Conference modes [REQMT-14] This wording of this requirement > > is problematic in part because the conference modes (site > > switching and segment switching) are not defined.It at > > least needs rewording.This is deferred until broader > > discussion on layout is concluded. > > [CNG] Yes this is still open. > [MB] I know the issue is open in the solution. But, I think the requirements stands, but just needs rewording. See my suggestion here: http://www.ietf.org/mail-archive/web/clue/current/msg02750.html [/MB] OPEN-4Need to capture requirement that attributes can change at any > > time during the call. > > [CNG] Yes although it seems REQMT-17 covers this. > [MB] That is my thought as well: http://www.ietf.org/mail-archive/web/clue/current/msg02749.html [/MB] > > OPEN-5Need to add requirement for three dimensions in the right > > place > > [CNG] Requirements 1d and 2e do capture an aspect of 3D. > [MB] Here's my thoughts on this one: http://www.ietf.org/mail-archive/web/clue/current/msg02755.html I think it's good that we have some requirements that capture some aspects and the FW/solution will support those requirements, I'm just not sure it's a priority to support 3D in the current set of deliverables. [/MB] OPEN-6Multi-view, is there a requirement needed? > > [CNG] Even if there=92s no requirement we appear to support it because we > allow both the capture area and capture point to be sent for captures. An > Advertiser could describe multiple capture points capturing the same area > of capture. > [MB] I didn't know what multi-view meant: http://www.ietf.org/mail-archive/web/clue/current/msg02754.html However, isn't that functionality supporting other requirements? So, my question is do we really need an explicit requirement and if so we need to be clear what we mean by multi-view (in more general terms. [/MB] > > > Regards, Christian > > > On 17/07/2013 6:07 AM, Mary Barnes wrote: > >> There really were no changes other than to refresh this draft. I was >> going to extend the security section with more detail, but I really can'= t >> add much more detail without referencing things that are defined in the >> framework. So, I think the next step is for me to work with Mark on the >> security for the framework. >> >> There are some open issues identified in the appendix of this document >> that we need to figure out whether they are issues that need resolution = for >> this document. I will open issues in the tracker and we can discuss each >> one and perhaps make some decisions before Berlin. >> >> We also need to consider whether the current framework meets these >> requirements. If some requirements are not met, we need to decide whethe= r >> it's because they'll be met by the solution documents or won't be met at >> all. In which case, we need to decide whether we actually need them for = the >> solution. >> >> Regards, >> Mary. >> >> >> On Tue, Jul 16, 2013 at 11:29 AM, > internet-drafts@ietf.**org >> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : Requirements for Telepresence Multi-Streams >> Author(s) : Allyn Romanow >> Stephen Botzko >> Mary Barnes >> Filename : draft-ietf-clue-telepresence-**requirements-04.txt >> Pages : 14 >> Date : 2013-07-15 >> >> Abstract: >> This memo discusses the requirements for a specification that enable= s >> telepresence interoperability, by describing the relationship betwee= n >> multiple RTP streams. In addition, the problem statement and >> definitions are also covered herein. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/**doc/draft-ietf-clue-** >> telepresence-requirements >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/**draft-ietf-clue-telepresence-** >> requirements-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=3Ddraft-ietf-clue-** >> telepresence-requirements-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-**drafts/ >> >> ______________________________**_________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/**listinfo/i-d-announce >> Internet-Draft >> > 0AInternet-Draft >> > >> >> directories: http://www.ietf.org/shadow.**html >> or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt >> >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --089e0149528e046ac704e231b1f3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks very much for your detailed review and comments wit= h regards to whether the REQ is currently supported in the solution. =A0I h= ave a few comments below. =A0

Thanks,
Mary
As editor for the Requirements do


On Wed, Jul 1= 7, 2013 at 10:01 PM, Christian Groves <Christian.Groves@nteczo= ne.com> wrote:
Hello Mary,

I did a review of the requirements and Appendix to see if they are met. My = comments are below. Sorry for the length of the email but I figured it woul= d be easier for people to read my comment [CNG] along with the requirement.=

REQMT-1:The solution MUST support a description of the spatial

arrangement of source video images sent in video streams

which enables a satisfactory reproduction at the receiver

of the original scene.This applies to each site in a

point to point or a multipoint meeting and refers to the

spatial ordering within a site, not to the ordering of

images between sites.

[CNG] Supported =96 via Capture Area attribute.

Use case point to point symmetric, and all other use cases.

REQMT-1a:The solution MUST support a means of allowing

the preservation of the order of images in the

captured scene.For example, if John is to

Susan's right in the image capture, John is

also to Susan's right in the rendered image.

[CNG] Supported =96 via Capture Area attribute.

REQMT-1b:The solution MUST support a means of allowing

the preservation of order of images in the

scene in two dimensions - horizontal and

vertical.

[CNG] Supported =96 via Capture Area attribute.

REQMT-1c:The solution MUST support a means to identify

the point of capture of individual video

captures in three dimensions.

[CNG] Supported =96 via Point of capture attribute.

REQMT-1d:The solution MUST support a means to identify

the extent of individual video captures in

three dimensions.

[CNG] Partial =96 Capture area attribute allows the specification of a plan= e of capture in 3 dimensions. However depth of the capture (needed for a 3D= area) is not supported.
[MB] Per my comments on open = issue 5 from the requirements document (and Ticket # 41 =A0in the tracker),= I was proposing we not require 3D in the solution at this time. =A0[/MB]= =A0

REQMT-2:The solution MUST support a description of the spatial

arrangement of captured source audio sent in audio streams

which enables a satisfactory reproduction at the receiver

in a spatially correct manner.This applies to each site

in a point to point or a multipoint meeting and refers to

the spatial ordering within a site, not the ordering of

channels between sites.

[CNG] Supported =96 Via Capture Area attribute.

Use case point to point symmetric, and all use cases,

especially heterogeneous.

REQMT-2a:The solution MUST support a means of preserving

the spatial order of audio in the captured

scene.For example, if John sounds as if he is

at Susan's right in the captured audio, John

voice is also placed at Susan's right in the

rendered image.

[CNG] Supported =96 Via Capture Area attribute.

REQMT-2b:The solution MUST support a means to identify

the number and spatial arrangement of audio

channels including monaural, stereophonic

(2.0), and 3.0 (left, center, right) audio

channels.

[CNG] Partial =96 the Audio Channel Format attribute currently only support= s =93mono=94 and =93stereo=94. It doesn=92t support the 3.0 format

[MB] So, my question to the group is do we need to = support this in the current work is is this something that could be extende= d later. I looked fairly quickly but I also could not find a use case for 3= .0[/MB]=A0
=A0

REQMT-2c:The solution MUST NOT preclude the use of

binaural audio.[Edt. This is an outstanding

issue.Text will be changed when the issue is

resolved.]

[CNG] Partial? =96 Binaural isn=92t mentioned in the framework so isn=92t p= recluded as such. There is no indication in CLUE recording a binaural captu= re.

[MB] Yeah, per my comments on Issue= 1 (ticket #37) , I propose that we just delete this requirement. [/MB]=A0<= /div>

REQMT-2d:The solution MUST support a means to identify

the point of capture of individual audio

captures in three dimensions.

[CNG] Supported =96 via Point of capture attribute.

REQMT-2e:The solution MUST support a means to identify

the extent of individual audio captures in

three dimensions.

[CNG] Partial =96 The Capture area attribute is based on capturing a plane = in Cartesian space. There is no depth parameter. Whether the plane concept = holds for audio like it does video needs further thought.

REQMT-3:The solution MUST support a mechanism to enable a

satisfactory spatial matching between audio and video

streams coming from the same endpoints.

[CNG] Supported - The given that an Advertiser places captures in a particu= lar scene it is possible to indicate audio and video streams are from the s= ame endpoint.

Use case is point to point symmetric, and all use cases.

REQMT-3a:The solution MUST enable individual audio

streams to be associated with one or more video

image captures, and individual video image

captures to be associated with one or more

audio captures, for the purpose of rendering

proper position.

[CNG] Supported (Partial?) =96 It is possible to deduce that audio and vide= o relate to the same capture area in a scene by analysing the Capture Area = parameters. It is possible to relate individual audio captures to video cap= tures if the Advertisement is constructed in a limited way. However its not= possible to deduce the relationships between individual captures by utilis= ing the Scene, CSE and capture concepts. CSE only relate to one media type.= So it=92s not possible to link audio CSEs to video CSEs.

REQMT-3b:The solution MUST enable individual audio

streams to be rendered in any desired spatial

position.

[CNG] Supported? =96 I think its assumed that a Consumer can do whatever it= likes with respect to rendering decisions. Ultimately that=92s local polic= y.

Edt: Rendering is an open issue. Text will

be changed when it is resolved.]

REQMT-4:The solution MUST enable interoperability between

endpoints that have a different number of similar devices.

For example, one endpoint may have 1 screen, 1 speaker, 1

camera, 1 mic, and another endpoint may have 3 screens, 2

speakers, 3 cameras and 2 mics.Or, in a multi-point

conference, one endpoint may have one screen, another may

have 2 screens and a third may have 3 screens.This

includes endpoints where the number of devices of a given

type is zero.

Use case is asymmetric point to point and multipoint.

[CNG] Supported =96 CLUE enables different capture capabilities to be signa= lled. It makes no assumption as to the rendering.

REQMT-5:The solution MUST support means of enabling

interoperability between telepresence endpoints where

cameras are of different picture aspect ratios.

[CNG] Supported =96 CLUE doesn=92t describe =93aspect ratio=94 but allows d= ifferent capture areas to be defined. This is a means of describing aspect = ratio.

REQMT-6:The solution MUST provide scaling information which

enables rendering of a video image at the actual size of

the captured scene.

[CNG] Supported - Capture Area, Capture Point, Point of Line of Capture and= Scene Scale allow this.

REQMT-7:The solution MUST support means of enabling

interoperability between telepresence endpoints where

displays are of different resolutions.

[CNG] Supported? =96 CLUE allow encoding parameters to be associated with c= aptures which could state the resolution of the captured image. However the= re is no way to indicate =93display=94 resolution. Perhaps the requirement = needs to be reworded?

[MB] Do you have any suggestions for rewor= ding? =A0[/MB]

REQMT-8:The solution MUST support methods for handling different

bit rates in the same conference.

[CNG] Supported =96 CLUE allow encoding parameters to be associated with ca= ptures which could state the bit rate.

REQMT-9:The solution MUST support means of enabling

interoperability between endpoints that send and receive

different numbers of media streams.

Use case heterogeneous and multipoint.

[CNG] Supported =96 CLUE allows different numbers of captures to be sent.
REQMT-10:The solution MUST make it possible for endpoints without

support for telepresence extensions to participate in a

telepresence session with those that do.

[CNG] Supported =96 The support of a CLUE channel will be negotiated betwee= n endpoints. From the current signalling draft it seems a basic set of medi= a can be established without CLUE. Endpoints that don=92t support CLUE obvi= ously won=92t be able to determine spatial information etc=85

REQMT-11:The solution MUST support a mechanism for determining

whether or not an endpoint or MCU is capable of

telepresence extensions.

[CNG] Supported? =96 The negotiation of a CLUE channel via SDP is one metho= d in the signalling draft. Another indication at the SIP level may be benef= icial such as a feature tag. This is yet to be documented.

REQMT-12:The solution MUST support a means to enable more than two

sites to participate in a teleconference.

Use case multipoint.

[CNG] Partial =96 This is on the agenda and there=92s basic support i.e. vi= a the composed attribute and =93scene-switch-policy=94 CSE attribute. Howev= er no method is yet defined to keep the source information.

REQMT-13:The solution MUST support both transcoding and switching

approaches to providing multipoint conferences.

[CNG] Supported =96 CLUE supports these two methods. However further work i= s needed on the details.

REQMT-14:The solution MUST support mechanisms to make possible for

either or both site switching or segment switching.[Edt:

This needs rewording.Deferred until layout discussion is

resolved.]

[CNG] Partial =96 The =93scene-switch-policy=94 CSE attribute supports this= to some level but further work is needed in this area.

REQMT-15:The solution MUST support mechanisms for presentations in

such a way that:

*Presentations can have different sources

*Presentations can be seen by all

*There can be variation in placement, number and size of

Presentations

[CNG] Partial =96 CLUE allows an endpoint whether the capture is related to= a presentation or not through the use of the presentation attribute. The s= patial attributes (i.e. capture area) allows the place and size to be indic= ated. The number can be inferred from the number of captures. CLUE doesn=92= t have any policy on who can see the presentations. The CLUE Advertisement = mechanism may include presentation captures to all people within the confer= ence. Perhaps the 2^nd bullet can be removed or clarified that its not rela= ted to policy?
[MB] I'm of a mindset to just remove that 2nd bullet.= [/MB]=A0

REQMT-16:The solution MUST include extensibility mechanisms.

[CNG] Supported? =96 whilst not explicitly documented I think there=92s gen= eral agreement this is needed.

REQMT-17:The solution must support a mechanism for allowing

information about media captures to change during a

conference.

[CNG] Supported? =96 Keeping the CLUE signalling channel open would allow f= or this and people seem in agreement this should be possible. Further detai= led work is needed in the signalling draft to describe this. i.e. increment= al vs full updates. Interaction with bearer signalling (i.e. SDP O/A) etc.<= br>
REQMT-18:The solution MUST provide a mechanism for the secure

exchange of information about the media captures.

[CNG] Partial? =96 It is assumed that CLUE will operate over a DTLS/SCTP ho= wever there=92s no documentation regarding CLUE security.
<= div>[MB] There is an open action item (Ticket #33) for me to work with Mark= with regards to an overview of the security solution required for CLUE. [/= MB]

Appendix A. open issues

OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural

audio is unresolved, and the "MUST NOT preclude" language in

this requirement is problematic.The authors believe this

requirement needs to be either changed or withdrawn,

depending on how the issue is resolved.

[CNG] Not supported - This is still unresolved.
[/MB]

OPEN-2Reference to Rendering [REQMT-3b] This is the only

requirement which refers to rendering.It may also be empty,

since receivers can rendering audio captures as they wish.

This is deferred until broader discussion on rendering

requirements is concluded.

[CNG] I think we should frame the requirements with regards to captures as = that=92s the way the framework is written. Perhaps some text to say that re= ndering is based on the receivers local policy.

[/MB]
OPEN-3Conference modes [REQMT-14] This wording of this requirement

is problematic in part because the conference modes (site

switching and segment switching) are not defined.It at

least needs rewording.This is deferred until broader

discussion on layout is concluded.

[CNG] Yes this is still open.
[MB] =A0I know the issue= is open in the solution. But, I think the requirements stands, but just ne= eds rewording. =A0See my suggestion here: =A0=A0http://www.ietf.org/mail-a= rchive/web/clue/current/msg02750.html
[/MB]


OPEN-4Need to capture requirement that attributes can change at any

time during the call.

[CNG] Yes although it seems REQMT-17 covers this.
[/MB]

OPEN-5Need to add requirement for three dimensions in the right

place

[CNG] Requirements 1d and 2e do capture an aspect of 3D.
[MB] Here's my thoughts on this one:=A0=A0
=A0I think it's good that we have some requirements that capture s= ome aspects and the FW/solution will support those requirements, I'm ju= st not sure it's a priority to support 3D in the current set of deliver= ables. [/MB]

OPEN-6Multi-view, is there a requirement needed?

[CNG] Even if there=92s no requirement we appear to support it because we a= llow both the capture area and capture point to be sent for captures. An Ad= vertiser could describe multiple capture points capturing the same area of = capture.
[MB] =A0I didn't know what multi-view meant:
http://www.ietf.org/mail-archive/web/clue/current/msg02754.html
<= /div>
=A0However, isn't that functionality supporting other requirements= ? =A0So, my question is do we really need an explicit requirement and if so= we need to be clear what we mean by multi-view (in more general terms. [/M= B]


Regards, Christian


On 17/07/2013 6:07 AM, Mary Barnes wrote:
There really were no changes other than to refresh this draft. I was going = to extend the security section with more detail, but I really can't add= much more detail without referencing things that are defined in the framew= ork. So, I think the next step is for me to work with Mark on the security = for the framework.

There are some open issues identified in the appendix of this document that= we need to figure out whether they are issues that need resolution for thi= s document. I will open issues in the tracker and we can discuss each one a= nd perhaps make some decisions before Berlin.

We also need to consider whether the current framework meets these requirem= ents. If some requirements are not met, we need to decide whether it's = because they'll be met by the solution documents or won't be met at= all. In which case, we need to decide whether we actually need them for th= e solution.

Regards,
Mary.


On Tue, Jul 16, 2013 at 11:29 AM, <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> wrote:


=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts<= br> =A0 =A0 directories.
=A0 =A0 This draft is a work item of the ControLling mUltiple streams for =A0 =A0 tElepresence Working Group of the IETF.

=A0 =A0 Title : Requirements for Telepresence Multi-Streams
=A0 =A0 Author(s) : Allyn Romanow
=A0 =A0 Stephen Botzko
=A0 =A0 Mary Barnes
=A0 =A0 Filename : draft-ietf-clue-telepresence-requirements-04.txt<= br> =A0 =A0 Pages : 14
=A0 =A0 Date : 2013-07-15

=A0 =A0 Abstract:
=A0 =A0 This memo discusses the requirements for a specification that enabl= es
=A0 =A0 telepresence interoperability, by describing the relationship betwe= en
=A0 =A0 multiple RTP streams. In addition, the problem statement and
=A0 =A0 definitions are also covered herein.


=A0 =A0 The IETF datatracker status page for this draft is:
=A0 =A0 https://datatracker.ietf.org/d= oc/draft-ietf-clue-telepresence-requirements

=A0 =A0 There's also a htmlized version available at:
=A0 =A0 http://tools.ietf.org/html/draft-= ietf-clue-telepresence-requirements-04

=A0 =A0 A diff from the previous version is available at:
=A0 =A0 http://www.ietf.org/rfcdiff?<= /u>url2=3Ddraft-ietf-clue-telepresence-requirements-04


=A0 =A0 Internet-Drafts are also available by anonymous FTP at:
=A0 =A0 f= tp://ftp.ietf.org/internet-drafts/

=A0 =A0 _______________________________________________
=A0 =A0 I-D-Announce mailing list
=A0 =A0 I-D-Anno= unce@ietf.org <mailto:I-D-Announce@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/i-d-announce=
=A0 =A0 Internet-Draft
=A0 =A0 <https://www.ietf.org/mailman/list= info/i-d-announce%0AInternet-Draft> _______________________________________________
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

--089e0149528e046ac704e231b1f3-- From mary.ietf.barnes@gmail.com Tue Jul 23 11:12:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1852F11E8346 for ; Tue, 23 Jul 2013 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.094 X-Spam-Level: X-Spam-Status: No, score=-101.094 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGY15vggjKcV for ; Tue, 23 Jul 2013 11:12:09 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id E54FD11E8344 for ; Tue, 23 Jul 2013 11:12:08 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id hu14so1435574qab.19 for ; Tue, 23 Jul 2013 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GJo4t8bVJwY+4NoEBht1IBTZ0Fq/JYYDQBmqbrxn/iA=; b=IAdLmIVYSXm0YArNKm2RJAyNu4+zs3Cy9YpNMIvjI3JbINuZZIMG6kA2DhSs6f5tGI o7c0qqfKERNdtaVpvgwrmVFvpgFVM/gxYVd0vEC8aABp+tGFNsLdE/fsf4vDNIftgy4E g6QhfOfPrpl1VyBVuTpoOgD2Bx1R43Wg5r7GXhlThkWbIGXINE7C33X/TL7wnvAB232O fUKHPk1sHYCitTfrX7hLbKeKuBpYWy/JRf9WQr+vTe7WMWugdTknUtkwTb/F8QGhhi3L IzpoUEqLivdDK8ZfYalpZXJ7xsljBBZEf8d+3NTqprPmLT01OjqmTtTqQkME3ruiHX1s FOUg== MIME-Version: 1.0 X-Received: by 10.49.128.42 with SMTP id nl10mr19936253qeb.6.1374603128238; Tue, 23 Jul 2013 11:12:08 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 11:12:08 -0700 (PDT) In-Reply-To: <51E89391.30507@nteczone.com> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> Date: Tue, 23 Jul 2013 13:12:08 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b6779e82a78f104e231bb86 Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 18:12:10 -0000 --047d7b6779e82a78f104e231bb86 Content-Type: text/plain; charset=ISO-8859-1 I have just one comment below. [MB]. Thanks, Mary - as editor of Requirements document On Thu, Jul 18, 2013 at 8:17 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello John, > > Please see my comments below. > > Regards, Christian > > On 18/07/2013 9:16 PM, John Leslie wrote: > >> Christian Groves wrote: >> >>> I did a review of the requirements and Appendix to see if they are met. >>> ... >>> >>> REQMT-2:The solution MUST support a description of the spatial >>> arrangement of captured source audio sent in audio streams >>> which enables a satisfactory reproduction at the receiver >>> in a spatially correct manner.This applies to each site >>> in a point to point or a multipoint meeting and refers to >>> the spatial ordering within a site, not the ordering of >>> channels between sites. >>> >>> [CNG] Supported ? Via Capture Area attribute... >>> >> Um... audio isn't two-dimensinal... >> > [CNG] That's why the "?" is next to "Supported" :-). I agree there's the > 2D issues which I pick up on below. > > >> REQMT-2a:The solution MUST support a means of preserving >>> the spatial order of audio in the captured >>> scene.For example, if John sounds as if he is >>> at Susan's right in the captured audio, John >>> voice is also placed at Susan's right in the >>> rendered image. >>> >> This REQMT could use some work... >> >> REQMT-2e:The solution MUST support a means to identify >>> the extent of individual audio captures in >>> three dimensions. >>> >> (I don't know what that means.) >> >> [CNG] Partial ? The Capture area attribute is based on capturing a plane >>> in Cartesian space. There is no depth parameter. Whether the plane >>> concept holds for audio like it does video needs further thought. >>> >> It doesn't. >> >> A microphone can be modeled by a capture point and direction, plus >> a sensitivity pattern; but no actual sensitivity pattern resembles a >> camera's pattern. Furthermore, no X/Y information survives, but distance >> from audio source to the microphone becomes significant (about one >> millisecond per foot). >> > [CNG] Could you perhaps propose some attributes (and descriptive text) > based on direction and sensitivity pattern that you mentioned above? It > would be good to have something more to discuss. > > > > >> REQMT-3b:The solution MUST enable individual audio >>> streams to be rendered in any desired spatial >>> position. >>> >>> [CNG] Supported? ? I think its assumed that a Consumer can do whatever >>> it likes with respect to rendering decisions. Ultimately that?s local >>> policy. >>> >> I agree it's local policy. >> >> OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural >>> audio is unresolved, and the "MUST NOT preclude" language in >>> this requirement is problematic.The authors believe this >>> requirement needs to be either changed or withdrawn, >>> depending on how the issue is resolved. >>> >>> [CNG] Not supported - This is still unresolved. >>> >> Binaural audio works fairly well when the listener's head is >> stationary. Alas, it won't be. >> > [CNG] I think the use case that was thought about was participating in a > telepresence conference via a smart phone whilst wearing headphones. I > think it was Christer that had that concern. [MB] My suggestion was that since we don't have a use case, I think we should just remove this requirement. [/MB] > > > >> -- >> John Leslie >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7b6779e82a78f104e231bb86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have just one comment below. [MB].

Th= anks,
Mary
- as editor of Requirements document


On Thu, Jul 18,= 2013 at 8:17 PM, Christian Groves <Christian.Groves@nteczone.= com> wrote:
Hello John,

Please see my comments below.

Regards, Christian

On 18/07/2013 9:16 PM, John Leslie wrote:
Christian Groves <Christian.Groves@nteczone.com> wrote:
I did a review of the requirements and Appendix to see if they are met.
...

REQMT-2:The solution MUST support a description of the spatial
arrangement of captured source audio sent in audio streams
which enables a satisfactory reproduction at the receiver
in a spatially correct manner.This applies to each site
in a point to point or a multipoint meeting and refers to
the spatial ordering within a site, not the ordering of
channels between sites.

[CNG] Supported ? Via Capture Area attribute...
=A0 =A0 Um... audio isn't two-dimensinal...
[CNG] That's why the "?" is next to "Supported" :-)= . I agree there's the 2D issues which I pick up on below.


REQMT-2a:The solution MUST support a means of preserving
the spatial order of audio in the captured
scene.For example, if John sounds as if he is
at Susan's right in the captured audio, John
voice is also placed at Susan's right in the
rendered image.
=A0 =A0 This REQMT could use some work...

REQMT-2e:The solution MUST support a means to identify
the extent of individual audio captures in
three dimensions.
=A0 =A0 (I don't know what that means.)

[CNG] Partial ? The Capture area attribute is based on capturing a plane in Cartesian space. There is no depth parameter. Whether the plane
concept holds for audio like it does video needs further thought.
=A0 =A0 It doesn't.

=A0 =A0 A microphone can be modeled by a capture point and direction, plus<= br> a sensitivity pattern; but no actual sensitivity pattern resembles a
camera's pattern. Furthermore, no X/Y information survives, but distanc= e
from audio source to the microphone becomes significant (about one
millisecond per foot).
[CNG] Could you perhaps propose some attributes (and descriptive text) base= d on direction and sensitivity pattern that you mentioned above? It would b= e good to have something more to discuss.




REQMT-3b:The solution MUST enable individual audio
streams to be rendered in any desired spatial
position.

[CNG] Supported? ? I think its assumed that a Consumer can do whatever
it likes with respect to rendering decisions. Ultimately that?s local
policy.
=A0 =A0 I agree it's local policy.

OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural
audio is unresolved, and the "MUST NOT preclude" language in
this requirement is problematic.The authors believe this
requirement needs to be either changed or withdrawn,
depending on how the issue is resolved.

[CNG] Not supported - This is still unresolved.
=A0 =A0 Binaural audio works fairly well when the listener's head is stationary. Alas, it won't be.
[CNG] I think the use case that was thought about was participating in a te= lepresence conference via a smart phone whilst wearing headphones. I think = it was Christer that had that concern.
[MB] My suggestion = was that since we don't have a use case, I think we should just remove = this requirement. =A0[/MB] =A0



--
John Leslie <john@jlc.= net>


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

--047d7b6779e82a78f104e231bb86-- From john@jlc.net Tue Jul 23 11:41:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8096811E8343 for ; Tue, 23 Jul 2013 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXTt1KkUxSdZ for ; Tue, 23 Jul 2013 11:40:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5270311E82E2 for ; Tue, 23 Jul 2013 11:40:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CF72D33C23; Tue, 23 Jul 2013 14:40:52 -0400 (EDT) Date: Tue, 23 Jul 2013 14:40:52 -0400 From: John Leslie To: Christian Groves , CLUE Message-ID: <20130723184052.GA8295@verdi> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 18:41:01 -0000 On Thu, Jul 18, 2013 at 8:17 PM, wrote: > On 18/07/2013 9:16 PM, John Leslie wrote: >> Christian Groves wrote: >> >> REQMT-2a:The solution MUST support a means of preserving >>> the spatial order of audio in the captured >>> scene.For example, if John sounds as if he is >>> at Susan's right in the captured audio, John >>> voice is also placed at Susan's right in the >>> rendered image. >>> >> This REQMT could use some work... Perhaps I should elaborate: "spatial order of audio" in largely devoid of meaning. "John voice is "also placed at Susan's right in the rendered image" is even more devoid of meaning. Perecived position of a voice in rendered audio is not a single- dimensioned thing. Furthermore, perceived coupling between two images rendered on different screens is looser than you may think. No doubt what was intended was that John's voice should seem to eminate from the position of John's image as rendered on the screen(s). I do not recommend that as a "requirement" either... >>> [CNG] Partial ? The Capture area attribute is based on capturing a plane >>> in Cartesian space. There is no depth parameter. Whether the plane >>> concept holds for audio like it does video needs further thought. >>> >> It doesn't. >> >> A microphone can be modeled by a capture point and direction, plus >> a sensitivity pattern; but no actual sensitivity pattern resembles a >> camera's pattern. Furthermore, no X/Y information survives, but distance >> from audio source to the microphone becomes significant (about one >> millisecond per foot). >> > [CNG] Could you perhaps propose some attributes (and descriptive text) > based on direction and sensitivity pattern that you mentioned above? It > would be good to have something more to discuss. I have negative desire to propose any requirement(s) here. Nonetheless, perhaps I should elaborate a bit. A microphone has a point of capture in three dimensions. This is worth preserving. The audio it captures has no useful (X,Y) dimensions. There is a sensitivity pattern; but in most cases it can be ignored. What can't be ignored is the fall-off in sensitivity with distance and the increase in latency for a signal to reach it through the air. Bottom-line: the point of capture is the only always-significant feature. The latency becomes significant if you try to pinpoint the source of the audio captured; but we probably won't do that. (We might, however, try to blend two microphones, in which case the difference in latency would _sometimes_ be worth considering.) The reduced audio level from sources farther away will usually deserve to be ignored. The desire to keep audio loud enough but not unpleasant is quite independent of the actual audio level. >> REQMT-3b:The solution MUST enable individual audio >>> streams to be rendered in any desired spatial >>> position. >>> >>> [CNG] Supported? ? I think its assumed that a Consumer can do whatever >>> it likes with respect to rendering decisions. Ultimately that?s local >>> policy. >>> >> I agree it's local policy. Furthermore, this requires essentially zero support in the protocol. -- John Leslie From ron.even.tlv@gmail.com Tue Jul 23 12:33:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CD711E837D for ; Tue, 23 Jul 2013 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks8+1maaMc1G for ; Tue, 23 Jul 2013 12:33:54 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1781B11E80A2 for ; Tue, 23 Jul 2013 12:33:53 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id d10so4727068eaj.41 for ; Tue, 23 Jul 2013 12:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=b1sJuAVp8qeeqCCd/k9r0e9je1HHleBUpMWVrOAmDJA=; b=HsgIUfF7T2mjvlNl/P88hiUz9jiS3s9Ug7urMGI3UJl/LhCfM2EzIk/EVkEaNTgbIN xsXnoFYiGI9gsmD2Mwe9xWD3RedGH0U08IACAHyyrgxHADknOfo9m+WxTUsEgyedgI2a hUZyt1B5MuN2OX+Wv2VvEGxfqAsCdZYvHQ3pOZ6jjOksZIxZ8zsBo3Bqq/Bbpko0QKGo Ina6D5hyR/C8iFd2bJFEpXBVeaRd4RXDim8TGGYL8A3uBxsEAvdW1y27PEaITT8HIb5L 7aIwggQfZH0bcMFMU8Vi16hzAkUkt7f/8VT8VYoLfxOZ9JOKTWQnnXcYQV6smSt+U6Yg S6PA== X-Received: by 10.14.201.68 with SMTP id a44mr8332087eeo.46.1374608030912; Tue, 23 Jul 2013 12:33:50 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id r54sm60764272eev.8.2013.07.23.12.33.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Jul 2013 12:33:50 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'clue issue tracker'" References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> In-Reply-To: Date: Tue, 23 Jul 2013 22:31:54 +0300 Message-ID: <092001ce87db$4bb87350$e32959f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0921_01CE87F4.71066EA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKqGugFlSeuNLyhVCUP2QL9IaTKwwH8Opxyl6udzTA= Content-Language: en-us Cc: draft-ietf-clue-telepresence-requirements@tools.ietf.org, 'CLUE' Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 19:33:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0921_01CE87F4.71066EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, It is in the use cases - section 3.7, still looking back at the mailing list discussion the feeling is this use case is to test extensibility of the CLUE solution and there would be no specific requirements Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 23 July, 2013 8:36 PM To: clue issue tracker Cc: CLUE; draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view I propose to just close this issue with the answer being "No". I don't know even what's meant by that term - it's not used in the FW or usecases. If you have any concerns, or you have more info about what this is intended for, please respond no later than August 12, 2013. Mary. On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker wrote: #42: OPEN-6. Multi-view Is there a requirement needed? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue ------=_NextPart_000_0921_01CE87F4.71066EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

It is in the use cases – section 3.7, still looking back at the = mailing list discussion the feeling is this use case is to test = extensibility of the CLUE solution and there would be no specific = requirements

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 23 July, 2013 8:36 PM
To: clue = issue tracker
Cc: CLUE; = draft-ietf-clue-telepresence-requirements@tools.ietf.org
Subject: Re: [clue] #42: OPEN-6. = Multi-view

 

I = propose to just close this issue with the answer being "No". =  I don't know even what's meant by that term - it's not used in the = FW or usecases.

 

If you have any concerns, or you have more info about = what this is intended for, please respond no later than August 12, = 2013.

 

Mary.

 

On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker = <trac+clue@trac.tools.ietf.org> = wrote:

#42: OPEN-6. =  Multi-view

 Is there a requirement = needed?

--
-------------------------------------+--------------= -----------------------
 Reporter:         =                   |   =    Owner:  draft-ietf-clue-
  mary.ietf.barnes@gmail.com=         |  telepresence-
    =  Type:  enhancement             =  |  requirements@tools.ietf.org
 Priority:  minor           =          |     Status: =  new
Component:  telepresence-         =    |  Milestone:  milestone1
  requirements =                     =   |    Version:
 Severity:  Active WG = Document       |   = Keywords:
-------------------------------------+----------------------= ---------------

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/42&g= t;
clue <http://tools.ietf.org/wg/clue/>

 

------=_NextPart_000_0921_01CE87F4.71066EA0-- From stephen.botzko@gmail.com Tue Jul 23 13:03:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3EC11E8116 for ; Tue, 23 Jul 2013 13:03:26 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TraSP-lfPR+r for ; Tue, 23 Jul 2013 13:03:25 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7311E80DE for ; Tue, 23 Jul 2013 13:03:22 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so6427476vea.38 for ; Tue, 23 Jul 2013 13:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bOlAa3YwmCq3KxQjUCBERJxX/P8O1tZasXrbi1+3xus=; b=kkKOQp7sfGSSQxd6nZi5JLbgOIs/ez0775UZhTgDS0hPxnzbIHJs9WR9iPgJVwnbDx AHGRyROpBRi1Bli9c9nmBZ0YFE3+hM0IgQtPJx0VoMnlwYXlfRCDT1qcrK2d6GRY6D20 Fqrt0OJFJB3kmtvk5CUJW5/+ZQ6B4FYv/B86UAjhC0zkfDDW/4r7HkOhJl0Pu8+/OnBE sO59qajUvkFlFvZ1NaydYkrVSOU5NwZADCV9tuepfmIqu0cPLnCu/AWEtgUUdy/WuTY/ yVGGEtNV0TiNCKtz/FnqrnCrY0garEFPOiroqTx2wCj35O0bjKrsuInhdnwv2Vag6Nrt BRcg== MIME-Version: 1.0 X-Received: by 10.220.17.206 with SMTP id t14mr12323626vca.15.1374609801685; Tue, 23 Jul 2013 13:03:21 -0700 (PDT) Received: by 10.220.162.72 with HTTP; Tue, 23 Jul 2013 13:03:21 -0700 (PDT) In-Reply-To: <092001ce87db$4bb87350$e32959f0$@gmail.com> References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> <092001ce87db$4bb87350$e32959f0$@gmail.com> Date: Tue, 23 Jul 2013 16:03:21 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=001a11c3b30aef2e8f04e23348e3 Cc: CLUE , clue issue tracker , draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 20:03:26 -0000 --001a11c3b30aef2e8f04e23348e3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Section 3.7 describes the case where different cameras are aimed at the same participant, to get different perspectives. Other systems receive and present the capture that gives the correct eye-contact for the display they chose to render it on. The attributes in the framework already allow such captures to be signaled and selected. What is perhaps missing is a way for all the endpoints to know their assigned location in the virtual room. I agree with Roni (and the previous mailing list discussion) that this use case could be used to test extensibility - so no requirements would be needed. Steve On Tue, Jul 23, 2013 at 3:31 PM, Roni Even wrote: > Mary,**** > > It is in the use cases =96 section 3.7, still looking back at the mailing > list discussion the feeling is this use case is to test extensibility of > the CLUE solution and there would be no specific requirements**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 23 July, 2013 8:36 PM > *To:* clue issue tracker > *Cc:* CLUE; draft-ietf-clue-telepresence-requirements@tools.ietf.org > *Subject:* Re: [clue] #42: OPEN-6. Multi-view**** > > ** ** > > I propose to just close this issue with the answer being "No". I don't > know even what's meant by that term - it's not used in the FW or usecases= . > **** > > ** ** > > If you have any concerns, or you have more info about what this is > intended for, please respond no later than August 12, 2013.**** > > ** ** > > Mary.**** > > ** ** > > On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker < > trac+clue@trac.tools.ietf.org> wrote:**** > > #42: OPEN-6. Multi-view > > Is there a requirement needed? > > -- > -------------------------------------+-----------------------------------= -- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | telepresence- > Type: enhancement | requirements@tools.ietf.org > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+-----------------------------------= -- > > Ticket URL: > clue **** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --001a11c3b30aef2e8f04e23348e3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Section 3.7 describes the case where different cameras are aimed at the sam= e participant, to get different perspectives.=A0 Other systems receive and = present the capture that gives the correct eye-contact for the display they= chose to render it on.

The attributes in the framework already allow such captures to be signa= led and selected.=A0 What is perhaps missing is a way for all the endpoints= to know their assigned location in the virtual room.

I agree with = Roni (and the previous mailing list discussion) that this use case could be= used to test extensibility - so no requirements would be needed.

Steve

On Tue, Jul 23, 2013 at 3:31 PM= , Roni Even <ron.even.tlv@gmail.com> wrote:

Mary,

It is in the use cases =96 section 3.7, still lo= oking back at the mailing list discussion the feeling is this use case is t= o test extensibility of the CLUE solution and there would be no specific re= quirements

Roni=

=A0

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 23 July, 2013 8:36 PM
To: clue issue tracker
C= c: CLUE; draft-ietf-clue-telepresence-requirements@t= ools.ietf.org
Subject: Re: [clue] #42: OPEN-6. Multi-view

=

=A0=

I propose to just close this issue with the= answer being "No". =A0I don't know even what's meant by = that term - it's not used in the FW or usecases.

=A0

If you have any concerns, or you have more info about what this is = intended for, please respond no later than August 12, 2013.

=A0

Mary.

=A0

On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker <trac+clue@trac.too= ls.ietf.org> wrote:

#42: OPEN-6. =A0Multi= -view

=A0Is there a requirement needed?

--
---------------= ----------------------+-------------------------------------
=A0Reporter= : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: = =A0draft-ietf-clue-
=A0 mary.ie= tf.barnes@gmail.com =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Ty= pe: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Miles= tone: =A0milestone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0Version:
=A0Severity: =A0Active WG Document =A0 =A0 = =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

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

=A0


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


--001a11c3b30aef2e8f04e23348e3-- From pkyzivat@alum.mit.edu Tue Jul 23 14:30:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8140811E8145 for ; Tue, 23 Jul 2013 14:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ1DgxBoBJ4H for ; Tue, 23 Jul 2013 14:30:54 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id AACD111E8136 for ; Tue, 23 Jul 2013 14:30:53 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 3p1R1m0040QuhwU5BxWt0q; Tue, 23 Jul 2013 21:30:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 3xWr1m01E3ZTu2S3NxWslU; Tue, 23 Jul 2013 21:30:53 +0000 Message-ID: <51EEF607.6080809@alum.mit.edu> Date: Tue, 23 Jul 2013 17:30:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374615053; bh=HGl+03qLpWTMRRoiMZLEoCns4VRfEKt5fkAvsSNMtdA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZnnH3wUYahrM0+4G9FKYcGA7m1nuJU/AqM7Dn8j7jdFepLqXi5FbVyNddqW/nfzsm FSUyfjdy1qzlkQeId7oqWR0PHUJXIN3YZY7cNXF2cZfHl/1Jb53FQsFQ7mA5meNene yvCtJpsHgiLVzJOKj2F8//NGP5RRsqF5jMgh/wSmKSUPVfjJXkZTjHyHMk/zuOHflF 3TJsgVtttLhzfI66kzjd/gz/raASapvnANZ6tCmele04v6Yjwa7CfOW9fU9mJxVzpD ogscC0UGzd9UH/92Jh1EI5D2YMyivsoEe86FQyMQcewtzPsa7vDAoi+S2jE/3mmaJJ QgeyVrUG/CFdw== Subject: Re: [clue] #41: OPEN-5. New Requirement - 3D X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 21:30:59 -0000 Mary, ISTM we went to quite a bit of trouble to define point of capture and axis of capture in addition to area of capture because it was thought to be necessary to perform geometric corrections/mappings of the video. This means that we acknowledge that the displays may not be coplanar, and the areas of capture may not be coplanar. That all makes sense only in 3D. So I don't think dropping 3D is a decision to be made lightly. Thanks, Paul On 7/23/13 1:44 PM, Mary Barnes wrote: > I propose to close this issue. We don't have a use case and it hasn't > been discussed in the context of the framework. This was something we > talked about early on, but I do not believe it's required for our > initial deliverables. > > If you have concerns about closing this issue, then please respond no > later than August 12, 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 10:05 AM, clue issue tracker > > > wrote: > > #41: OPEN-5. New Requirement - 3D > > Need to add requirement for three dimensions in the right > place > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com > | telepresence- > Type: enhancement | requirements@tools.ietf.org > > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Jul 23 14:52:50 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B87C11E8149 for ; Tue, 23 Jul 2013 14:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0KpJe-uWMdf for ; Tue, 23 Jul 2013 14:52:42 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 00BCD21F9814 for ; Tue, 23 Jul 2013 14:52:37 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id 3suA1m0051vXlb857xsdcD; Tue, 23 Jul 2013 21:52:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:38e6:305f:7887:aff3]) by omta17.westchester.pa.mail.comcast.net with comcast id 3xsb1m00T0jqEmc3dxsbGw; Tue, 23 Jul 2013 21:52:37 +0000 Message-ID: <51EEFB22.5070002@alum.mit.edu> Date: Tue, 23 Jul 2013 17:52:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <51E7FECE.7000607@alum.mit.edu> <51E8952D.9020106@nteczone.com> In-Reply-To: <51E8952D.9020106@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374616357; bh=5KFODaXACFlisO2lr828PDBg4zGvPsoafho/wz0V9ck=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=n8ivrVfXD1TOZC5+32qhW8yvUcjtagoOoEYcCCFRabxSH8tcvMof+83gazW3caokE GtiUMmlFcbASgCW85/600Z/KqTUD1LKRhW+nnwSW6/hO1r18IWjU3uf+04k4QHQti0 5IcWVuLDLxHXg4vtDZWRu4qBh4RrrhKE6zZGWmxmqsuVleI0mRh30RmtzT+va7e5jZ Gg2YJkIgbiujN+AUdRNhqhf1oIJOvd5PaAiS7yPOnBg42FSggiTPWEfJHdlAxC6u01 wjqXq7CVDpNvEZfFCfWWU06EHh7/RfZeaVewvgkuFtSVONxYZ+uYd7eNwe8Fp1zt71 Yuocsgp96kBLA== Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:52:50 -0000 On 7/18/13 9:23 PM, Christian Groves wrote: > Hello Paul, > > There was a bounding attribute "the scene area" which was removed. As I > mentioned at the time the idea was to give an indication of how the > capture areas were located in the room. Yeah. But it wasn't sufficient to say much useful for the question I am asking below. So it probably made sense to remove it. More below. > With regards to audio I think we need to revisit that with respect to > the spatial attributes. > > Regards, Christian > > On 19/07/2013 12:42 AM, Paul Kyzivat wrote: >> Christian, >> >> You raise a point that has bothered me for some time: Note: this point wasn't raised to Christian. It is really addressed to all the telepresence experts. >> We describe the spatial attributes of a capture by point of capture >> and area of capture (a quadrilateral). Implicitly this describes an >> unbounded pyramid. In reality, it is bounded by the geometry of the >> room and the stuff in it, but we don't have that info. This pyramid >> may be meaningful in some sense for video, though we lack other >> information such as depth of field. But as John replied, I guess it >> means very little for audio. So I think the following is still an important question to answer: >> The fundamental question is: does this provide sufficient information >> for the consumer to properly adapt the received media to his available >> equipment? I don't know the answer to that, but I suspect that it will >> allow some approximation, but probably not enough to do the best >> possible job. Is there more that we ought to be providing to help with >> that job? Or does doing more provide diminishing returns? I don't have any specific requirement of offer to address it. I just ask everybody with knowledge of a real telepresence implementation: Will you be able to do a satisfactory job of this from an arbitrary received advertisement? (Without making further assumptions about constraints on the advertiser.) If the answer is NO, then we should ask what we would need to fix that. I don't think this calls for any change in requirements, because what I am asking is what is called for in requirements #1,2. Thanks, Paul >> Thanks, >> Paul >> >> On 7/17/13 11:01 PM, Christian Groves wrote: >>> Hello Mary, >>> >>> I did a review of the requirements and Appendix to see if they are met. >>> My comments are below. Sorry for the length of the email but I figured >>> it would be easier for people to read my comment [CNG] along with the >>> requirement. >>> >>> REQMT-1:The solution MUST support a description of the spatial >>> >>> arrangement of source video images sent in video streams >>> >>> which enables a satisfactory reproduction at the receiver >>> >>> of the original scene.This applies to each site in a >>> >>> point to point or a multipoint meeting and refers to the >>> >>> spatial ordering within a site, not to the ordering of >>> >>> images between sites. >>> >>> [CNG] Supported via Capture Area attribute. >>> >>> Use case point to point symmetric, and all other use cases. >>> >>> REQMT-1a:The solution MUST support a means of allowing >>> >>> the preservation of the order of images in the >>> >>> captured scene.For example, if John is to >>> >>> Susan's right in the image capture, John is >>> >>> also to Susan's right in the rendered image. >>> >>> [CNG] Supported via Capture Area attribute. >>> >>> REQMT-1b:The solution MUST support a means of allowing >>> >>> the preservation of order of images in the >>> >>> scene in two dimensions - horizontal and >>> >>> vertical. >>> >>> [CNG] Supported via Capture Area attribute. >>> >>> REQMT-1c:The solution MUST support a means to identify >>> >>> the point of capture of individual video >>> >>> captures in three dimensions. >>> >>> [CNG] Supported via Point of capture attribute. >>> >>> REQMT-1d:The solution MUST support a means to identify >>> >>> the extent of individual video captures in >>> >>> three dimensions. >>> >>> [CNG] Partial Capture area attribute allows the specification of a >>> plane of capture in 3 dimensions. However depth of the capture (needed >>> for a 3D area) is not supported. >>> >>> REQMT-2:The solution MUST support a description of the spatial >>> >>> arrangement of captured source audio sent in audio streams >>> >>> which enables a satisfactory reproduction at the receiver >>> >>> in a spatially correct manner.This applies to each site >>> >>> in a point to point or a multipoint meeting and refers to >>> >>> the spatial ordering within a site, not the ordering of >>> >>> channels between sites. >>> >>> [CNG] Supported Via Capture Area attribute. >>> >>> Use case point to point symmetric, and all use cases, >>> >>> especially heterogeneous. >>> >>> REQMT-2a:The solution MUST support a means of preserving >>> >>> the spatial order of audio in the captured >>> >>> scene.For example, if John sounds as if he is >>> >>> at Susan's right in the captured audio, John >>> >>> voice is also placed at Susan's right in the >>> >>> rendered image. >>> >>> [CNG] Supported Via Capture Area attribute. >>> >>> REQMT-2b:The solution MUST support a means to identify >>> >>> the number and spatial arrangement of audio >>> >>> channels including monaural, stereophonic >>> >>> (2.0), and 3.0 (left, center, right) audio >>> >>> channels. >>> >>> [CNG] Partial the Audio Channel Format attribute currently only >>> supports 搈ono and 搒tereo. It doesn抰 support the 3.0 format. >>> >>> REQMT-2c:The solution MUST NOT preclude the use of >>> >>> binaural audio.[Edt. This is an outstanding >>> >>> issue.Text will be changed when the issue is >>> >>> resolved.] >>> >>> [CNG] Partial? Binaural isn抰 mentioned in the framework so isn抰 >>> precluded as such. There is no indication in CLUE recording a binaural >>> capture. >>> >>> REQMT-2d:The solution MUST support a means to identify >>> >>> the point of capture of individual audio >>> >>> captures in three dimensions. >>> >>> [CNG] Supported via Point of capture attribute. >>> >>> REQMT-2e:The solution MUST support a means to identify >>> >>> the extent of individual audio captures in >>> >>> three dimensions. >>> >>> [CNG] Partial The Capture area attribute is based on capturing a plane >>> in Cartesian space. There is no depth parameter. Whether the plane >>> concept holds for audio like it does video needs further thought. >>> >>> REQMT-3:The solution MUST support a mechanism to enable a >>> >>> satisfactory spatial matching between audio and video >>> >>> streams coming from the same endpoints. >>> >>> [CNG] Supported - The given that an Advertiser places captures in a >>> particular scene it is possible to indicate audio and video streams are >>> from the same endpoint. >>> >>> Use case is point to point symmetric, and all use cases. >>> >>> REQMT-3a:The solution MUST enable individual audio >>> >>> streams to be associated with one or more video >>> >>> image captures, and individual video image >>> >>> captures to be associated with one or more >>> >>> audio captures, for the purpose of rendering >>> >>> proper position. >>> >>> [CNG] Supported (Partial?) It is possible to deduce that audio and >>> video relate to the same capture area in a scene by analysing the >>> Capture Area parameters. It is possible to relate individual audio >>> captures to video captures if the Advertisement is constructed in a >>> limited way. However its not possible to deduce the relationships >>> between individual captures by utilising the Scene, CSE and capture >>> concepts. CSE only relate to one media type. So it抯 not possible to >>> link audio CSEs to video CSEs. >>> >>> REQMT-3b:The solution MUST enable individual audio >>> >>> streams to be rendered in any desired spatial >>> >>> position. >>> >>> [CNG] Supported? I think its assumed that a Consumer can do whatever >>> it likes with respect to rendering decisions. Ultimately that抯 local >>> policy. >>> >>> Edt: Rendering is an open issue. Text will >>> >>> be changed when it is resolved.] >>> >>> REQMT-4:The solution MUST enable interoperability between >>> >>> endpoints that have a different number of similar devices. >>> >>> For example, one endpoint may have 1 screen, 1 speaker, 1 >>> >>> camera, 1 mic, and another endpoint may have 3 screens, 2 >>> >>> speakers, 3 cameras and 2 mics.Or, in a multi-point >>> >>> conference, one endpoint may have one screen, another may >>> >>> have 2 screens and a third may have 3 screens.This >>> >>> includes endpoints where the number of devices of a given >>> >>> type is zero. >>> >>> Use case is asymmetric point to point and multipoint. >>> >>> [CNG] Supported CLUE enables different capture capabilities to be >>> signalled. It makes no assumption as to the rendering. >>> >>> REQMT-5:The solution MUST support means of enabling >>> >>> interoperability between telepresence endpoints where >>> >>> cameras are of different picture aspect ratios. >>> >>> [CNG] Supported CLUE doesn抰 describe 揳spect ratio but allows >>> different capture areas to be defined. This is a means of describing >>> aspect ratio. >>> >>> REQMT-6:The solution MUST provide scaling information which >>> >>> enables rendering of a video image at the actual size of >>> >>> the captured scene. >>> >>> [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture >>> and Scene Scale allow this. >>> >>> REQMT-7:The solution MUST support means of enabling >>> >>> interoperability between telepresence endpoints where >>> >>> displays are of different resolutions. >>> >>> [CNG] Supported? CLUE allow encoding parameters to be associated with >>> captures which could state the resolution of the captured image. However >>> there is no way to indicate 揹isplay resolution. Perhaps the >>> requirement needs to be reworded? >>> >>> REQMT-8:The solution MUST support methods for handling different >>> >>> bit rates in the same conference. >>> >>> [CNG] Supported CLUE allow encoding parameters to be associated with >>> captures which could state the bit rate. >>> >>> REQMT-9:The solution MUST support means of enabling >>> >>> interoperability between endpoints that send and receive >>> >>> different numbers of media streams. >>> >>> Use case heterogeneous and multipoint. >>> >>> [CNG] Supported CLUE allows different numbers of captures to be sent. >>> >>> REQMT-10:The solution MUST make it possible for endpoints without >>> >>> support for telepresence extensions to participate in a >>> >>> telepresence session with those that do. >>> >>> [CNG] Supported The support of a CLUE channel will be negotiated >>> between endpoints. From the current signalling draft it seems a basic >>> set of media can be established without CLUE. Endpoints that don抰 >>> support CLUE obviously won抰 be able to determine spatial information >>> etc >>> >>> REQMT-11:The solution MUST support a mechanism for determining >>> >>> whether or not an endpoint or MCU is capable of >>> >>> telepresence extensions. >>> >>> [CNG] Supported? The negotiation of a CLUE channel via SDP is one >>> method in the signalling draft. Another indication at the SIP level may >>> be beneficial such as a feature tag. This is yet to be documented. >>> >>> REQMT-12:The solution MUST support a means to enable more than two >>> >>> sites to participate in a teleconference. >>> >>> Use case multipoint. >>> >>> [CNG] Partial This is on the agenda and there抯 basic support i.e. via >>> the composed attribute and 搒cene-switch-policy CSE attribute. However >>> no method is yet defined to keep the source information. >>> >>> REQMT-13:The solution MUST support both transcoding and switching >>> >>> approaches to providing multipoint conferences. >>> >>> [CNG] Supported CLUE supports these two methods. However further work >>> is needed on the details. >>> >>> REQMT-14:The solution MUST support mechanisms to make possible for >>> >>> either or both site switching or segment switching.[Edt: >>> >>> This needs rewording.Deferred until layout discussion is >>> >>> resolved.] >>> >>> [CNG] Partial The 搒cene-switch-policy CSE attribute supports this to >>> some level but further work is needed in this area. >>> >>> REQMT-15:The solution MUST support mechanisms for presentations in >>> >>> such a way that: >>> >>> *Presentations can have different sources >>> >>> *Presentations can be seen by all >>> >>> *There can be variation in placement, number and size of >>> >>> Presentations >>> >>> [CNG] Partial CLUE allows an endpoint whether the capture is related >>> to a presentation or not through the use of the presentation attribute. >>> The spatial attributes (i.e. capture area) allows the place and size to >>> be indicated. The number can be inferred from the number of captures. >>> CLUE doesn抰 have any policy on who can see the presentations. The CLUE >>> Advertisement mechanism may include presentation captures to all people >>> within the conference. Perhaps the 2^nd bullet can be removed or >>> clarified that its not related to policy? >>> >>> REQMT-16:The solution MUST include extensibility mechanisms. >>> >>> [CNG] Supported? whilst not explicitly documented I think there抯 >>> general agreement this is needed. >>> >>> REQMT-17:The solution must support a mechanism for allowing >>> >>> information about media captures to change during a >>> >>> conference. >>> >>> [CNG] Supported? Keeping the CLUE signalling channel open would allow >>> for this and people seem in agreement this should be possible. Further >>> detailed work is needed in the signalling draft to describe this. i.e. >>> incremental vs full updates. Interaction with bearer signalling (i.e. >>> SDP O/A) etc. >>> >>> REQMT-18:The solution MUST provide a mechanism for the secure >>> >>> exchange of information about the media captures. >>> >>> [CNG] Partial? It is assumed that CLUE will operate over a DTLS/SCTP >>> however there抯 no documentation regarding CLUE security. >>> >>> Appendix A. open issues >>> >>> OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural >>> >>> audio is unresolved, and the "MUST NOT preclude" language in >>> >>> this requirement is problematic.The authors believe this >>> >>> requirement needs to be either changed or withdrawn, >>> >>> depending on how the issue is resolved. >>> >>> [CNG] Not supported - This is still unresolved. >>> >>> OPEN-2Reference to Rendering [REQMT-3b] This is the only >>> >>> requirement which refers to rendering.It may also be empty, >>> >>> since receivers can rendering audio captures as they wish. >>> >>> This is deferred until broader discussion on rendering >>> >>> requirements is concluded. >>> >>> [CNG] I think we should frame the requirements with regards to captures >>> as that抯 the way the framework is written. Perhaps some text to say >>> that rendering is based on the receivers local policy. >>> >>> OPEN-3Conference modes [REQMT-14] This wording of this requirement >>> >>> is problematic in part because the conference modes (site >>> >>> switching and segment switching) are not defined.It at >>> >>> least needs rewording.This is deferred until broader >>> >>> discussion on layout is concluded. >>> >>> [CNG] Yes this is still open. >>> >>> OPEN-4Need to capture requirement that attributes can change at any >>> >>> time during the call. >>> >>> [CNG] Yes although it seems REQMT-17 covers this. >>> >>> OPEN-5Need to add requirement for three dimensions in the right >>> >>> place >>> >>> [CNG] Requirements 1d and 2e do capture an aspect of 3D. >>> >>> OPEN-6Multi-view, is there a requirement needed? >>> >>> [CNG] Even if there抯 no requirement we appear to support it because we >>> allow both the capture area and capture point to be sent for captures. >>> An Advertiser could describe multiple capture points capturing the same >>> area of capture. >>> >>> >>> Regards, Christian >>> >>> On 17/07/2013 6:07 AM, Mary Barnes wrote: >>>> There really were no changes other than to refresh this draft. I was >>>> going to extend the security section with more detail, but I really >>>> can't add much more detail without referencing things that are defined >>>> in the framework. So, I think the next step is for me to work with >>>> Mark on the security for the framework. >>>> >>>> There are some open issues identified in the appendix of this document >>>> that we need to figure out whether they are issues that need >>>> resolution for this document. I will open issues in the tracker and we >>>> can discuss each one and perhaps make some decisions before Berlin. >>>> >>>> We also need to consider whether the current framework meets these >>>> requirements. If some requirements are not met, we need to decide >>>> whether it's because they'll be met by the solution documents or won't >>>> be met at all. In which case, we need to decide whether we actually >>>> need them for the solution. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Jul 16, 2013 at 11:29 AM, >>> > wrote: >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the ControLling mUltiple streams for >>>> tElepresence Working Group of the IETF. >>>> >>>> Title : Requirements for Telepresence Multi-Streams >>>> Author(s) : Allyn Romanow >>>> Stephen Botzko >>>> Mary Barnes >>>> Filename : draft-ietf-clue-telepresence-requirements-04.txt >>>> Pages : 14 >>>> Date : 2013-07-15 >>>> >>>> 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 datatracker status page for this draft is: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements >>>> >>>> >>>> >>>> There's also a htmlized version available at: >>>> >>>> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04 >>>> >>>> A diff from the previous version is available at: >>>> >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04 >>>> >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft >>>> >>>> directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Tue Jul 23 15:27:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7811E8158 for ; Tue, 23 Jul 2013 15:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.343 X-Spam-Level: X-Spam-Status: No, score=-101.343 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6JEnQW86wrT for ; Tue, 23 Jul 2013 15:27:41 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6756F11E8150 for ; Tue, 23 Jul 2013 15:27:40 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 1so1190828qec.8 for ; Tue, 23 Jul 2013 15:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ef0qpbwR4vQLNRCrMlYSJJmi51PjZAO8/uMHlfNbmxg=; b=WEEq12UKt29n8Qp4Ip5B0uQTMo4/oLJXPJ9ouBCYE9VzpgcQcQfWqmsarmw4y1a2gZ FtzqMC+M/o4Bu+33fj8Gbd842oB/hYldHFB61UeTcZaHTGyV/EEWau44yAfjuBWq+U54 FQF6jtdh09GwgoXvn+2EM/tXGqd4zrZUNv2qU+my2OS9BgZF8R889kL8VkUo8wj+Bbnz 1sMmR7zrK/5MtRd5boRu22XqWSwYoTmr7OGSoWkT1Agnk+oMvt7WFJJEQNKVxgFZjBxm z6+BsfywYMxbW/5Lh4AhW4f4HCHwz8O8Z5CYQC5UkNk8uLwTonq5KaWNUZGP1w1MsMAn NBQw== MIME-Version: 1.0 X-Received: by 10.229.33.136 with SMTP id h8mr7939704qcd.25.1374618458697; Tue, 23 Jul 2013 15:27:38 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 15:27:38 -0700 (PDT) In-Reply-To: <51EEF607.6080809@alum.mit.edu> References: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> <51EEF607.6080809@alum.mit.edu> Date: Tue, 23 Jul 2013 17:27:38 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=14dae9d70d0aeeb93704e2354c11 Cc: CLUE Subject: Re: [clue] #41: OPEN-5. New Requirement - 3D X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 22:27:42 -0000 --14dae9d70d0aeeb93704e2354c11 Content-Type: text/plain; charset=ISO-8859-1 The question then is whether we need an explicit, unique requirement for the solution in order to support 3D? This issue was added to the requirements document 21 months ago. If we go back to the charts presented at IETF-82 (November, 2011) it looks like it's already been discussed (and I think resolved): http://www.ietf.org/proceedings/82/slides/clue-1.pdf Here's the specific comments on addressing OPEN-5: Authors propose (slide 3): REQMT-1d: The solution MUST support a means to identify the extent of individual video captures in three dimensions REQMT-2e: The solution MUST support a means to identify the extent of individual audio captures in three dimensions. IN addition, the following is proposed on slide 4: REQMT-1c: The solution MUST support a means to identify the point of capture of individual video captures in three dimensions REQMT-2d: The solution MUST support a means to identify the point of capture of individual audio captures in three dimensions. So, it looks to me that requirements were already added to address this issue and thus we should close the issue: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-clue-telepresence-requirements-02.txt I'm thinking the ball was dropped as Allyn was no longer participating by IETF-83. You can see that we never discussed this document again after IETF-82. Mary. On Tue, Jul 23, 2013 at 4:30 PM, Paul Kyzivat wrote: > Mary, > > ISTM we went to quite a bit of trouble to define point of capture and axis > of capture in addition to area of capture because it was thought to be > necessary to perform geometric corrections/mappings of the video. This > means that we acknowledge that the displays may not be coplanar, and the > areas of capture may not be coplanar. That all makes sense only in 3D. > > So I don't think dropping 3D is a decision to be made lightly. > > Thanks, > Paul > > > On 7/23/13 1:44 PM, Mary Barnes wrote: > >> I propose to close this issue. We don't have a use case and it hasn't >> been discussed in the context of the framework. This was something we >> talked about early on, but I do not believe it's required for our >> initial deliverables. >> >> If you have concerns about closing this issue, then please respond no >> later than August 12, 2013. >> >> Thanks, >> Mary. >> >> >> On Tue, Jul 23, 2013 at 10:05 AM, clue issue tracker >> >> >> >> >> wrote: >> >> #41: OPEN-5. New Requirement - 3D >> >> Need to add requirement for three dimensions in the right >> place >> >> -- >> ------------------------------**-------+----------------------** >> --------------- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com >> > >> | telepresence- >> Type: enhancement | requirements@tools.ietf.org >> > >> >> Priority: minor | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------**-------+----------------------** >> --------------- >> >> Ticket URL: >> > >> clue >> > >> >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --14dae9d70d0aeeb93704e2354c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The question then is whether we need an explicit, unique r= equirement for the solution in order to support 3D?=A0

= =A0This issue was added to the requirements document 21 months ago. =A0If w= e go back to the charts presented at IETF-82 (November, 2011) it looks like= it's already been discussed (and I think resolved):
=A0ht= tp://www.ietf.org/proceedings/82/slides/clue-1.pdf

<= div>Here's the specific comments on addressing OPEN-5:

Authors propose (slide 3):=A0
REQMT-1d: The solution MUST su= pport a means to identify the extent of individual video captures in three = dimensions

REQMT-2e: The solution MUST support a m= eans to identify the extent of individual audio captures in three dimension= s.

IN addition, the following is proposed on slide 4:

REQMT-1c: The solution MUST support a m= eans to identify the point of capture of individual video captures in three= dimensions

REQMT-2d: The solution MUST support a means to identify= the point of capture of individual audio captures in three dimensions.

So, it looks to me that requir= ements were already added to address this issue and thus we should close th= e issue:

I'm thinking the ball was dropped as Allyn wa= s no longer participating by IETF-83. =A0You can see that we never discusse= d this document again after IETF-82.=A0

Mary.<= /div>


O= n Tue, Jul 23, 2013 at 4:30 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Mary,

ISTM we went to quite a bit of trouble to define point of capture and axis = of capture in addition to area of capture because it was thought to be nece= ssary to perform geometric corrections/mappings of the video. This means th= at we acknowledge that the displays may not be coplanar, and the areas of c= apture may not be coplanar. That all makes sense only in 3D.

So I don't think dropping 3D is a decision to be made lightly.

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


On 7/23/13 1:44 PM, Mary Barnes wrote:
I propose to close this issue. =A0We don't have a use case and it hasn&= #39;t
been discussed in the context of the framework. =A0This was something we talked about early on, but I do not believe it's required for our
initial deliverables.

If you have concerns about closing this issue, then please respond no
later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 10:05 AM, clue issue tracker
<tr= ac+clue@trac.tools.ietf.org <mailto:trac+clue@trac.tools.ietf.org>>

wrote:

=A0 =A0 #41: OPEN-5. =A0New Requirement - 3D

=A0 =A0 =A0 Need to add requirement for three dimensions in the right
=A0 =A0 =A0 place

=A0 =A0 --
=A0 =A0 -------------------------------------+----------------------= ---------------
=A0 =A0 =A0 Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0Owner: =A0draft-ietf-clue-
=A0 =A0 mar= y.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>
=A0 =A0 =A0 =A0| =A0telepresence-
=A0 =A0 =A0 =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| requirements@to= ols.ietf.org
=A0 =A0 <mailto:requirements@tools.ietf.org>

=A0 =A0 =A0 Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0= =A0 Status: =A0new
=A0 =A0 Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: = =A0milestone1
=A0 =A0 =A0 =A0requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0Version:
=A0 =A0 =A0 Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
=A0 =A0 -------------------------------------+----------------------= ---------------

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




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


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

--14dae9d70d0aeeb93704e2354c11-- From mary.ietf.barnes@gmail.com Tue Jul 23 15:35:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CEC11E8150 for ; Tue, 23 Jul 2013 15:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C5B2AH+J+OG for ; Tue, 23 Jul 2013 15:35:51 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B911E8224 for ; Tue, 23 Jul 2013 15:33:30 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 1so1193613qec.8 for ; Tue, 23 Jul 2013 15:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QeM7fzBUgun313dZJlQURqgOtKu8fyW5pdm7un18DFs=; b=AFZAQQG75wZZz4Bw7g/yQj6KPQWYQNZd8OhJh0PONYvX2yLTgvfWRS7cQv3fdGnnu6 qShDxozofKCMMqWxo3MZexPMagG1B8dpha74uzj/w/TGajNM/Nc+AUQXSvZxhbd/G1Gk PplLKCoKlXzD16Lcnp8oIH7HmYKXBXHD/ScYbo73mWzG6E2Tg5GQFC+kxdz/Rq/yWpU1 GeCTjD3D31i2aG+S1jc8ievtZk4t+jY3n2fs2xPrDZ3K8PmQ2MFmViQd8Xpyhtrdbyid IkMEr2EyTURtoQ8YGb+FaeZUy0lafPXPPGWCRloT5aKURw2fk9Xaesn97kFxdZmspaq9 8HRw== MIME-Version: 1.0 X-Received: by 10.224.161.76 with SMTP id q12mr24174024qax.3.1374618809451; Tue, 23 Jul 2013 15:33:29 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 23 Jul 2013 15:33:29 -0700 (PDT) In-Reply-To: References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> <092001ce87db$4bb87350$e32959f0$@gmail.com> Date: Tue, 23 Jul 2013 17:33:29 -0500 Message-ID: From: Mary Barnes To: Stephen Botzko Content-Type: multipart/alternative; boundary=089e0149528ed6d41b04e23561dd Cc: CLUE , clue issue tracker , draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 22:35:52 -0000 --089e0149528ed6d41b04e23561dd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I was digging for background on Ticket #41/OPEN-5, I found that we had already discussed this issue and the conclusion as I found in minutes from IETF-82: http://www.ietf.org/proceedings/82/minutes/clue.html was consistent with what was presented (chart 5): http://www.ietf.org/proceedings/82/slides/clue-1.pdf "As in Use Case draft, meaning capturing the same field of view from multiple camera angles We feel it is covered in the above, which specifies the location of the viewpoint and the capture area" So, I think we can definitely close this issue. Mary On Tue, Jul 23, 2013 at 3:03 PM, Stephen Botzko w= rote: > Section 3.7 describes the case where different cameras are aimed at the > same participant, to get different perspectives. Other systems receive a= nd > present the capture that gives the correct eye-contact for the display th= ey > chose to render it on. > > The attributes in the framework already allow such captures to be signale= d > and selected. What is perhaps missing is a way for all the endpoints to > know their assigned location in the virtual room. > > I agree with Roni (and the previous mailing list discussion) that this us= e > case could be used to test extensibility - so no requirements would be > needed. > > Steve > > On Tue, Jul 23, 2013 at 3:31 PM, Roni Even wrote= : > >> Mary,**** >> >> It is in the use cases =96 section 3.7, still looking back at the mailin= g >> list discussion the feeling is this use case is to test extensibility of >> the CLUE solution and there would be no specific requirements**** >> >> Roni**** >> >> ** ** >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* 23 July, 2013 8:36 PM >> *To:* clue issue tracker >> *Cc:* CLUE; draft-ietf-clue-telepresence-requirements@tools.ietf.org >> *Subject:* Re: [clue] #42: OPEN-6. Multi-view**** >> >> ** ** >> >> I propose to just close this issue with the answer being "No". I don't >> know even what's meant by that term - it's not used in the FW or usecase= s. >> **** >> >> ** ** >> >> If you have any concerns, or you have more info about what this is >> intended for, please respond no later than August 12, 2013.**** >> >> ** ** >> >> Mary.**** >> >> ** ** >> >> On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker < >> trac+clue@trac.tools.ietf.org> wrote:**** >> >> #42: OPEN-6. Multi-view >> >> Is there a requirement needed? >> >> -- >> >> -------------------------------------+----------------------------------= --- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com | telepresence- >> Type: enhancement | requirements@tools.ietf.org >> Priority: minor | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> >> -------------------------------------+----------------------------------= --- >> >> Ticket URL: >> clue **** >> >> ** ** >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --089e0149528ed6d41b04e23561dd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
As I was digging for background on Ticket #41/OPEN-5, I fo= und that we had already discussed this issue and the conclusion as I found = in minutes from IETF-82:
was consistent with what was presented (chart 5):
=

&quo= t;As in Use Case draft, meaning capturing the same field of view from multi= ple camera angles
We feel it is covered in the above, which specifies the location of th= e viewpoint and the capture area"
So, I thi= nk we can definitely close this issue.

Mary


O= n Tue, Jul 23, 2013 at 3:03 PM, Stephen Botzko <stephen.botzko@gmai= l.com> wrote:
Section 3.7 describes the case where differe= nt cameras are aimed at the same participant, to get different perspectives= .=A0 Other systems receive and present the capture that gives the correct e= ye-contact for the display they chose to render it on.

The attributes in the framework already allow such captures to be signa= led and selected.=A0 What is perhaps missing is a way for all the endpoints= to know their assigned location in the virtual room.

I agree with = Roni (and the previous mailing list discussion) that this use case could be= used to test extensibility - so no requirements would be needed.

Steve

On Tue, = Jul 23, 2013 at 3:31 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Mary,

It is in the use cases =96 section 3.7, still lo= oking back at the mailing list discussion the feeling is this use case is t= o test extensibility of the CLUE solution and there would be no specific re= quirements

Roni=

=A0

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 23 July, 2013 8:36 PM
To: clue issue tracker
C= c: CLUE; draft-ietf-clue-telepresence-requirements@t= ools.ietf.org
Subject: Re: [clue] #42: OPEN-6. Multi-view

=

=A0

I propose to just close this issue with the answer being= "No". =A0I don't know even what's meant by that term - i= t's not used in the FW or usecases.

=A0

If you have any concerns, or you have more info about what this is = intended for, please respond no later than August 12, 2013.

=A0

Mary.

=A0

On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker <trac+clue@trac.too= ls.ietf.org> wrote:

#42: OPEN-6. =A0Multi= -view

=A0Is there a requirement needed?

--
---------------= ----------------------+-------------------------------------
=A0Reporter= : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: = =A0draft-ietf-clue-
=A0 mary.ie= tf.barnes@gmail.com =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Ty= pe: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ietf.org =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Miles= tone: =A0milestone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0Version:
=A0Severity: =A0Active WG Document =A0 =A0 = =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

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

=A0


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



--089e0149528ed6d41b04e23561dd-- From Christian.Groves@nteczone.com Tue Jul 23 17:14:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24B711E8199 for ; Tue, 23 Jul 2013 17:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-nab19lSi+6 for ; Tue, 23 Jul 2013 17:14:58 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id BB5C711E8195 for ; Tue, 23 Jul 2013 17:14:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAGEb71F20eLE/2dsb2JhbAANToM7wTeBK4MYAQEBBAEBAS8BBRsbChELEQQBAQEJFggHCQMCAQIBDwYfCQgTBgIBAReHYwMbpWqJSQ2IXo0SgUOBL4QAA5V2gxKKfohM Received: from ppp118-209-226-196.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.226.196]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Jul 2013 09:44:53 +0930 Message-ID: <51EF1C78.6080809@nteczone.com> Date: Wed, 24 Jul 2013 10:14:48 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> <092001ce87db$4bb87350$e32959f0$@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 00:14:58 -0000 Hello Mary, I agree with Steve, although I'm interested in his comment with regards to the location in the virtual room. Steve: can you elaborate on what you see the issue is here? Regards, Christian On 24/07/2013 6:03 AM, Stephen Botzko wrote: > Section 3.7 describes the case where different cameras are aimed at > the same participant, to get different perspectives. Other systems > receive and present the capture that gives the correct eye-contact for > the display they chose to render it on. > > The attributes in the framework already allow such captures to be > signaled and selected. What is perhaps missing is a way for all the > endpoints to know their assigned location in the virtual room. > > I agree with Roni (and the previous mailing list discussion) that this > use case could be used to test extensibility - so no requirements > would be needed. > > Steve > > On Tue, Jul 23, 2013 at 3:31 PM, Roni Even > wrote: > > Mary, > > It is in the use cases section 3.7, still looking back at the > mailing list discussion the feeling is this use case is to test > extensibility of the CLUE solution and there would be no specific > requirements > > Roni > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] *On > Behalf Of *Mary Barnes > *Sent:* 23 July, 2013 8:36 PM > *To:* clue issue tracker > *Cc:* CLUE; > draft-ietf-clue-telepresence-requirements@tools.ietf.org > > *Subject:* Re: [clue] #42: OPEN-6. Multi-view > > I propose to just close this issue with the answer being "No". I > don't know even what's meant by that term - it's not used in the > FW or usecases. > > If you have any concerns, or you have more info about what this is > intended for, please respond no later than August 12, 2013. > > Mary. > > On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker > > wrote: > > #42: OPEN-6. Multi-view > > Is there a requirement needed? > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | > telepresence- > Type: enhancement | requirements@tools.ietf.org > > Priority: minor | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Jul 23 17:21:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A8711E81A1 for ; Tue, 23 Jul 2013 17:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OCprZTzWcht for ; Tue, 23 Jul 2013 17:21:34 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0A11E819A for ; Tue, 23 Jul 2013 17:21:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIId71F20eLE/2dsb2JhbAANTsRygSuDGQEBBDgbJQEQCyEWDwkDAgECAUUGDQEHAQGuBZI0j30HhAADrFI Received: from ppp118-209-226-196.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.226.196]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Jul 2013 09:51:10 +0930 Message-ID: <51EF1DEE.9010708@nteczone.com> Date: Wed, 24 Jul 2013 10:21:02 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Leslie References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> In-Reply-To: <20130723184052.GA8295@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:21:36 -0000 Hello John, ..snip.. >> [CNG] Could you perhaps propose some attributes (and descriptive text) >> based on direction and sensitivity pattern that you mentioned above? It >> would be good to have something more to discuss. > I have negative desire to propose any requirement(s) here. > > Nonetheless, perhaps I should elaborate a bit. > > A microphone has a point of capture in three dimensions. This is > worth preserving. The audio it captures has no useful (X,Y) dimensions. > There is a sensitivity pattern; but in most cases it can be ignored. > What can't be ignored is the fall-off in sensitivity with distance and > the increase in latency for a signal to reach it through the air. > > Bottom-line: the point of capture is the only always-significant > feature. The latency becomes significant if you try to pinpoint the > source of the audio captured; but we probably won't do that. (We might, > however, try to blend two microphones, in which case the difference > in latency would _sometimes_ be worth considering.) The reduced audio > level from sources farther away will usually deserve to be ignored. > The desire to keep audio loud enough but not unpleasant is quite > independent of the actual audio level. > [CNG] So what you're basically proposing is that the "Area of Capture" attribute and "Point on capture axis" is changed to be valid only for video capture. Audio captures would only have the "Capture point" and "Audio Channel" parameters? Regards, Christian From Christian.Groves@nteczone.com Tue Jul 23 17:24:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E011E81A2 for ; Tue, 23 Jul 2013 17:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYoG1AfZFlEe for ; Tue, 23 Jul 2013 17:24:14 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5B11E819A for ; Tue, 23 Jul 2013 17:24:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIId71F20eLE/2dsb2JhbAANToM7wTeBK4MYAQEBBAEBATUbGwoRCxgJFggHCQMCAQIBDwYfERMGAgEBF4djAxulbYlJDYhejRKBQ4EvFoNqA5V2gxKKfohM Received: from ppp118-209-226-196.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.226.196]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Jul 2013 09:54:12 +0930 Message-ID: <51EF1EA8.3000202@nteczone.com> Date: Wed, 24 Jul 2013 10:24:08 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 00:24:15 -0000 Hello Mary, Another option is that we remove this requirement as its local policy. The rendering will be more dependent on the actual audio encoding rather than the CLUE information. Regards, Christian On 24/07/2013 3:26 AM, Mary Barnes wrote: > I see two ways to resolve this one. We either change the word > "render" to something more specific OR define the term "Render" in > this document. Render is defined in the FW as: > Render: the process of generating a representation from a media, > such as displayed motion video or sound emitted from loudspeakers. > My suggestion to resolve this one is to just change the replace the > word "render" to something more general. Perhaps changing the > requirement as follows: > > OLD: > REQMT-3b: The solution MUST enable individual audio > streams to be rendered in any desired spatial > position. > > NEW: > REQMT-3b: The solution MUST enable individual audio > streams to be emitted from a specific speaker > based on > spatial information. > > Please provide comments on this proposed change no later than August > 12, 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 10:01 AM, clue issue tracker > > > wrote: > > #38: OPEN-2 Reference to Rendering [REQMT-3b] > > This is the only > requirement which refers to rendering. It may also be empty, > since receivers can render audio captures as they wish. > This is deferred until broader discussion on rendering > requirements is concluded. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com > | telepresence- > Type: enhancement | requirements@tools.ietf.org > > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: - | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Jul 23 17:31:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25F11E819F for ; Tue, 23 Jul 2013 17:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-d0K+HM219F for ; Tue, 23 Jul 2013 17:31:25 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 8790411E819A for ; Tue, 23 Jul 2013 17:31:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJ4f71F20eLE/2dsb2JhbAANToM7g1m9X4ErgxgBAQEEAQEBIBUbFQYEBhELGAICBRYIAwICCQMCAQIBDwYfERMGAgEBh3oDG6VtdIhSDYhegSiLaoFDgS+CX4EhA5V2gxKKfohM Received: from ppp118-209-226-196.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.226.196]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Jul 2013 10:01:06 +0930 Message-ID: <51EF2044.3090308@nteczone.com> Date: Wed, 24 Jul 2013 10:31:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-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: Wed, 24 Jul 2013 00:31:26 -0000 Hello Mary, Here's some text I've been working on with regards to the framework to better describe site and segment switch. The "site-switch" policy means all captures are switched at the same time to keep captures from the same endpoint site together. Let's say the speaker is at site A and everyone else is at a "remote" site. When the room at site A shown, all the camera images from site A are forwarded to the remote sites. Therefore at each receiving remote site, all the screens display camera images from site A. This can be used to preserve full size image display, and also provide full visual context of the displayed far end, site A. In site switching, there is a fixed relation between the cameras in each room and the displays in remote rooms. The room or participants being shown is switched from time to time based on who is speaking or by manual control. The "segment-switch" policy means different captures can switch at different times, and can be coming from different endpoints. Still using site A as where the speaker is, and "remote" to refer to all the other sites, in segment switching, rather than sending all the images from site A, only the image containing the speaker at site A is shown. The camera images of the current speaker and previous speakers (if any) are forwarded to the other sites in the conference. Therefore the screens in each site are usually displaying images from different remote sites - the current speaker at site A and the previous ones. This strategy can be used to preserve full size image display, and also capture the non-verbal communication between the speakers. In segment switching, the display depends on the activity in the remote rooms - generally, but not necessarily based on audio / speech detection. Regards, Christian On 24/07/2013 3:17 AM, Mary Barnes wrote: > My suggestion is to define the terms "site switching" and "segment > switching" in this document using terminology consistent with this > document. NOte, that these terms don't explicitly appear in the > terminology section of the framework, however, they are clearly > described in 6.2.2. So I think we can borrow some of that text and add > a definition to the requirements document and close this issue. My > suggestion is something like: > > Site-switching:there is a fixed relation between the cameras in each > room and the displays in remote rooms. The room or participants being > shown is switched from time to time based on who is speaking or by > manual control. > > Segment-switching: there is a variable relation between the cameras in > each room and the displays in different rooms. Rather than sending all > the images from a room, only the image with the active speaker is sent > from a specific room. Therefore the screens in each site are usually > displaying images from different remote sites - the current speaker at > site A and the previous ones. > > Please make suggestions if you have alternative wording. I'd like to > get this issue closed no later than August 12, 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker > > > wrote: > > #39: OPEN-3 Conference modes [REQMT-14] > > This wording of this requirement > is problematic in part because the conference modes (site > switching and segment switching) are not defined. It at > least needs rewording. This is deferred until broader > discussion on layout is concluded. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com | > telepresence- > Type: defect | requirements@tools.ietf.org > > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Jul 23 19:18:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081A411E81BD for ; Tue, 23 Jul 2013 19:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bS31q3qH0n2 for ; Tue, 23 Jul 2013 19:18:27 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB5911E81BC for ; Tue, 23 Jul 2013 19:18:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALE471F20eLE/2dsb2JhbAANRArCDIJ8gSqDGAEBAQMBMgEFGxUREAsYCSUPAkYGDQEHAQEXh2+lepIvjjsGFIElB4QAA6xSgV8 Received: from ppp118-209-226-196.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.226.196]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Jul 2013 11:48:20 +0930 Message-ID: <51EF3964.80206@nteczone.com> Date: Wed, 24 Jul 2013 12:18:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mary Barnes References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 02:18:29 -0000 Hello Mary, Please see my replies below. Regards, Christian On 24/07/2013 4:09 AM, Mary Barnes wrote: > Thanks very much for your detailed review and comments with regards to > whether the REQ is currently supported in the solution. I have a few > comments below. > > Thanks, > Mary > As editor for the Requirements do > > > ..snip.. > > > REQMT-1d:The solution MUST support a means to identify > > the extent of individual video captures in > > three dimensions. > > [CNG] Partial Capture area attribute allows the specification of > a plane of capture in 3 dimensions. However depth of the capture > (needed for a 3D area) is not supported. > > [MB] Per my comments on open issue 5 from the requirements document > (and Ticket # 41 in the tracker), I was proposing we not require 3D > in the solution at this time. [/MB] [CNG] 3D is also a requirement in the ITU-T Q5/16 work, although like CLUE there has been little technical contribution on it. I've sent an email to the Q5 list to stimulate input. > > > > REQMT-2b:The solution MUST support a means to identify > > the number and spatial arrangement of audio > > channels including monaural, stereophonic > > (2.0), and 3.0 (left, center, right) audio > > channels. > > [CNG] Partial the Audio Channel Format attribute currently only > supports 搈ono and 搒tereo. It doesn抰 support the 3.0 format > > > [MB] So, my question to the group is do we need to support this in the > current work is is this something that could be extended later. I > looked fairly quickly but I also could not find a use case for 3.0[/MB] [CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just make this an integer. So rather "Audio Channel Format" we have a "Number of audio channels capture" parameter. 1 would indicate single channel (e.g. mono), 2 would indicate two channels (e.g. stereo), 5 would indicate five channels (e.g. 5.1). At least this is a future proof way so we don't have to open up this parameter in the future? > > REQMT-2c:The solution MUST NOT preclude the use of > > binaural audio.[Edt. This is an outstanding > > issue.Text will be changed when the issue is > > resolved.] > > [CNG] Partial? Binaural isn抰 mentioned in the framework so > isn抰 precluded as such. There is no indication in CLUE recording > a binaural capture. > > > [MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we > just delete this requirement. [/MB] [CNG] I believe this is Christer's requirement. I don't have a strong preference either way. > > ..snip.. > > REQMT-7:The solution MUST support means of enabling > > interoperability between telepresence endpoints where > > displays are of different resolutions. > > [CNG] Supported? CLUE allow encoding parameters to be associated > with captures which could state the resolution of the captured > image. However there is no way to indicate 揹isplay resolution. > Perhaps the requirement needs to be reworded? > > > [MB] Do you have any suggestions for rewording? [/MB] [CNG] The solution MUST support a means for an endpoint to indicate it's supported video capture and encoding parameters. A receiving endpoint may use this information to determine which which video it requires. > ..snip.. > > REQMT-15:The solution MUST support mechanisms for presentations in > > such a way that: > > *Presentations can have different sources > > *Presentations can be seen by all > > *There can be variation in placement, number and size of > > Presentations > > [CNG] Partial CLUE allows an endpoint whether the capture is > related to a presentation or not through the use of the > presentation attribute. The spatial attributes (i.e. capture area) > allows the place and size to be indicated. The number can be > inferred from the number of captures. CLUE doesn抰 have any policy > on who can see the presentations. The CLUE Advertisement mechanism > may include presentation captures to all people within the > conference. Perhaps the 2^nd bullet can be removed or clarified > that its not related to policy? > > [MB] I'm of a mindset to just remove that 2nd bullet. [/MB] [CNG] I'm ok with removing it. > > ..snip From coverdale@sympatico.ca Wed Jul 24 09:07:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E136421F888F for ; Wed, 24 Jul 2013 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rN1tZIx0h6i for ; Wed, 24 Jul 2013 09:07:20 -0700 (PDT) Received: from blu0-omc1-s2.blu0.hotmail.com (blu0-omc1-s2.blu0.hotmail.com [65.55.116.13]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9411E8142 for ; Wed, 24 Jul 2013 09:07:13 -0700 (PDT) Received: from BLU0-SMTP15 ([65.55.116.7]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Jul 2013 09:07:13 -0700 X-EIP: [crMTf3yWUo0uVMw6HjM1jxFBeg78ArOt] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([70.26.37.98]) by BLU0-SMTP15.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Jul 2013 09:07:09 -0700 From: Paul Coverdale To: "'Christian Groves'" , References: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> <51EF1EA8.3000202@nteczone.com> In-Reply-To: <51EF1EA8.3000202@nteczone.com> Date: Wed, 24 Jul 2013 12:07:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6IBCtqoifQ5ThJRQi3vJj3klPHrAAe290Q Content-Language: en-us X-OriginalArrivalTime: 24 Jul 2013 16:07:09.0976 (UTC) FILETIME=[DA00A180:01CE8887] Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 16:07:26 -0000 It seems to me that this is something best left to the local end to figure out. I would support removing it as a specific requirement. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Christian Groves >Sent: Tuesday, July 23, 2013 8:24 PM >To: clue@ietf.org >Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] > >Hello Mary, > >Another option is that we remove this requirement as its local policy. >The rendering will be more dependent on the actual audio encoding rather >than the CLUE information. > >Regards, Christian > >On 24/07/2013 3:26 AM, Mary Barnes wrote: >> I see two ways to resolve this one. We either change the word >> "render" to something more specific OR define the term "Render" in >> this document. Render is defined in the FW as: >> Render: the process of generating a representation from a media, >> such as displayed motion video or sound emitted from loudspeakers. >> My suggestion to resolve this one is to just change the replace the >> word "render" to something more general. Perhaps changing the >> requirement as follows: >> >> OLD: >> REQMT-3b: The solution MUST enable individual audio >> streams to be rendered in any desired spatial >> position. >> >> NEW: >> REQMT-3b: The solution MUST enable individual audio >> streams to be emitted from a specific speaker >> based on >> spatial information. >> >> Please provide comments on this proposed change no later than August >> 12, 2013. >> >> Thanks, >> Mary. >> >> >> On Tue, Jul 23, 2013 at 10:01 AM, clue issue tracker >> > >> wrote: >> >> #38: OPEN-2 Reference to Rendering [REQMT-3b] >> >> This is the only >> requirement which refers to rendering. It may also be empty, >> since receivers can render audio captures as they wish. >> This is deferred until broader discussion on rendering >> requirements is concluded. >> >> -- >> -------------------------------------+---------------------------- >--------- >> Reporter: | Owner: draft-ietf- >clue- >> mary.ietf.barnes@gmail.com >> | telepresence- >> Type: enhancement | requirements@tools.ietf.org >> >> Priority: major | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: - | Keywords: >> >> -------------------------------------+-------------------------------- >> ----- >> >> Ticket URL: >> clue >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 24 11:38:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2311E80FD for ; Wed, 24 Jul 2013 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5z0paVrp9w9 for ; Wed, 24 Jul 2013 11:38:42 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5592D11E8258 for ; Wed, 24 Jul 2013 11:38:33 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 24 Jul 2013 11:38:32 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Wed, 24 Jul 2013 11:38:30 -0700 Thread-Topic: [clue] draft-ietf-clue-framework-11 Thread-Index: Ac6G7YxkZxaaUNNJRvuYkqG5HLAq2QBr0ftg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE48CB@CRPMBOXPRD07.polycom.com> References: <51ED4B39.1000605@alum.mit.edu> In-Reply-To: <51ED4B39.1000605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] draft-ietf-clue-framework-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: Wed, 24 Jul 2013 18:38:54 -0000 Thanks Paul. I was too quick with the copy and paste on these. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, July 22, 2013 11:10 AM > To: CLUE > Subject: [clue] draft-ietf-clue-framework-11 >=20 > A couple of nits for this version of the draft: >=20 > Section 6.1.1 - definition of Description: >=20 > The definition has been copied from that for Capture Scene. It isn't quit= e > right in this context. It should be: >=20 > "Human-readable description of the Capture," ... >=20 > Section 6.2.2 - definition of Description: >=20 > The definition has been copied from that for Capture Scene. It isn't quit= e > right in this context. It should be: >=20 > "Human-readable description of the Capture Scene Entry," ... >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 24 11:57:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4F021F8436 for ; Wed, 24 Jul 2013 11:57:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlnjhQFTiQhD for ; Wed, 24 Jul 2013 11:57:47 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1482111E812C for ; Wed, 24 Jul 2013 11:57:47 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 24 Jul 2013 11:57:46 -0700 From: "Duckworth, Mark" To: Mary Barnes , "clue@ietf.org" Date: Wed, 24 Jul 2013 11:57:44 -0700 Thread-Topic: [clue] #42: OPEN-6. Multi-view Thread-Index: Ac6H9QDX1tFnPfE2QpeaAsLggO4ZzAAqohPw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE48FF@CRPMBOXPRD07.polycom.com> References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> <092001ce87db$4bb87350$e32959f0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601FE48FFCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 18:57:51 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601FE48FFCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree we can close the issue. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Tuesday, July 23, 2013 6:33 PM To: Stephen Botzko Cc: CLUE; clue issue tracker; draft-ietf-clue-telepresence-requirements@too= ls.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view As I was digging for background on Ticket #41/OPEN-5, I found that we had a= lready discussed this issue and the conclusion as I found in minutes from I= ETF-82: http://www.ietf.org/proceedings/82/minutes/clue.html was consistent with what was presented (chart 5): http://www.ietf.org/proceedings/82/slides/clue-1.pdf "As in Use Case draft, meaning capturing the same field of view from multip= le camera angles We feel it is covered in the above, which specifies the location of the vie= wpoint and the capture area" So, I think we can definitely close this issue. Mary On Tue, Jul 23, 2013 at 3:03 PM, Stephen Botzko > wrote: Section 3.7 describes the case where different cameras are aimed at the sam= e participant, to get different perspectives. Other systems receive and pr= esent the capture that gives the correct eye-contact for the display they c= hose to render it on. The attributes in the framework already allow such captures to be signaled = and selected. What is perhaps missing is a way for all the endpoints to kn= ow their assigned location in the virtual room. I agree with Roni (and the previous mailing list discussion) that this use = case could be used to test extensibility - so no requirements would be need= ed. Steve On Tue, Jul 23, 2013 at 3:31 PM, Roni Even > wrote: Mary, It is in the use cases - section 3.7, still looking back at the mailing lis= t discussion the feeling is this use case is to test extensibility of the C= LUE solution and there would be no specific requirements Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 23 July, 2013 8:36 PM To: clue issue tracker Cc: CLUE; draft-ietf-clue-telepresence-requirements@tools.ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view I propose to just close this issue with the answer being "No". I don't kno= w even what's meant by that term - it's not used in the FW or usecases. If you have any concerns, or you have more info about what this is intended= for, please respond no later than August 12, 2013. Mary. On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker > wrote: #42: OPEN-6. Multi-view Is there a requirement needed? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | = telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_49E45C59CA48264997FEBFB29B6BC2D601FE48FFCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= e can close the issue.

Mar= k

 =

From: clue-bounces@ietf.org [ma= ilto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent:= Tuesday, July 23, 2013 6:33 PM
To: Stephen Botzko
Cc: = CLUE; clue issue tracker; draft-ietf-clue-telepresence-requirements@tools.i= etf.org
Subject: Re: [clue] #42: OPEN-6. Multi-view

 

 

On Tue, Jul 23, 2013 at 3:03 PM, Stephen Botzko <stephen.botzko@gmail.co= m> wrote:

Section 3.7 describes the case where different cameras are aimed at= the same participant, to get different perspectives.  Other systems r= eceive and present the capture that gives the correct eye-contact for the d= isplay they chose to render it on.

The attributes in the framework = already allow such captures to be signaled and selected.  What is perh= aps missing is a way for all the endpoints to know their assigned location = in the virtual room.

I agree with Roni (and the previous mailing li= st discussion) that this use case could be used to test extensibility - so = no requirements would be needed.

Steve

=

On Tue, Jul 23, 2013 at 3:31 PM, Roni Even <ron.even.tlv@gmail.com= > wrote:

Mary,

It is in the use cases – section 3.7, still lookin= g back at the mailing list discussion the feeling is this use case is to te= st extensibility of the CLUE solution and there would be no specific requir= ements

Roni

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 23 Ju= ly, 2013 8:36 PM
To: clue issue tracker
Cc: CLUE; draft-ietf-clue-telepresence-requirements@tools.ietf.org<= br>Subject: Re: [clue] #42: OPEN-6. Multi-view

=

 

I propose to = just close this issue with the answer being "No".  I don't k= now even what's meant by that term - it's not used in the FW or usecases.

 

If you have= any concerns, or you have more info about what this is intended for, pleas= e respond no later than August 12, 2013.

&= nbsp;

Mary.

=

 

On Tue, Jul 23, 2013 at 10:06 AM, clue is= sue tracker <trac+clue@trac.tools.ietf.org> wrote:

#42: OP= EN-6.  Multi-view

 Is there a requirement needed?

-= -
-------------------------------------+--------------------------------= -----
 Reporter:               &= nbsp;           |      Owner:  = ;draft-ietf-clue-
  mary.ietf.barnes@gmail.com        = |  telepresence-
     Type:  enhancement  = ;            |  requirements@tools.ietf.org Priority:  minor             &nbs= p;      |     Status:  new
Component: &nbs= p;telepresence-            |  Milestone:=  milestone1
  requirements          =             |    Version:
 = ;Severity:  Active WG Document       |   Keywords:=
-------------------------------------+---------------------------------= ----

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ti= cket/42>
clue <http://tools.ietf.org/wg/clue/>

 

 

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

 

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D601FE48FFCRPMBOXPRD07pol_-- From christer.holmberg@ericsson.com Wed Jul 24 12:35:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6185E21F9D56 for ; Wed, 24 Jul 2013 12:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2+a9YqWZopv for ; Wed, 24 Jul 2013 12:35:47 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 46E8711E80FC for ; Wed, 24 Jul 2013 12:35:45 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-7f-51f02c8c1e86 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A7.8B.19388.C8C20F15; Wed, 24 Jul 2013 21:35:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 21:35:40 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] Thread-Index: AQHOh8rLMrhzj0FOXU2AVtONJovFoJl0Ol/G Date: Wed, 24 Jul 2013 19:35:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C405C77@ESESSMB209.ericsson.se> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C405C77ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW6PzodAgxvNthb7T11mtvi8fz+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx8c9PtoIZlhVfWx+yNTCuNuhi5OSQEDCR +P3rDzOELSZx4d56ti5GLg4hgcOMEtcbt7NCOEsYJTr7T7F0MXJwsAlYSHT/0wZpEBFwkrjw 8j0LiC0sYCVx49M5NpASEQFriRVt/BAlRhJPH61mArFZBFQlXi5dwwZi8wr4SixZ0Ae1q5tR YufjxWBFnAKBEjsm/gezGYEO+n5qDZjNLCAucevJfCaIQwUkluw5D3W0qMTLx/9YIWryJXo7 p7NCLBCUODnzCcsERuFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKv YmTPTczMSS8338QIjJGDW34b7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanF hxiZODilGhhrJOe9b+erf10nuuC2VIaUV0PJxqgEZv0EJZ9dfPpTS4pf5a54/fX4k0PXDNb5 cXjpXP3UGJdgo7d6/eVlLh/frTr9NumK5d5/URmJfc/fa4q15zhoPM14anZdf92HbE6dHBdW /8vV7/3456/a+2LeD8Zz2m53WKqvmJj52BUsb7mVsXwSv58SS3FGoqEWc1FxIgAmnKtCXwIA AA== Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 19:35:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C405C77ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a concern with removing the requirement at this point. The main reas= on it hasn't been discussed much is because I believe it impacts the signal= ing, rather than the framework. Also, in general, keep in mind that July is a main holiday season in northe= rn Europe, which means many (including myself, and more or less all of my c= olleagues working on telepresence) aren't able to comment at this point. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Mary Barnes [mary.ietf.barnes@gmail.com] To: CLUE [clue@ietf.org] Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] My suggestion is to just remove this requirement. We haven't discussed it = at all in the framework as far as I can tell and it's not in the use cases.= I know we talked about this way, way early on. But, at this point, I thin= k we should consider it out of scope. We have the extensibility requiremen= t, so I think that's sufficient in terms of not precluding additional new b= ehaviors in the future. If you have any concerns about removing this requirement and closing this i= ssue, please respond no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 9:19 AM, clue issue tracker > wrote: #37: OPEN 1: Binaural Audio [REQMT-2C] The need to support of binaural audio is unresolved, and the "MUST NOT preclude" language in this requirement is problematic. The authors believe this requirement needs to be either changed or withdrawn, depending on how the issue is resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | = telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue --_000_7594FB04B1934943A5C02806D1A2204B1C405C77ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a concern with removing the requirement = at this point. The main reason it hasn't been discussed much is because I b= elieve it impacts the signaling, rather than the framework.
 
Also, in general, keep in mind that July i= s a main holiday season in northern Europe, which means many (including mys= elf, and more or less all of my colleagues working on telepresence) aren't = able to comment at this point.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: CLUE [clue@ietf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
My suggestion is to just remove this requirement.  We= haven't discussed it at all in the framework as far as I can tell and it's= not in the use cases.  I know we talked about this way, way early on.= But, at this point, I think we should consider it out of scope.  We have the extensibility requirement, so I think t= hat's sufficient in terms of not precluding additional new behaviors in the= future. 

If you have any concerns about removing this requirement and closing t= his issue, please respond no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:19 AM, clue issue trac= ker <= trac+clue@trac.tools.ietf.org> wrote:
#37: OPEN 1: Binaural Audio [REQMT-2C]

 The need to support of binaural
  audio is unresolved, and the "MUST NOT preclude" language = in
  this requirement is problematic.  The authors believe this
  requirement needs to be either changed or withdrawn,
  depending on how the issue is resolved.

--
-------------------------------------+---------------------------------= ----
 Reporter:                 &nb= sp;         |      Owner:  draft-ie= tf-clue-
  mary.ietf.barnes@gmail= .com         |  telepresence-
     Type:  enhancement         &nb= sp;    |  req= uirements@tools.ietf.org
 Priority:  major              = ;      |     Status:  new
Component:  telepresence-            | &= nbsp;Milestone:  milestone1
  requirements                =       |    Version:
 Severity:  Active WG Document       |   Keyw= ords:
-------------------------------------+---------------------------------= ----

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/37&= gt;
clue <http:= //tools.ietf.org/wg/clue/>


--_000_7594FB04B1934943A5C02806D1A2204B1C405C77ESESSMB209erics_-- From Mark.Duckworth@polycom.com Wed Jul 24 13:11:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4056911E8105 for ; Wed, 24 Jul 2013 13:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpPqSsZU+IDv for ; Wed, 24 Jul 2013 13:11:49 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E53F911E8239 for ; Wed, 24 Jul 2013 13:11:48 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 24 Jul 2013 13:11:48 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Wed, 24 Jul 2013 13:11:46 -0700 Thread-Topic: [clue] draft-duckworth-clue-switching-example-01 Thread-Index: Ac6G/Da+GhaHHtTJTuybWVypsIJrmABo5oaQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE4986@CRPMBOXPRD07.polycom.com> References: <51ED62AA.9060802@alum.mit.edu> In-Reply-To: <51ED62AA.9060802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] draft-duckworth-clue-switching-example-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 20:11:54 -0000 Hi Paul, Thanks very much for the comments! Discussion inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, July 22, 2013 12:50 PM > To: CLUE > Subject: [clue] draft-duckworth-clue-switching-example-01 >=20 > Section 3.2 (Advertising multiple scenes): >=20 > While I understand what you are trying to do, I can't figure out how to m= ake > this approach work in a sensible way. >=20 > What logic would the MCU use to assign actual captures to the switched > captures in the multiple scenes? [Duckworth, Mark] I see it as an extension of what the MCU could do if ther= e was only one scene with a CSE with 3 captures for site switching (just to= use an example). If the most recent talker has 3 cameras, then use those.= If the most recent talker has just 1 camera, then what does the MCU do? = I think the question is fundamentally the same whether there is one simple = scene with 3 captures, one scene with 12 captures in a CSE, or several scen= es each with multiple captures. I think a sensible thing for the MCU to do= is to choose captures form other sites, maybe only the single camera sites= , to fill in the rest of the switched captures that are not used by the mos= t recent talker. > It could use site switching: the site of the most recent speaker in scene= 1, 2nd > most recent speaker in Scene 2, etc. As long as each site has three camer= as > that would work fine. But in the given example that isn't so. If the 2nd = most > recently speaking site only has one capture, and the 3rd most recently > speaking site has three captures, does it leave VC5 and VC6 empty? That > doesn't seem like an ideal choice. [Duckworth, Mark] I expect it would not leave VC5 and VC6 empty. > Or does it back fill? (Put the most recently speaking four sites into Sce= nes > 1...4. Then put the 5th most recently speaking site into the first captur= es in > any of the sites that are still open, etc.) This would *work*, but it wou= ld > violate the idea that the scenes are in priority order.=20 [Duckworth, Mark] Yes, that sounds the same as what I was suggesting above. > So a receiving site that > couldn't take them all might get some lower priority captures while missi= ng > some higher priority ones. [Duckworth, Mark] No, the consumer is getting the captures the consumer ask= ed for. The priority of those switched captures does not change. The MCU i= n this case is deciding which streams belong in the switched captures. The= priority of those switched captures is defined by the MCU. So the MCU is = the one that sets the priority and makes the decisions based on local polic= y. [Duckworth, Mark] Again, I think this issue of how the MCU decides what to = put in switched captures is really the same issue no matter how many captur= e scenes there are, how many captures in a CSE, or what the priority attrib= ute values are. If you think this issue is not really an issue if there is= just one capture scene, can you explain why? > Section 4: >=20 > A consumer that can handle all 12 captures isn't the interesting one to > consider here. More interesting are endpoints E,F,G. Lets consider F: >=20 > It can handle 8 captures: two big and 6 small. Or maybe one big and 12 sm= all. >=20 > The quality of the result depends upon the interaction between how the > advertiser chooses to distribute sites among its advertised captures and = the > choices the consumer makes to distribute those among displays. [Duckworth, Mark] Yes, exactly. draft-hansen-clue-consumer-layout and draf= t-pepperell-clue-switched-attribute suggest a solution for this. That's wh= y I'm suggesting it again. > And it doesn't look like there is enough information to allow the consume= r to do > the best possible job. [Duckworth, Mark] I think "the best possible job" is very subjective and ca= n't be explicitly defined. Different people will have different opinions a= bout what is "best". At this point I'm trying to make sure there is a way = to do what most people would consider a "reasonably good job". > But I think we need to work the examples to see this. >=20 > Section 4.1 (One big scene): >=20 > Issue: If the single screen endpoint wants to show 1 large image and > three PiPs, then it must ask to receive 4 captures. But how could it > ask for one capture that represents the whole scene, plus 3 others > that are additional lower priority, and that the 3 others shouldn't > have a spatial relationship with the one large one? The "Area of > Display" idea would solve this issue. A 2 screen consumer would be > similar to a single screen endpoint, regarding this issue. >=20 > I think your example doesn't support this case. I thought the captures, w= hile > switched, each represented a single camera. I'm not sure what kind of > advertisement would cover what you are questioning. [Duckworth, Mark] I don't follow you, but I'll try to explain my thoughts b= etter. Yes, each switched capture represents a single camera at a time, bu= t which camera that is can be switched fairly frequently by the MCU. Let's= start with the single screen consumer that wants 1 large image to represen= t the highest priority, plus 3 small images of lower priority, and these 3 = small images can be spatially related. If the advertisement is the one in = section 3.2, then the consumer would ask for VC1, VC4, VC5, VC6. With VC1 = being large (high resolution) and the rest small. I think this would work = well. Similarly, a 2 screen consumer would ask for VC1, VC2, VC4, VC5, VC6= , and maybe also VC7, VC8, VC9. A very simple single screen consumer would= ask for VC1. [Duckworth, Mark] But if the advertisement is the one in section 3.1, then = I don't know how the consumer could ask for what it wants. This is where d= raft-hansen-clue-consumer-layout offers a solution. From mary.ietf.barnes@gmail.com Wed Jul 24 16:32:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170B021F9346 for ; Wed, 24 Jul 2013 16:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBnjGhMmwMyU for ; Wed, 24 Jul 2013 16:32:44 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C759C21F9344 for ; Wed, 24 Jul 2013 16:32:43 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so1351317qeb.17 for ; Wed, 24 Jul 2013 16:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVmkgrWSNLnxvju8PbCcJae8ydB7t7EBhQiBrCGzMVw=; b=TwU7yCoB8FsfswUznV2i6UVi5N0s2nvNM51MTWR5c1zsc9QK2itEP39C0VzTf6hNvp zNkA83rfT/jBX+29gEiHTNeOCFPYg+hKDlS8Yoyrm/ZUYjJwtSC9UaMJAwMWhaR5EQAP xI7TfqqG1Babt3LhSRJi+rSu71FIxHJnAziN0GZlkMoV4DQCRELeevD9PhYYZGthGvzO Li1mVQibmvKjgCY6VoHTWnd2jVPVlQyn9/8Qu8DUllYF2jdCIJhNE/BqAKkuWe/W4kPE FAfU456sEDeLTaxmjWZM7P/QMqkQj1GXRR2+XCe2RhQkF5zgunEj8qW6/YLUY93/f1VQ EdYw== MIME-Version: 1.0 X-Received: by 10.229.176.136 with SMTP id be8mr1276833qcb.79.1374708763029; Wed, 24 Jul 2013 16:32:43 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 24 Jul 2013 16:32:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 18:32:42 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c2d90c7d764504e24a53c9 Subject: Re: [clue] CLUE-87 Agenda & Planning X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 23:32:45 -0000 --001a11c2d90c7d764504e24a53c9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have a request and a reminder: 1) For folks that are presenting, please have your charts to the chairs by 5pm (local Berlin) so that we have time to upload and they can be made available for remote participants and Meetecho. 2) As a reminder, there is a doodle for a dinner if folks are interested. Right now we have 6 responses - if others want to join, please respond ASAP as I plan to try to find a place on Saturday and want a fairly accurate headcount. Thanks, Mary. On Thu, Jul 18, 2013 at 10:08 AM, Mary Barnes wrote: > Hi all, > > The agenda for the CLUE WG session is available: > https://datatracker.ietf.org/meeting/87/agenda/clue/ > > Please comment on the agenda now so that we go into the meeting ready to > go. > > Also, there is a doodle for a "CLUE WG Social Dinner": > http://www.doodle.com/fb6kzkxfwk5hrfr9 > > Please respond to the doodle poll if you are interested in dinner no later > than Wednesday, July 24th 24:00 UTC, so that I have some time before the > meeting starts to find a place. > > Regards, > Mary. > --001a11c2d90c7d764504e24a53c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have a request and a reminder= :

1) For folks that are presenting, please have yo= ur charts to the chairs by 5pm (local Berlin) so that we have time to uploa= d and they can be made available for remote participants and Meetecho. =A0<= /div>

2) As a reminder, there is a doodle for a dinner if fol= ks are interested. =A0Right now we have 6 responses - if others want to joi= n, please respond ASAP as I plan to try to find a place on Saturday and wan= t a fairly accurate headcount. =A0 =A0

Thanks,
Mary.=A0


On Thu, Jul 18, 2013 at 10:08 = AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=
Hi all,

= The agenda for the CLUE WG session is available:

Please comment on the = agenda now so that we go into the meeting ready to go. =A0
=
Also, there is a doodle for a=A0"CLUE WG Social Dinner&= quot;:
http://www.doodle.com/fb6kzkxfwk5hrfr9

Please respond to the doodle poll if you a= re interested in dinner no later than Wednesday, July 24th 24:00 UTC, so th= at I have some time before the meeting starts to find a place.

Regar= ds,
Mary.=A0

--001a11c2d90c7d764504e24a53c9-- From mary.ietf.barnes@gmail.com Wed Jul 24 17:02:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A551921F841B for ; Wed, 24 Jul 2013 17:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg3Q4CPM3UE4 for ; Wed, 24 Jul 2013 17:02:34 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F921F85E0 for ; Wed, 24 Jul 2013 17:02:33 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so626131qcx.40 for ; Wed, 24 Jul 2013 17:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OVG0qJ+fTJW+Bd9GgC4BXpbrllStAUJnbtYPDhNT3fU=; b=fgdR3YQgpG7CumJYKcn8VTy//RjSKGlxvkMlp25bJ9Mh/unz5TAqo9u0sZ2zCDXwfg J7S+3M8F109EGNXWZ6g41LOTKYtcVISNn5KNG7+lXOoeDCbRpIOx1qnqtph9Gc1iggNJ ehG2a4kjRKLElgRX2ZqmeLHsGBMXF9y8bGlxrOwHIWBveRdqokDgIIWEA3gAdbUNywfA 4QYGI+60e531hKnrWcx9mNKBbAgvQCvsn1iMI5Q0LYq1pPOum20PXNXxlhiCHzhtPnhM pErk0umE3/hxc5JxN9hVwW/ZXMBcqyGA72GgqNZeGRmAr9XNsc/8yRbjccrFy++2SDzB gGEg== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr13957950qaj.57.1374710552587; Wed, 24 Jul 2013 17:02:32 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 24 Jul 2013 17:02:32 -0700 (PDT) In-Reply-To: <51EF3964.80206@nteczone.com> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <51EF3964.80206@nteczone.com> Date: Wed, 24 Jul 2013 19:02:32 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c3e0e427f3cf04e24abe5c Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 00:02:36 -0000 --001a11c3e0e427f3cf04e24abe5c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian, Additional responses below [MB2]. Thanks, Mary. On Tue, Jul 23, 2013 at 9:18 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > Please see my replies below. > > Regards, Christian > > > On 24/07/2013 4:09 AM, Mary Barnes wrote: > >> Thanks very much for your detailed review and comments with regards to >> whether the REQ is currently supported in the solution. I have a few >> comments below. >> >> Thanks, >> Mary >> As editor for the Requirements do >> >> >> ..snip.. >> >> >> >> REQMT-1d:The solution MUST support a means to identify >> >> the extent of individual video captures in >> >> three dimensions. >> >> [CNG] Partial =96 Capture area attribute allows the specification of >> a plane of capture in 3 dimensions. However depth of the capture >> (needed for a 3D area) is not supported. >> >> [MB] Per my comments on open issue 5 from the requirements document (and >> Ticket # 41 in the tracker), I was proposing we not require 3D in the >> solution at this time. [/MB] >> > > [CNG] 3D is also a requirement in the ITU-T Q5/16 work, although like CLU= E > there has been little technical contribution on it. I've sent an email to > the Q5 list to stimulate input. [MB2] Per my separate email on this issue, I think the issue is closed as there were requirements added specific to 3D: http://www.ietf.org/mail-archive/web/clue/current/msg02763.html I think the proposal/changes made to address the issue are sufficient. [MB2] > > > >> >> >> REQMT-2b:The solution MUST support a means to identify >> >> the number and spatial arrangement of audio >> >> channels including monaural, stereophonic >> >> (2.0), and 3.0 (left, center, right) audio >> >> channels. >> >> [CNG] Partial =96 the Audio Channel Format attribute currently only >> supports =93mono=94 and =93stereo=94. It doesn=92t support the 3.0 f= ormat >> >> >> [MB] So, my question to the group is do we need to support this in the >> current work is is this something that could be extended later. I looked >> fairly quickly but I also could not find a use case for 3.0[/MB] >> > [CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just make > this an integer. So rather "Audio Channel Format" we have a "Number of > audio channels capture" parameter. 1 would indicate single channel (e.g. > mono), 2 would indicate two channels (e.g. stereo), 5 would indicate five > channels (e.g. 5.1). At least this is a future proof way so we don't have > to open up this parameter in the future? [MB2] I think I agree with you. If I understand your proposal, the solution needs to support a number of audio channels. So, we would be okay with this requirement standing since the solution would provide the "means to identify", although the functionality may not necessarily support. Is that correct? [/MB2] > > > >> REQMT-2c:The solution MUST NOT preclude the use of >> >> binaural audio.[Edt. This is an outstanding >> >> issue.Text will be changed when the issue is >> >> resolved.] >> >> [CNG] Partial? =96 Binaural isn=92t mentioned in the framework so >> isn=92t precluded as such. There is no indication in CLUE recording >> a binaural capture. >> >> >> [MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we >> just delete this requirement. [/MB] >> > > [CNG] I believe this is Christer's requirement. I don't have a strong > preference either way. > > >> ..snip.. >> >> >> REQMT-7:The solution MUST support means of enabling >> >> interoperability between telepresence endpoints where >> >> displays are of different resolutions. >> >> [CNG] Supported? =96 CLUE allow encoding parameters to be associated >> with captures which could state the resolution of the captured >> image. However there is no way to indicate =93display=94 resolution. >> Perhaps the requirement needs to be reworded? >> >> >> [MB] Do you have any suggestions for rewording? [/MB] >> > > [CNG] The solution MUST support a means for an endpoint to indicate it's > supported video capture and encoding parameters. A receiving endpoint may > use this information to determine which which video it requires. > [MB2] I like that. [/MB2] > > ..snip.. >> >> >> REQMT-15:The solution MUST support mechanisms for presentations in >> >> such a way that: >> >> *Presentations can have different sources >> >> *Presentations can be seen by all >> >> *There can be variation in placement, number and size of >> >> Presentations >> >> [CNG] Partial =96 CLUE allows an endpoint whether the capture is >> related to a presentation or not through the use of the >> presentation attribute. The spatial attributes (i.e. capture area) >> allows the place and size to be indicated. The number can be >> inferred from the number of captures. CLUE doesn=92t have any policy >> on who can see the presentations. The CLUE Advertisement mechanism >> may include presentation captures to all people within the >> conference. Perhaps the 2^nd bullet can be removed or clarified >> that its not related to policy? >> >> [MB] I'm of a mindset to just remove that 2nd bullet. [/MB] >> > > [CNG] I'm ok with removing it. > >> >> >> ..snip > --001a11c3e0e427f3cf04e24abe5c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Christian,

Additional responses belo= w [MB2].

Thanks,
Mary.


On Tue, Jul 23, 2013 at= 9:18 PM, Christian Groves <Christian.Groves@nteczone.com&= gt; wrote:
Hello Mary,

Please see my replies below.

Regards, Christian


On 24/07/2013 4:09 AM, Mary Barnes wrote:
Thanks very much for your detailed review and comments with regards to whet= her the REQ is currently supported in the solution. =A0I have a few comment= s below.

Thanks,
Mary
As editor for the Requirements do


..snip..



=A0 =A0 REQMT-1d:The solution MUST support a means to identify

=A0 =A0 the extent of individual video captures in

=A0 =A0 three dimensions.

=A0 =A0 [CNG] Partial =96 Capture area attribute allows the specification o= f
=A0 =A0 a plane of capture in 3 dimensions. However depth of the capture =A0 =A0 (needed for a 3D area) is not supported.

[MB] Per my comments on open issue 5 from the requirements document (and Ti= cket # 41 =A0in the tracker), I was proposing we not require 3D in the solu= tion at this time. =A0[/MB]

[CNG] 3D is also a requirement in the ITU-T Q5/16 work, although like CLUE = there has been little technical contribution on it. I've sent an email = to the Q5 list to stimulate input.
=A0
[MB2] Per= my separate email on this issue, I think the issue is closed as there were= requirements added specific to 3D:
http://www.ietf.org/mail-archive/web/clue/current/msg02763.html
I think the proposal/changes made to address the issue are suffici= ent.
[MB2]
=A0





=A0 =A0 REQMT-2b:The solution MUST support a means to identify

=A0 =A0 the number and spatial arrangement of audio

=A0 =A0 channels including monaural, stereophonic

=A0 =A0 (2.0), and 3.0 (left, center, right) audio

=A0 =A0 channels.

=A0 =A0 [CNG] Partial =96 the Audio Channel Format attribute currently only=
=A0 =A0 supports =93mono=94 and =93stereo=94. It doesn=92t support the 3.0 = format


[MB] So, my question to the group is do we need to support this in the curr= ent work is is this something that could be extended later. I looked fairly= quickly but I also could not find a use case for 3.0[/MB]
[CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just make thi= s an integer. So rather "Audio Channel Format" we have a "Nu= mber of audio channels capture" parameter. 1 would indicate single cha= nnel (e.g. mono), 2 would indicate two channels (e.g. stereo), 5 would indi= cate five channels (e.g. 5.1). At least this is a future proof way so we do= n't have to open up this parameter in the future?
[MB2] I think I agree with you. =A0If I understand your proposal, the = solution needs to support a number of audio channels. =A0So, we would be ok= ay with this requirement standing since the solution would provide the &quo= t;means to identify", although the functionality may not necessarily s= upport. =A0Is that correct? [/MB2]



=A0 =A0 REQMT-2c:The solution MUST NOT preclude the use of

=A0 =A0 binaural audio.[Edt. This is an outstanding

=A0 =A0 issue.Text will be changed when the issue is

=A0 =A0 resolved.]

=A0 =A0 [CNG] Partial? =96 Binaural isn=92t mentioned in the framework so =A0 =A0 isn=92t precluded as such. There is no indication in CLUE recording=
=A0 =A0 a binaural capture.


[MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we just= delete this requirement. [/MB]

[CNG] I believe this is Christer's requirement. I don't have a stro= ng preference either way.


=A0 =A0 ..snip..


=A0 =A0 REQMT-7:The solution MUST support means of enabling

=A0 =A0 interoperability between telepresence endpoints where

=A0 =A0 displays are of different resolutions.

=A0 =A0 [CNG] Supported? =96 CLUE allow encoding parameters to be associate= d
=A0 =A0 with captures which could state the resolution of the captured
=A0 =A0 image. However there is no way to indicate =93display=94 resolution= .
=A0 =A0 Perhaps the requirement needs to be reworded?


[MB] Do you have any suggestions for rewording? =A0[/MB]

[CNG] The solution MUST support a means for an endpoint to indicate it'= s supported video capture and encoding parameters. A receiving endpoint may= use this information to determine which which video it requires.
[MB2] I like that. [/MB2]=A0

=A0 =A0 ..snip..


=A0 =A0 REQMT-15:The solution MUST support mechanisms for presentations in<= br>
=A0 =A0 such a way that:

=A0 =A0 *Presentations can have different sources

=A0 =A0 *Presentations can be seen by all

=A0 =A0 *There can be variation in placement, number and size of

=A0 =A0 Presentations

=A0 =A0 [CNG] Partial =96 CLUE allows an endpoint whether the capture is =A0 =A0 related to a presentation or not through the use of the
=A0 =A0 presentation attribute. The spatial attributes (i.e. capture area)<= br> =A0 =A0 allows the place and size to be indicated. The number can be
=A0 =A0 inferred from the number of captures. CLUE doesn=92t have any polic= y
=A0 =A0 on who can see the presentations. The CLUE Advertisement mechanism<= br> =A0 =A0 may include presentation captures to all people within the
=A0 =A0 conference. Perhaps the 2^nd bullet can be removed or clarified
=A0 =A0 that its not related to policy?

[MB] I'm of a mindset to just remove that 2nd bullet. [/MB]

[CNG] I'm ok with removing it.


..snip

--001a11c3e0e427f3cf04e24abe5c-- From mary.ietf.barnes@gmail.com Wed Jul 24 17:06:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF6721F9302 for ; Wed, 24 Jul 2013 17:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwEa4BrylC4N for ; Wed, 24 Jul 2013 17:06:11 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91321F9301 for ; Wed, 24 Jul 2013 17:06:10 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id f6so9801qej.40 for ; Wed, 24 Jul 2013 17:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ci6QLaA4qQDaHALm9pZQ1srsHZg9E+oMoqaPCYi972I=; b=TQiCoxNCp7HRv5CZH32bbC+BHaoVwbMKFw/mAs5LBmBUhfAuFl3X1fpDHausLMCQMA yd9GlKlu/XCt0lpbcrrLMAwWyD3LDk+346REcu+8FHV9hpNcvluZFDCKLlkSGbdSiVkk 8mhzbkAFJK6XZZo0yYDbYTqM0DrVqqUSVCF4mnmIZYspzhU/NKRc2iybNWbLUty0Yu1l nVbkrxmUZHeQYZSBAzb6gE9DSB8WXjohZIU0zi9zy+l8iXTB98mxRK81UBEY3ijM2rQz Ax+ylEZwxOiPUHvxBAPLFvNrHGGzJ4/ATyiGe5FvxZmxKGRTMt7wiIisuVEfjprm2jUO eyEQ== MIME-Version: 1.0 X-Received: by 10.49.128.42 with SMTP id nl10mr26351274qeb.6.1374710769818; Wed, 24 Jul 2013 17:06:09 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 24 Jul 2013 17:06:09 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C405C77@ESESSMB209.ericsson.se> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> <7594FB04B1934943A5C02806D1A2204B1C405C77@ESESSMB209.ericsson.se> Date: Wed, 24 Jul 2013 19:06:09 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b6779e81aa2e904e24acbbf Cc: CLUE Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 00:06:12 -0000 --047d7b6779e81aa2e904e24acbbf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 24, 2013 at 2:35 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I have a concern with removing the requirement at this point. The main > reason it hasn't been discussed much is because I believe it impacts the > signaling, rather than the framework. > [MB] So, what is your use case. Can you point to a use case in the WG use case document? My personal opinion is that this is something that could be added later with extensions - I don't see this as a primary requirement for CLUE. [/MB] > > Also, in general, keep in mind that July is a main holiday season in > northern Europe, which means many (including myself, and more or less all > of my colleagues working on telepresence) aren't able to comment at this > point. > [MB] That's why the deadline for comments for these issues is August 12th. In the US, there's always someone that is away at any given period during the summer. We can't shutdown the WG because folks are on holiday. We can extend deadlines, which was done for these comments. And, given that none of these issues are new at all, folks have had plenty of time to read the document at other times and provide comments. [/MB] > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Mary Barnes [mary.ietf.barnes@gmail.com] > *To:* CLUE [clue@ietf.org] > *Subject:* Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] > My suggestion is to just remove this requirement. We haven't discussed it > at all in the framework as far as I can tell and it's not in the use cases. > I know we talked about this way, way early on. But, at this point, I think > we should consider it out of scope. We have the extensibility requirement, > so I think that's sufficient in terms of not precluding additional new > behaviors in the future. > > If you have any concerns about removing this requirement and closing > this issue, please respond no later than August 12, 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 9:19 AM, clue issue tracker < > trac+clue@trac.tools.ietf.org> wrote: > >> #37: OPEN 1: Binaural Audio [REQMT-2C] >> >> The need to support of binaural >> audio is unresolved, and the "MUST NOT preclude" language in >> this requirement is problematic. The authors believe this >> requirement needs to be either changed or withdrawn, >> depending on how the issue is resolved. >> >> -- >> >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com | telepresence- >> Type: enhancement | requirements@tools.ietf.org >> Priority: major | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> clue >> >> > --047d7b6779e81aa2e904e24acbbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 24, 2013 at 2:35 PM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
=A0
I have a concern with removing the requirement = at this point. The main reason it hasn't been discussed much is because= I believe it impacts the signaling, rather than the framework.
[MB] =A0So, what is your use case. =A0Can you point= to a use case in the WG use case document? =A0My personal opinion is that = this is something that could be added later with extensions - I don't s= ee this as a primary requirement for CLUE. =A0[/MB]=A0
=A0
Also, in general,=A0keep in mind that July is a= main holiday season in northern Europe, which means many (including myself= , and more or less all of my colleagues working on telepresence) aren't= able to comment at this point.
[MB] That's why the deadline for comments for t= hese issues is August 12th. =A0In the US, there's always someone that i= s away at any given period during the summer. =A0We can't shutdown the = WG because folks are on holiday. =A0We can extend deadlines, which was done= for these comments. =A0And, given that none of these issues are new at all= , folks have had plenty of time to read the document at other times and pro= vide comments. [/MB]
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: CLUE [clue@ie= tf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
My suggestion is to just remove this requirement. =A0We ha= ven't discussed it at all in the framework as far as I can tell and it&= #39;s not in the use cases. =A0I know we talked about this way, way early o= n. But, at this point, I think we should consider it out of scope. =A0We have the extensibility requirement, so I think that= 's sufficient in terms of not precluding additional new behaviors in th= e future.=A0

If you have any concerns about removing this requirement and closing t= his issue, please respond no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:19 AM, clue issue trac= ker <trac= +clue@trac.tools.ietf.org> wrote:
#37: OPEN 1: Binaural Audio [REQMT-2C]

=A0The need to support of binaural
=A0 audio is unresolved, and the "MUST NOT preclude" language in<= br> =A0 this requirement is problematic. =A0The authors believe this
=A0 requirement needs to be either changed or withdrawn,
=A0 depending on how the issue is resolved.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ie= tf.barnes@gmail.com =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ie= tf.org
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/37&= gt;
clue <http:= //tools.ietf.org/wg/clue/>



--047d7b6779e81aa2e904e24acbbf-- From Christian.Groves@nteczone.com Wed Jul 24 17:17:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE0C21F98AD for ; Wed, 24 Jul 2013 17:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSMkiNu5-JAN for ; Wed, 24 Jul 2013 17:17:52 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D721F9829 for ; Wed, 24 Jul 2013 17:17:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGZt8FF20Thy/2dsb2JhbAANRAq+coJ9gSyDGAEBAQQyAQUbJQEQCxgJFg8JAwIBAgFFBg0BBwEBF68/kjyORIE5B4QAA6xS Received: from ppp118-209-56-114.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.56.114]) by ipmail05.adl6.internode.on.net with ESMTP; 25 Jul 2013 09:47:50 +0930 Message-ID: <51F06EA8.8000302@nteczone.com> Date: Thu, 25 Jul 2013 10:17:44 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mary Barnes References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <51EF3964.80206@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 00:17:53 -0000 Hello Mary, Please see below. Regards, Christian On 25/07/2013 10:02 AM, Mary Barnes wrote: > Hi Christian, > > Additional responses below [MB2]. > > Thanks, > Mary. > ..snip.. > > > REQMT-2b:The solution MUST support a means to identify > > the number and spatial arrangement of audio > > channels including monaural, stereophonic > > (2.0), and 3.0 (left, center, right) audio > > channels. > > [CNG] Partial the Audio Channel Format attribute > currently only > supports 搈ono and 搒tereo. It doesn抰 support the 3.0 > format > > > [MB] So, my question to the group is do we need to support > this in the current work is is this something that could be > extended later. I looked fairly quickly but I also could not > find a use case for 3.0[/MB] > > [CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just > make this an integer. So rather "Audio Channel Format" we have a > "Number of audio channels capture" parameter. 1 would indicate > single channel (e.g. mono), 2 would indicate two channels (e.g. > stereo), 5 would indicate five channels (e.g. 5.1). At least this > is a future proof way so we don't have to open up this parameter > in the future? > > [MB2] I think I agree with you. If I understand your proposal, the > solution needs to support a number of audio channels. So, we would be > okay with this requirement standing since the solution would provide > the "means to identify", although the functionality may not > necessarily support. Is that correct? [/MB2] [CNG] Yes although I'm not sure what the significance of "since the solution would provide the "means to identify", although the functionality may not necessarily support" is? Like all the attributes/values a endpoint isn't required to support them. > From christer.holmberg@ericsson.com Thu Jul 25 00:01:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F208421F99F3 for ; Thu, 25 Jul 2013 00:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-1.927, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB9+7grURS-J for ; Thu, 25 Jul 2013 00:01:09 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C01B021F99D7 for ; Thu, 25 Jul 2013 00:01:08 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-04-51f0cd339f08 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 69.F6.11907.33DC0F15; Thu, 25 Jul 2013 09:01:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 09:01:07 +0200 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] Thread-Index: AQHOh8rLMrhzj0FOXU2AVtONJovFoJl0Ol/GgAAqC4CAAJV4hQ== Date: Thu, 25 Jul 2013 07:01:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C408993@ESESSMB209.ericsson.se> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> <7594FB04B1934943A5C02806D1A2204B1C405C77@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C408993ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7x2Q+BBqfPK1vsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG+vO3WQq2xVTsP3aCtYGx06+LkZNDQsBE onf/ajYIW0ziwr31YLaQwFFGia0rqyHsJYwSHf2+XYwcHGwCFhLd/7RBwiICOhLfPr8FK2cW kJBYdfEDI4gtLGAlcePTOTaQchEBa4kVbfwQppPE9xdWIBUsAqoSUy/0soDYvAK+Eu+avjJ3 MXIBLZrGJHFy/T52kHpOgUCJ2xttQWoYgQ77fmoNE8QmcYlbT+YzQRwsILFkz3lmCFtU4uXj f6wQNfkSE/4eYIeYLyhxcuYTlgmMIrOQtM9CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/ DrEgiy9gZF/FyFGcWpyUm25ksIkRGDUHt/y22MF4+a/NIUZpDhYlcd4temcChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAeZBY9Oe/eyg853+4sk0y/rq3c5JBksaVjfuWL7c2XE8rXCP1K F98UWVRlzPtGdU7UPTYxkf/G8SwX7E8uN2r9N4fp1enwWl+zsrL27MjpHyK9s2fIF0yW3Rzo cstiSUb4bp2Xm5jYTv24vttq1/5oGQflNRlK4rcdtz19nXDevF7VQ+ufdaMSS3FGoqEWc1Fx IgCIHAuXaAIAAA== Cc: CLUE Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 07:01:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C408993ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am sure use-cases were discussed at the time, but they may not have been = documented in the draft. Anyway, let's get back to this later. Also, I am not asking anyone to shut down the WG, but I think we are allowe= d to remove requirements etc also at other times than during the summer vac= ation months... :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Mary Barnes [mary.ietf.barnes@gmail.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: CLUE [clue@ietf.org] Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] On Wed, Jul 24, 2013 at 2:35 PM, Christer Holmberg > wrote: Hi, I have a concern with removing the requirement at this point. The main reas= on it hasn't been discussed much is because I believe it impacts the signal= ing, rather than the framework. [MB] So, what is your use case. Can you point to a use case in the WG use= case document? My personal opinion is that this is something that could b= e added later with extensions - I don't see this as a primary requirement f= or CLUE. [/MB] Also, in general, keep in mind that July is a main holiday season in northe= rn Europe, which means many (including myself, and more or less all of my c= olleagues working on telepresence) aren't able to comment at this point. [MB] That's why the deadline for comments for these issues is August 12th. = In the US, there's always someone that is away at any given period during = the summer. We can't shutdown the WG because folks are on holiday. We can= extend deadlines, which was done for these comments. And, given that none= of these issues are new at all, folks have had plenty of time to read the = document at other times and provide comments. [/MB] Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Mary Barnes [mary.ietf.barnes@gmail.com] To: CLUE [clue@ietf.org] Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] My suggestion is to just remove this requirement. We haven't discussed it = at all in the framework as far as I can tell and it's not in the use cases.= I know we talked about this way, way early on. But, at this point, I thin= k we should consider it out of scope. We have the extensibility requiremen= t, so I think that's sufficient in terms of not precluding additional new b= ehaviors in the future. If you have any concerns about removing this requirement and closing this i= ssue, please respond no later than August 12, 2013. Thanks, Mary. On Tue, Jul 23, 2013 at 9:19 AM, clue issue tracker > wrote: #37: OPEN 1: Binaural Audio [REQMT-2C] The need to support of binaural audio is unresolved, and the "MUST NOT preclude" language in this requirement is problematic. The authors believe this requirement needs to be either changed or withdrawn, depending on how the issue is resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | = telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: new Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue --_000_7594FB04B1934943A5C02806D1A2204B1C408993ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am sure use-cases were discussed at the time,= but they may not have been documented in the draft. Anyway, let's get back= to this later.
 
Also, I am not asking anyone to shut down the WG, but I think we are a= llowed to remove requirements etc also at other times than during the summe= r vacation months... :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: CLUE [clue@ietf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
On Wed, Jul 24, 2013 at 2:35 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,
 
I have a concern with removing the requirement = at this point. The main reason it hasn't been discussed much is because I b= elieve it impacts the signaling, rather than the framework.
[MB]  So, what is your use case.  Can you point to a use cas= e in the WG use case document?  My personal opinion is that this is so= mething that could be added later with extensions - I don't see this as a p= rimary requirement for CLUE.  [/MB] 
 
Also, in general, keep in mind that July i= s a main holiday season in northern Europe, which means many (including mys= elf, and more or less all of my colleagues working on telepresence) aren't = able to comment at this point.
[MB] That's why the deadline for comments for these issues is August 1= 2th.  In the US, there's always someone that is away at any given peri= od during the summer.  We can't shutdown the WG because folks are on h= oliday.  We can extend deadlines, which was done for these comments.  And, given that none of these issues are ne= w at all, folks have had plenty of time to read the document at other times= and provide comments. [/MB]
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: CLUE [clue@ie= tf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
My suggestion is to just remove this requirement.  We= haven't discussed it at all in the framework as far as I can tell and it's= not in the use cases.  I know we talked about this way, way early on.= But, at this point, I think we should consider it out of scope.  We have the extensibility requirement, so I think t= hat's sufficient in terms of not precluding additional new behaviors in the= future. 

If you have any concerns about removing this requirement and closing t= his issue, please respond no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:19 AM, clue issue trac= ker <= trac+clue@trac.tools.ietf.org> wrote:
#37: OPEN 1: Binaural Audio [REQMT-2C]

 The need to support of binaural
  audio is unresolved, and the "MUST NOT preclude" language = in
  this requirement is problematic.  The authors believe this
  requirement needs to be either changed or withdrawn,
  depending on how the issue is resolved.

--
-------------------------------------+---------------------------------= ----
 Reporter:                 &nb= sp;         |      Owner:  draft-ie= tf-clue-
  mary= .ietf.barnes@gmail.com         |  telepresence= -
     Type:  enhancement         &nb= sp;    |  requirements@tools.ietf.org
 Priority:  major              = ;      |     Status:  new
Component:  telepresence-            | &= nbsp;Milestone:  milestone1
  requirements                =       |    Version:
 Severity:  Active WG Document       |   Keyw= ords:
-------------------------------------+---------------------------------= ----

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/37&= gt;
clue <http:= //tools.ietf.org/wg/clue/>



--_000_7594FB04B1934943A5C02806D1A2204B1C408993ESESSMB209erics_-- From ron.even.tlv@gmail.com Thu Jul 25 02:09:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53E21F99A1 for ; Thu, 25 Jul 2013 02:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LiH5N0oV38a for ; Thu, 25 Jul 2013 02:09:06 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id EB6AC21F85E8 for ; Thu, 25 Jul 2013 02:09:05 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id b57so765454eek.8 for ; Thu, 25 Jul 2013 02:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=37H2PNlAKI6/dQPRnqSwkT+73PVhfegR80jzMbZOhwk=; b=ZqI5U+yR2CXU7JV6I1x4Yh071jc70L/eeTUdeAKOZ2UgwTldMny7rPOyLCHqktPdBF +e1QN6E3C7A+/29Z0/5lKHDy0lMDUgFH7YQ4TK+xzszvSY560n0YbiA37Li/7ZTTh2pK fo4kuh6JaAjBrMOB12Jx0KDrm1mrOx5tBXqSqUXikJ1FgzUeSIMM/M2o1QkZuhk3NsiQ SO1HOtDTENip50SK+CHeGRnszaIxSSBeP+OtH0ePnOMJu2U7GnNiItIpB6jFq+hhMwqo /+THQjGOHy/bI9R3MKy2Ct2jnxUozEzWNVlkCUKC1kH9o59w+25FyhN8nJMdiUr2gYxC +kAA== X-Received: by 10.14.176.68 with SMTP id a44mr41828846eem.31.1374743345033; Thu, 25 Jul 2013 02:09:05 -0700 (PDT) Received: from RoniE (bzq-109-67-165-48.red.bezeqint.net. [109.67.165.48]) by mx.google.com with ESMTPSA id c3sm72188736eev.3.2013.07.25.02.09.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 02:09:03 -0700 (PDT) From: "Roni Even" To: "'Roberta Presta'" , References: <5153979E.1010106@nteczone.com> <515A2F8F.1020507@nteczone.com> <515C6548.1020807@unina.it> In-Reply-To: <515C6548.1020807@unina.it> Date: Thu, 25 Jul 2013 12:07:05 +0300 Message-ID: <002401ce8916$5741f7f0$05c5e7d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+eiZrgRq3W36iCBgT2uojWxZc0QNBzs6tAqQpwqEBuaqpmpnYOjkA Content-Language: en-us Subject: Re: [clue] Capture ID scope in a Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 09:09:07 -0000 Hi Roberta, In the capture encoding type there is a mediaCaptureID looking at you example on configure it looks like it should have been captureIDREF element. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roberta Presta > Sent: 03 April, 2013 8:22 PM > To: clue@ietf.org > Subject: Re: [clue] Capture ID scope in a Configure > > Hi all, > > it seems to me that capture scenes and capture scene entries are semantical > abstractions that are useful only to make a media provider able to show the > organization of the available media captures to the media consumer via an > advertisement message. > I don't believe they should be used within a configure message. > The media consumer should specify only *capture encodings*, i.e., the > associations of a media capture with an individual encoding with the desired > parameters. > If the media consumer wants both VC1 encoded with ENC0 and VC1 encoded > with ENC1, he should put in the configure message the specification of two > capture encodings. > > VC1... > ENC1... > ... > If he wants all the captures within a capture scene, he should specify in the > configure a capture encoding for each capture of the scene, since he should > be forced to associate a desired encoding to each desired capture. > Do you think this interpretation is correct? > > Thanks, > > Roberta > > > > > > Il 02/04/2013 03:08, Christian Groves ha scritto: > > > > > >> The "multiple encodings" aspect of media captures is designed to be > >> orthogonal to media captures' presence in one or more CSEs - it may > >> be valid to receive multiple encodings of a media capture even if it > >> were present in just one capture scene or capture scene entry, for > >> instance, and on the flip side, depending on the provider's > >> advertisement, it may only be possible to receive a single encodings > >> of a media capture which appears in multiple capture scene entries. > > [CNG] I agree that the encodings is designed to be orthogonal but I > > think that perhaps there needs to be a tie between then encoding and > > the CSE/CaptureID. For example: as a provider I can see the case where > > it offer CSE1,CaptureID1 which uses a high quality encoding or > > CSE2,CaptureID1,CaptureID2 which uses a lower quality encoding. > > Currently we have a link between the CaptureID and encoding. How does > > it relate a CSE to a particular encoding instance when the CaptureID > > is the same? > >> > >> >Now if a Consumer sends a configure in response wanting Scene 1 CSE > >> 1 and Scene 2 CSE 1 how does it respond? > >> > >> To my mind, the phrasing is slightly misleading here in that it could > >> be said that the Consumer doesn't really want "Scene 1 CSE 1" and > >> "Scene 2 CSE 1" but in fact wants a single encoding or multiple > >> encodings of the more fundamental "VC1", which it can put to whatever > >> use, post decoding, that it chooses. > > [CNG] OK. > >> > >> >a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > >> > >> That's what I believe to be the answer to your question. As per the > >> above, if it has multiple "uses" for VC1, perhaps a very high quality > >> encoding to switch out to certain other consumers and a lower quality > >> version to transcode (if it's a middle box, for instance) it may > >> choose to use more than one of the provider's Individual Encodings > >> for VC1, but fundamentally this can be considered orthogonal to the > >> choice of which media captures are needed, or the reason, based on > >> their CSE membership, why those media captures are being requested. > > [CNG] Can it be completely orthogonal if a CSE is constructed based on > > some encoding considerations? > >> > >> >In response to the Configure what does the Provider do? The consumer > >> has indicated it wants two scenes and there's a duplicate of VC1. > >> Should the provider send the SDP to establish only one RTP stream for > >> VC1 or should it setup two RTP streams one for each scene? > >> > >> The idea behind the Encoding Group and Individual Encoding concepts > >> was that the provider can be fairly dumb here, and need to take no > >> view or action explicitly based on the "duplication" of VC1. SDP / > >> RTP relationships should be made according to the encoding > >> configuration, mostly determined by the consumer's configuration > >> message. One RTP stream per configured encoding would seem fairly > >> straightforward, but the multiplexing relationship of those streams > >> with respect to "m lines", SSRCs, multiplex IDs within RTP extension > >> headers hasn't, to my knowledge, been completely thrashed out to > >> everyone's satisfaction as yet (though I am forced to confess to a > >> certain amount of ignorance as to the latest state of this discussion). > >> > >> Regards, > >> > >> Andy > >> > >> > >> On Thu, Mar 28, 2013 at 1:06 AM, Christian Groves > >> >> > wrote: > >> > >> Hello, > >> > >> >From the framework it seems that it is assumed CaptureIDs are > >> unique in an Advertisement and the same CaptureID can be used in > >> multiple scenes and CSEs. A captureID may have multiple encodings. > >> > >> I.e. > >> Advertisement > >> VC1 (capture attributes 1) > >> VC2 (capture attributes 2) > >> VC3 (capture attributes 3) > >> VC4 (capture attributes 4) > >> Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) > >> Scene 2 (CSE1(VC1,VC4)) > >> > >> Now if a Consumer sends a configure in response wanting Scene 1 > >> CSE 1 and Scene 2 CSE 1 how does it respond? > >> a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > >> b) Does it include the complete reference? i.e. > >> Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4)) > >> c) Both? > >> d) ? > >> > >> In response to the Configure what does the Provider do? The > >> consumer has indicated it wants two scenes and there's a duplicate > >> of VC1. Should the provider send the SDP to establish only one RTP > >> stream for VC1 or should it setup two RTP streams one for each > >> scene? > >> > >> Any thoughts? > >> > >> Regards, Christian > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > -- > Roberta Presta, Ph.D. Student > Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione > (DIETI) Universita' degli Studi di Napoli "Federico II" > Via Claudio 21 -- 80125 Napoli (Italy) > Phone: +390817683821 - Fax: +390817683816 > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Jul 25 09:04:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE421F969F for ; Thu, 25 Jul 2013 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5zED-7XX71u for ; Thu, 25 Jul 2013 09:04:16 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0F21F941F for ; Thu, 25 Jul 2013 09:04:15 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta07.westchester.pa.mail.comcast.net with comcast id 4at71m0021wpRvQ57g4F5M; Thu, 25 Jul 2013 16:04:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 4g4E1m01P3ZTu2S3eg4ERE; Thu, 25 Jul 2013 16:04:15 +0000 Message-ID: <51F14C7E.7010604@alum.mit.edu> Date: Thu, 25 Jul 2013 12:04:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Duckworth, Mark" References: <51ED62AA.9060802@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4986@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601FE4986@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374768255; bh=iAEeL9CTOim5LW9FHLZWpEvpgWlYFxSkegZEnw/qydw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mfdysxtjl/Q99mFbpx/TVngRuqsDpiJcZG8NRxYEYOYJrP1ohu3WzZdV2fjviQLmd M8mVcY3b7s5Y2vkKl3pB20bMvnH0kcnPw8RB1PhbpdmyNe8qFlQ3eARdZop0VEDROh pDKZyuC3WVLZ3sL71zPXHK+h9JBDEYehegkMbaZB7IRbtogzBVmXnOFvHaNShSnWp9 2r8Vo02sty2Ly8XiCBSYnyX5rAc9uPu/WspQiD8aEu44oUmoHsetHM38oPNQlnSlzZ xS4UDo5qK24ignaK8RjOlVvrGNbWfx4E+ZSUuectcavNoZR8uU5dtAN7QIF9QVz/6L 0WbXCnBL71WTw== Cc: CLUE Subject: Re: [clue] draft-duckworth-clue-switching-example-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 16:04:22 -0000 Mark, More inline. There are some nasty problems here. This is hard! On 7/24/13 4:11 PM, Duckworth, Mark wrote: > Hi Paul, > > Thanks very much for the comments! > > Discussion inline. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, July 22, 2013 12:50 PM >> To: CLUE >> Subject: [clue] draft-duckworth-clue-switching-example-01 >> >> Section 3.2 (Advertising multiple scenes): >> >> While I understand what you are trying to do, I can't figure out how to make >> this approach work in a sensible way. >> >> What logic would the MCU use to assign actual captures to the switched >> captures in the multiple scenes? > > [Duckworth, Mark] I see it as an extension of what the MCU could do if there was only one scene with a CSE with 3 captures for site switching (just to use an example). If the most recent talker has 3 cameras, then use those. If the most recent talker has just 1 camera, then what does the MCU do? I think the question is fundamentally the same whether there is one simple scene with 3 captures, one scene with 12 captures in a CSE, or several scenes each with multiple captures. I think a sensible thing for the MCU to do is to choose captures form other sites, maybe only the single camera sites, to fill in the rest of the switched captures that are not used by the most recent talker. > >> It could use site switching: the site of the most recent speaker in scene 1, 2nd >> most recent speaker in Scene 2, etc. As long as each site has three cameras >> that would work fine. But in the given example that isn't so. If the 2nd most >> recently speaking site only has one capture, and the 3rd most recently >> speaking site has three captures, does it leave VC5 and VC6 empty? That >> doesn't seem like an ideal choice. > > [Duckworth, Mark] I expect it would not leave VC5 and VC6 empty. I agree. >> Or does it back fill? (Put the most recently speaking four sites into Scenes >> 1...4. Then put the 5th most recently speaking site into the first captures in >> any of the sites that are still open, etc.) This would *work*, but it would >> violate the idea that the scenes are in priority order. > > [Duckworth, Mark] Yes, that sounds the same as what I was suggesting above. > >> So a receiving site that >> couldn't take them all might get some lower priority captures while missing >> some higher priority ones. > > [Duckworth, Mark] No, the consumer is getting the captures the consumer asked for. The priority of those switched captures does not change. The MCU in this case is deciding which streams belong in the switched captures. The priority of those switched captures is defined by the MCU. So the MCU is the one that sets the priority and makes the decisions based on local policy. Maybe we are thinking of this differently. My thinking is that the definition of the content of each capture in the advertisement is fixed at the time the advertisement is sent. So the configuration of which captures are to be received does not alter that. Of course that is tricky for switched captures, especially site-switched. I think it can only be defined by an algorithm. But it could be defined by an algorithm such as the one I described above. (I'm not implying that the algorithm needs to be standardized, or even advertised, except in the most general terms.) And of course the captures have their priorities fixed in the advertisement. So we presume that those with higher priority are more important to receive. I'll also presume that more recent speakers, (or sites containing more recent speakers) are more important to receive that less recent ones. So ideally the captures containing the more recent ones should be the captures with the highest priority. But trying to preserve spatial relationships seems to result in assigning some sites into captures with lower priority that their desired priority order. I *think* you are suggesting that this would be fixed by doing the switching assignment to captures based on what captures have been configured, rather than only based on the advertisement. Now maybe that is ok. But it makes it a real challenge to come up with a good definition of what a switched capture is, that makes it possible to make a good choice of what to configure. > [Duckworth, Mark] Again, I think this issue of how the MCU decides what to put in switched captures is really the same issue no matter how many capture scenes there are, how many captures in a CSE, or what the priority attribute values are. If you think this issue is not really an issue if there is just one capture scene, can you explain why? The constraints on the spatial relationships in a single scene make it simpler, at the expense of doing a poorer job of preserving spatial relationships. It may be that we have simply tried to tackle an intractable problem. So far I haven't seen a solution proposed that can do a good job in cases where the rooms have significantly different arrangements. >> Section 4: >> >> A consumer that can handle all 12 captures isn't the interesting one to >> consider here. More interesting are endpoints E,F,G. Lets consider F: >> >> It can handle 8 captures: two big and 6 small. Or maybe one big and 12 small. >> >> The quality of the result depends upon the interaction between how the >> advertiser chooses to distribute sites among its advertised captures and the >> choices the consumer makes to distribute those among displays. > > [Duckworth, Mark] Yes, exactly. draft-hansen-clue-consumer-layout and draft-pepperell-clue-switched-attribute suggest a solution for this. That's why I'm suggesting it again. Yes. The essence of these is that the consumer describes the rendering capabilities and the provider then chooses what to send that will best portray what the advertiser has available. This is certainly a possible approach. But IMO it is a radical departure from the current model where the advertiser describes what is available, and the consumer chooses what it wants and how to best render what it has chosen. I could see choosing either extreme. But it gets messy if we choose some halfway point between the two extremes. And that is what seems to have been proposed. Again, this is *possible*, but it gets messy. Either extreme has tradeoffs: - for our current approach, we are limited by how much the consumer knows about what it is choosing. The advertiser knows more, but we have chosen to limit how much is make available to the consumer, in order to keep things simple. - for the "provider makes it right" approach, the provider has all the info about the sources. But then it is limited by what it knows about the consumer. The details about this haven't been worked out in great detail. But I think they will be difficult to describe thoroughly. In any case, it seems to me that this is a difficult and important subject. If we get it wrong the result may be that the CLUE is found to be unusable. >> And it doesn't look like there is enough information to allow the consumer to do >> the best possible job. > > [Duckworth, Mark] I think "the best possible job" is very subjective and can't be explicitly defined. Different people will have different opinions about what is "best". At this point I'm trying to make sure there is a way to do what most people would consider a "reasonably good job". Agreed. Perhaps we should set some metrics for this. E.g., - that it should produce the ideal result when all sites are identical - set low, but attainable, goals for radically dissimilar sites. >> But I think we need to work the examples to see this. >> >> Section 4.1 (One big scene): >> >> Issue: If the single screen endpoint wants to show 1 large image and >> three PiPs, then it must ask to receive 4 captures. But how could it >> ask for one capture that represents the whole scene, plus 3 others >> that are additional lower priority, and that the 3 others shouldn't >> have a spatial relationship with the one large one? The "Area of >> Display" idea would solve this issue. A 2 screen consumer would be >> similar to a single screen endpoint, regarding this issue. >> >> I think your example doesn't support this case. I thought the captures, while >> switched, each represented a single camera. I'm not sure what kind of >> advertisement would cover what you are questioning. > > [Duckworth, Mark] I don't follow you, but I'll try to explain my thoughts better. Yes, each switched capture represents a single camera at a time, but which camera that is can be switched fairly frequently by the MCU. Let's start with the single screen consumer that wants 1 large image to represent the highest priority, plus 3 small images of lower priority, and these 3 small images can be spatially related. If the advertisement is the one in section 3.2, then the consumer would ask for VC1, VC4, VC5, VC6. With VC1 being large (high resolution) and the rest small. I think this would work well. This goes back to my question about whether the mappings are fixed with the advertisement, or dependent upon what is configured. I would expect that VC1 would contain the current talker. If the 2nd most recent talker was from a different site with three cameras, then VC4..6 would contain that site, which would be ok. But if the current talker came from a site with only one camera, and the 2nd most recent talker came from a site with 1 or 2 cameras, then it is unclear that the 2nd most recent talking site will be mapped to VC4..6 - it might be mapped to VC2..3. So the mapping algorithm must be very well understood by both ends in order to for this selection to work well. Again, this just points to a need be very precise about what we mean by site switching. > Similarly, a 2 screen consumer would ask for VC1, VC2, VC4, VC5, VC6, and maybe also VC7, VC8, VC9. A very simple single screen consumer would ask for VC1. I'm not going to discuss this case until we understand the prior one. > [Duckworth, Mark] But if the advertisement is the one in section 3.1, then I don't know how the consumer could ask for what it wants. This is where draft-hansen-clue-consumer-layout offers a solution. Agreed. Thanks, Paul From Mark.Duckworth@polycom.com Thu Jul 25 12:06:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04A21F93F8 for ; Thu, 25 Jul 2013 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMY26VOtiOxE for ; Thu, 25 Jul 2013 12:06:14 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id DFBF821F85D1 for ; Thu, 25 Jul 2013 12:06:13 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 25 Jul 2013 12:06:13 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Thu, 25 Jul 2013 12:06:10 -0700 Thread-Topic: [clue] draft-duckworth-clue-switching-example-01 Thread-Index: Ac6JUKBA47EphaoxQHi6F6wvIOBAjQAEY7ww Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE4DD9@CRPMBOXPRD07.polycom.com> References: <51ED62AA.9060802@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4986@CRPMBOXPRD07.polycom.com> <51F14C7E.7010604@alum.mit.edu> In-Reply-To: <51F14C7E.7010604@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] draft-duckworth-clue-switching-example-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 19:06:19 -0000 Hi Paul, Yeah, it's hard, but I think we can come to a "good enough" solution to cov= er basic switched capture use cases. It seems to me we are thinking along = the same lines, for the most part, in the discussion below. Particularly s= ee my suggestion near the end, to see if it avoids some issues you raise. Personally, I now think the scenarios I'm most interested in can be handled= with the framework as is, by using the multiple scenes approach in section= 3.2 of my draft. I was hoping more people would be interested in discussing this on the list= . More inline. Mark > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, July 25, 2013 12:04 PM > To: Duckworth, Mark > Cc: CLUE > Subject: Re: [clue] draft-duckworth-clue-switching-example-01 > > Mark, > > More inline. There are some nasty problems here. This is hard! > > On 7/24/13 4:11 PM, Duckworth, Mark wrote: > > Hi Paul, > > > > Thanks very much for the comments! > > > > Discussion inline. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Monday, July 22, 2013 12:50 PM > >> To: CLUE > >> Subject: [clue] draft-duckworth-clue-switching-example-01 > >> > >> Section 3.2 (Advertising multiple scenes): > >> > >> While I understand what you are trying to do, I can't figure out how > >> to make this approach work in a sensible way. > >> > >> What logic would the MCU use to assign actual captures to the > >> switched captures in the multiple scenes? > > > > [Duckworth, Mark] I see it as an extension of what the MCU could do if > there was only one scene with a CSE with 3 captures for site switching (j= ust to > use an example). If the most recent talker has 3 cameras, then use those= . If > the most recent talker has just 1 camera, then what does the MCU do? I > think the question is fundamentally the same whether there is one simple > scene with 3 captures, one scene with 12 captures in a CSE, or several sc= enes > each with multiple captures. I think a sensible thing for the MCU to do = is to > choose captures form other sites, maybe only the single camera sites, to = fill > in the rest of the switched captures that are not used by the most recent > talker. > > > >> It could use site switching: the site of the most recent speaker in > >> scene 1, 2nd most recent speaker in Scene 2, etc. As long as each > >> site has three cameras that would work fine. But in the given example > >> that isn't so. If the 2nd most recently speaking site only has one > >> capture, and the 3rd most recently speaking site has three captures, > >> does it leave VC5 and VC6 empty? That doesn't seem like an ideal choic= e. > > > > [Duckworth, Mark] I expect it would not leave VC5 and VC6 empty. > > I agree. > > >> Or does it back fill? (Put the most recently speaking four sites into > >> Scenes 1...4. Then put the 5th most recently speaking site into the > >> first captures in any of the sites that are still open, etc.) This > >> would *work*, but it would violate the idea that the scenes are in pri= ority > order. > > > > [Duckworth, Mark] Yes, that sounds the same as what I was suggesting > above. > > > >> So a receiving site that > >> couldn't take them all might get some lower priority captures while > >> missing some higher priority ones. > > > > [Duckworth, Mark] No, the consumer is getting the captures the consumer > asked for. The priority of those switched captures does not change. The > MCU in this case is deciding which streams belong in the switched capture= s. > The priority of those switched captures is defined by the MCU. So the MC= U > is the one that sets the priority and makes the decisions based on local = policy. > > Maybe we are thinking of this differently. > > My thinking is that the definition of the content of each capture in the > advertisement is fixed at the time the advertisement is sent. So the > configuration of which captures are to be received does not alter that. [Duckworth, Mark] I think it is okay if the Provider alters its algorithm f= or switching depending on what the consumer has configured. I think this i= s particularly true for the case where the advertisement has a CSE attribut= e for "explicitly signaling that a subset of the constituent captures can b= e used to produce a valid representation of that scene." We haven't agreed= yet on adding such an attribute, maybe it is a bad idea, see below for ano= ther example and question about it. > Of course that is tricky for switched captures, especially site-switched.= I think > it can only be defined by an algorithm. > But it could be defined by an algorithm such as the one I described above= . > > (I'm not implying that the algorithm needs to be standardized, or even > advertised, except in the most general terms.) > > And of course the captures have their priorities fixed in the advertiseme= nt. > So we presume that those with higher priority are more important to > receive. > > I'll also presume that more recent speakers, (or sites containing more re= cent > speakers) are more important to receive that less recent ones. So ideally= the > captures containing the more recent ones should be the captures with the > highest priority. > > But trying to preserve spatial relationships seems to result in assigning= some > sites into captures with lower priority that their desired priority order= . [Duckworth, Mark] Yes, and I think that is okay. > I *think* you are suggesting that this would be fixed by doing the switch= ing > assignment to captures based on what captures have been configured, > rather than only based on the advertisement. [Duckworth, Mark] Yes, I'm saying the actual switching algorithm used by th= e MCU could depend on which captures the consumer has configured. I don't = see any problem with that. > Now maybe that is ok. But it makes it a real challenge to come up with a = good > definition of what a switched capture is, that makes it possible to make = a > good choice of what to configure. [Duckworth, Mark] I think the definition of switching algorithm decisions h= as to be loose, to let the Provider do what it wants to do. If the consume= r wants to have more control, then the consumer should be making more speci= fic decisions about which original captures it wants to receive, including = changing that decision fairly frequently as current talkers change. I thin= k this is an interesting topic also, not specific to CLUE. > > [Duckworth, Mark] Again, I think this issue of how the MCU decides what > to put in switched captures is really the same issue no matter how many > capture scenes there are, how many captures in a CSE, or what the priorit= y > attribute values are. If you think this issue is not really an issue if = there is just > one capture scene, can you explain why? > > The constraints on the spatial relationships in a single scene make it si= mpler, > at the expense of doing a poorer job of preserving spatial relationships. > > It may be that we have simply tried to tackle an intractable problem. > So far I haven't seen a solution proposed that can do a good job in cases > where the rooms have significantly different arrangements. [Duckworth, Mark] I think the multiple scenes idea from section 3.2 of my d= raft does a good job for cases I'm interested in, including the example in = the draft. > >> Section 4: > >> > >> A consumer that can handle all 12 captures isn't the interesting one > >> to consider here. More interesting are endpoints E,F,G. Lets consider = F: > >> > >> It can handle 8 captures: two big and 6 small. Or maybe one big and 12 > small. > >> > >> The quality of the result depends upon the interaction between how > >> the advertiser chooses to distribute sites among its advertised > >> captures and the choices the consumer makes to distribute those among > displays. > > > > [Duckworth, Mark] Yes, exactly. draft-hansen-clue-consumer-layout and > draft-pepperell-clue-switched-attribute suggest a solution for this. Tha= t's > why I'm suggesting it again. > > Yes. The essence of these is that the consumer describes the rendering > capabilities and the provider then chooses what to send that will best po= rtray > what the advertiser has available. > > This is certainly a possible approach. But IMO it is a radical departure = from the > current model where the advertiser describes what is available, and the > consumer chooses what it wants and how to best render what it has chosen. [Duckworth, Mark] Yes, that's one reason why I'm leaning toward using the m= ultiple scenes approach, because it works with the current framework. > I could see choosing either extreme. But it gets messy if we choose some > halfway point between the two extremes. And that is what seems to have > been proposed. Again, this is *possible*, but it gets messy. > > Either extreme has tradeoffs: > - for our current approach, we are limited by how much the consumer > knows about what it is choosing. The advertiser knows more, but > we have chosen to limit how much is make available to the consumer, > in order to keep things simple. [Duckworth, Mark] Yes. I think this is okay. > - for the "provider makes it right" approach, the provider has all > the info about the sources. But then it is limited by what it knows > about the consumer. The details about this haven't been worked out > in great detail. But I think they will be difficult to describe > thoroughly. > > In any case, it seems to me that this is a difficult and important subjec= t. If we > get it wrong the result may be that the CLUE is found to be unusable. [Duckworth, Mark] I still think the multiple scenes advertisement works, al= ong with the "provider makes it right" approach as you say. > >> And it doesn't look like there is enough information to allow the > >> consumer to do the best possible job. > > > > [Duckworth, Mark] I think "the best possible job" is very subjective an= d > can't be explicitly defined. Different people will have different opinio= ns > about what is "best". At this point I'm trying to make sure there is a w= ay to > do what most people would consider a "reasonably good job". > > Agreed. Perhaps we should set some metrics for this. E.g., > > - that it should produce the ideal result when all sites are identical > - set low, but attainable, goals for radically dissimilar sites. > > >> But I think we need to work the examples to see this. > >> > >> Section 4.1 (One big scene): > >> > >> Issue: If the single screen endpoint wants to show 1 large image = and > >> three PiPs, then it must ask to receive 4 captures. But how coul= d it > >> ask for one capture that represents the whole scene, plus 3 other= s > >> that are additional lower priority, and that the 3 others shouldn= 't > >> have a spatial relationship with the one large one? The "Area of > >> Display" idea would solve this issue. A 2 screen consumer would = be > >> similar to a single screen endpoint, regarding this issue. > >> > >> I think your example doesn't support this case. I thought the > >> captures, while switched, each represented a single camera. I'm not > >> sure what kind of advertisement would cover what you are questioning. > > > > [Duckworth, Mark] I don't follow you, but I'll try to explain my > > thoughts better. Yes, each switched capture represents a single > > camera at a time, but which camera that is can be switched fairly > > frequently by the MCU. Let's start with the single screen consumer > > that wants 1 large image to represent the highest priority, plus 3 > > small images of lower priority, and these 3 small images can be > > spatially related. If the advertisement is the one in section 3.2, > > then the consumer would ask for VC1, VC4, VC5, VC6. With VC1 being > > large (high resolution) and the rest small. I think > this would work well. > > This goes back to my question about whether the mappings are fixed with > the advertisement, or dependent upon what is configured. > > I would expect that VC1 would contain the current talker. If the 2nd most > recent talker was from a different site with three cameras, then > VC4..6 would contain that site, which would be ok. > > But if the current talker came from a site with only one camera, and the = 2nd > most recent talker came from a site with 1 or 2 cameras, then it is uncle= ar > that the 2nd most recent talking site will be mapped to VC4..6 - it might= be > mapped to VC2..3. [Duckworth, Mark] Yes, could be either, depends on the algorithm/policy in = the provider. Consumer doesn't need to have knowledge of this. > So the mapping algorithm must be very well understood by both ends in > order to for this selection to work well. [Duckworth, Mark] I disagree. I am thinking of "the provider makes it righ= t" approach, as you put it. In my view, the consumer doesn't need to know = any more details of the provider's switching algorithm. [Duckworth, Mark] Maybe the concept of "explicitly signaling that a subset = of the constituent captures can be used to produce a valid representation o= f that scene" is making this more complicated than it needs to be. Suppose= the advertisement was like this, where all the captures are switched: Scene 1: (higher priority captures) CSE1 (VC1, VC2, VC3) CSE2 (VC4, VC5) CSE3 (VC6) Scene 2: (lower priority captures) CSE1 (VC7, VC8, VC9) CSE2 (VC10, VC11) CSE3 (VC12) and so on... Now consider the single screen consumer that wants 1 large image to represe= nt the highest priority, plus 3 small images of lower priority, and these 3= small images can be spatially related. This consumer will ask for VC6 (hi= gh resolution), VC7, VC8, VC9 (all low res). In this case, we can distingu= ish between VC6 and VC1. It is more clear now that VC6 should represent th= e entire scene 1. With scenes like this, it seems the switching algorithm = is less dependent (maybe not at all?) on what has been configured by the co= nsumer. Does this approach avoid some issues you raise? > Again, this just points to a need be very precise about what we mean by s= ite > switching. [Duckworth, Mark] I think it should be very loose, doesn't need to be preci= se at all. > > Similarly, a 2 screen consumer would ask for VC1, VC2, VC4, VC5, VC6, a= nd > maybe also VC7, VC8, VC9. A very simple single screen consumer would ask > for VC1. > > I'm not going to discuss this case until we understand the prior one. > > > [Duckworth, Mark] But if the advertisement is the one in section 3.1, t= hen I > don't know how the consumer could ask for what it wants. This is where > draft-hansen-clue-consumer-layout offers a solution. > > Agreed. > > Thanks, > Paul From john@jlc.net Thu Jul 25 13:04:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED021F91CB for ; Thu, 25 Jul 2013 13:04:49 -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, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vB+BV+LFEey for ; Thu, 25 Jul 2013 13:04:44 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ADAB821F91CE for ; Thu, 25 Jul 2013 13:04:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 51CFC33C20; Thu, 25 Jul 2013 16:04:44 -0400 (EDT) Date: Thu, 25 Jul 2013 16:04:44 -0400 From: John Leslie To: Christian Groves Message-ID: <20130725200444.GB8295@verdi> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51EF1DEE.9010708@nteczone.com> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:04:50 -0000 Christian Groves wrote: > To: John Leslie >> >> A microphone has a point of capture in three dimensions. This is >> worth preserving. The audio it captures has no useful (X,Y) dimensions. >> There is a sensitivity pattern; but in most cases it can be ignored. >> What can't be ignored is the fall-off in sensitivity with distance and >> the increase in latency for a signal to reach it through the air. >> >> Bottom-line: the point of capture is the only always-significant >> feature. The latency becomes significant if you try to pinpoint the >> source of the audio captured; but we probably won't do that. (We might, >> however, try to blend two microphones, in which case the difference >> in latency would _sometimes_ be worth considering.) The reduced audio >> level from sources farther away will usually deserve to be ignored. >> The desire to keep audio loud enough but not unpleasant is quite >> independent of the actual audio level. >> > [CNG] So what you're basically proposing is that the "Area of Capture" > attribute and "Point on capture axis" is changed to be valid only for > video capture. Audio captures would only have the "Capture point" and > "Audio Channel" parameters? I don't know if I want to go so far as "proposing," but - "Area of Capture" makes no sense to me for audio. - "Point on capture axis" makes no sense to me unless there is also a "sensitivity pattern". I don't expect folks to use sensitivity patters within the next year or two. The current case is using an aimed shotgun to capture an individual with a question from the audience. For that use, I expect folks to mix it into a surround-sound presentation without specifying how they derived it. -- John Leslie From pkyzivat@alum.mit.edu Thu Jul 25 13:16:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC4021F962D for ; Thu, 25 Jul 2013 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4E8fRwXyH0U for ; Thu, 25 Jul 2013 13:16:16 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7A21F95BD for ; Thu, 25 Jul 2013 13:16:15 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta07.westchester.pa.mail.comcast.net with comcast id 4bf21m0050xGWP857kGF6t; Thu, 25 Jul 2013 20:16:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 4kGF1m00F3ZTu2S3YkGFg6; Thu, 25 Jul 2013 20:16:15 +0000 Message-ID: <51F1878E.2040703@alum.mit.edu> Date: Thu, 25 Jul 2013 16:16:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> In-Reply-To: <20130725200444.GB8295@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374783375; bh=RPt8HURfMft61uJTOp+QobluK72dy2iQxX76huefSvM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e2+OWXxSFBKs66EU/0WjFO50ra5bT8LdJguveNIN4NodJYgv6r0BtADspdwIvfFwU ++fvWhuWRLVMvnjrPfR49nd2Vut8QOk1jjGq0BuqpuKSIHAZFHE0us/kC3Kx+8/D9C hX5UmgzUCbwcSVRf3CQmmRSI1pamnHPOzY6BHf10TjZOLfixYeAMy1JkVPgMkLPske NZlZri1uBjccE8Mizb9ntzGjY6mBSqawrExEnPpBAYiXjgWzzYZX6qDZB0KWC0s1R0 ZDtJdAueNLnSnwjBiNNJFwe1XqyN37J8C65pQlxextuteMzOX4YY4woLs8lH8Z7aZ6 ckeGNZBbSqi2Q== Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:16:22 -0000 I am commenting from the perspective of somebody who knows nothing special about audio... On 7/25/13 4:04 PM, John Leslie wrote: > Christian Groves wrote: >> To: John Leslie >>> >>> A microphone has a point of capture in three dimensions. This is >>> worth preserving. The audio it captures has no useful (X,Y) dimensions. >>> There is a sensitivity pattern; but in most cases it can be ignored. >>> What can't be ignored is the fall-off in sensitivity with distance and >>> the increase in latency for a signal to reach it through the air. >>> >>> Bottom-line: the point of capture is the only always-significant >>> feature. The latency becomes significant if you try to pinpoint the >>> source of the audio captured; but we probably won't do that. (We might, >>> however, try to blend two microphones, in which case the difference >>> in latency would _sometimes_ be worth considering.) The reduced audio >>> level from sources farther away will usually deserve to be ignored. >>> The desire to keep audio loud enough but not unpleasant is quite >>> independent of the actual audio level. >>> >> [CNG] So what you're basically proposing is that the "Area of Capture" >> attribute and "Point on capture axis" is changed to be valid only for >> video capture. Audio captures would only have the "Capture point" and >> "Audio Channel" parameters? > > I don't know if I want to go so far as "proposing," but > > - "Area of Capture" makes no sense to me for audio. That has troubled me for some time. Glad to hear it isn't just me. > - "Point on capture axis" makes no sense to me unless there is also a > "sensitivity pattern". I guess there are omnidirectional mics where axis of capture makes no sense. But in my naive view I would think that most mics have some directional sensitivity and that knowing the axis would be "better than nothing". > I don't expect folks to use sensitivity patters within the next year > or two. > > The current case is using an aimed shotgun to capture an individual > with a question from the audience. For that use, I expect folks to mix > it into a surround-sound presentation without specifying how they > derived it. ISTM that we need to provide *something* that will help the consumer to decide which audio captures to choose if it can't choose them all, and how to assign them to the speakers it has. I don't know what that something is. The one advantage of area of capture for audio is that if you pick a particular video capture then you might want to look for an audio capture that covers that area. Axis of capture might also be used as a hint in the same way. But I realize that is naive. Thanks, Paul From christer.holmberg@ericsson.com Thu Jul 25 13:28:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E066321F84B8 for ; Thu, 25 Jul 2013 13:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZzloBP+U0QQ for ; Thu, 25 Jul 2013 13:28:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 31D8621F8A85 for ; Thu, 25 Jul 2013 13:28:10 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-30-51f18a594d1e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 36.4C.19388.95A81F15; Thu, 25 Jul 2013 22:28:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 22:28:09 +0200 From: Christer Holmberg To: Paul Kyzivat , clue_ietf.org Thread-Topic: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt Thread-Index: AQHOgmA126CPpn8yikmyHGZOHINUW5lpn8gAgACKUACAAOr8gIAHZO4AgAAIBwCAAF8KAIAC3Q4AgAADNwCAACTaxQ== Date: Thu, 25 Jul 2013 20:28:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C409AEA@ESESSMB209.ericsson.se> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi>,<51F1878E.2040703@alum.mit.edu> In-Reply-To: <51F1878E.2040703@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C409AEAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW5U18dAgxWXmSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj8rYdjAWTPCv6ZnYyNjBOtO1i5OSQEDCR WH7lMBOELSZx4d56ti5GLg4hgcOMEvsnLwRLCAksYZS4dY23i5GDg03AQqL7nzZIWETAXeL5 vimsILawQJBEQ88RNoh4sMTfXz9YIewsiflzD7KDtLIIqEo8faAJYvIK+ErMP1kFsWk9s8TC i3MZQco5BXQkepqbwWxGoHO+n1oDdgGzgLjErSfzoc4UkFiy5zwzhC0q8fLxP1aImnyJnnO/ wXp5BQQlTs58wjKBUXgWkvZZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZ cxMzc9LLzTcxAuPj4JbfBjsYN90XO8QozcGiJM67We9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZGpbkXDa2vuoiuSNptZbhkycdZxmrfFsQsujUhZY7LXOv6nwynczh1JzqHiKzVLrlZ 0zyjM3rVZss+6ym+04z6+/uC2ornf1k9g4+hKSJcfWrdygcur1uZtPOiFy1lqbOLjOhvZ2nw KOta2d/CuPHtAX3/F/82836fZyD6/N7jk4J9j5SE/z9XYinOSDTUYi4qTgQAqrzo1l0CAAA= Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:28:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C409AEAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had a discussion about this with some of my colleagues just before summer= , and there might be a need for area of capture also for audio. I'll get back to this when people come back from their summer vacation. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: clue@ietf.org [clue@ietf.org] Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-0= 4.txt I am commenting from the perspective of somebody who knows nothing special about audio... On 7/25/13 4:04 PM, John Leslie wrote: > Christian Groves wrote: >> To: John Leslie >>> >>> A microphone has a point of capture in three dimensions. This is >>> worth preserving. The audio it captures has no useful (X,Y) dimensions. >>> There is a sensitivity pattern; but in most cases it can be ignored. >>> What can't be ignored is the fall-off in sensitivity with distance and >>> the increase in latency for a signal to reach it through the air. >>> >>> Bottom-line: the point of capture is the only always-significant >>> feature. The latency becomes significant if you try to pinpoint the >>> source of the audio captured; but we probably won't do that. (We might, >>> however, try to blend two microphones, in which case the difference >>> in latency would _sometimes_ be worth considering.) The reduced audio >>> level from sources farther away will usually deserve to be ignored. >>> The desire to keep audio loud enough but not unpleasant is quite >>> independent of the actual audio level. >>> >> [CNG] So what you're basically proposing is that the "Area of Capture" >> attribute and "Point on capture axis" is changed to be valid only for >> video capture. Audio captures would only have the "Capture point" and >> "Audio Channel" parameters? > > I don't know if I want to go so far as "proposing," but > > - "Area of Capture" makes no sense to me for audio. That has troubled me for some time. Glad to hear it isn't just me. > - "Point on capture axis" makes no sense to me unless there is also a > "sensitivity pattern". I guess there are omnidirectional mics where axis of capture makes no sense. But in my naive view I would think that most mics have some directional sensitivity and that knowing the axis would be "better than nothing". > I don't expect folks to use sensitivity patters within the next year > or two. > > The current case is using an aimed shotgun to capture an individual > with a question from the audience. For that use, I expect folks to mix > it into a surround-sound presentation without specifying how they > derived it. ISTM that we need to provide *something* that will help the consumer to decide which audio captures to choose if it can't choose them all, and how to assign them to the speakers it has. I don't know what that something is. The one advantage of area of capture for audio is that if you pick a particular video capture then you might want to look for an audio capture that covers that area. Axis of capture might also be used as a hint in the same way. But I realize that is naive. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C409AEAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I had a discussion about this with some of my c= olleagues just before summer, and there might be a need for area of capture= also for audio.
 
I'll get back to this when people come back fro= m their summer vacation.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: clue@ietf.org [clue@ietf.org]
Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-require= ments-04.txt
I am commenting from the perspective of somebody w= ho knows nothing
special about audio...

On 7/25/13 4:04 PM, John Leslie wrote:
> Christian Groves <Christian.Groves@nteczone.com> wrote:
>> To: John Leslie <john@jlc.net>
>>>
>>> A microphone has a point of capture in three dimensions. This = is
>>> worth preserving. The audio it captures has no useful (X,Y) di= mensions.
>>> There is a sensitivity pattern; but in most cases it can be ig= nored.
>>> What can't be ignored is the fall-off in sensitivity with dist= ance and
>>> the increase in latency for a signal to reach it through the a= ir.
>>>
>>> Bottom-line: the point of capture is the only always-significa= nt
>>> feature. The latency becomes significant if you try to pinpoin= t the
>>> source of the audio captured; but we probably won't do that. (= We might,
>>> however, try to blend two microphones, in which case the diffe= rence
>>> in latency would _sometimes_ be worth considering.) The reduce= d audio
>>> level from sources farther away will usually deserve to be ign= ored.
>>> The desire to keep audio loud enough but not unpleasant is qui= te
>>> independent of the actual audio level.
>>>
>> [CNG] So what you're basically proposing is that the "Area of= Capture"
>> attribute and "Point on capture axis" is changed to be v= alid only for
>> video capture. Audio captures would only have the "Capture po= int" and
>> "Audio Channel" parameters?
>
>     I don't know if I want to go so far as "p= roposing," but
>
> - "Area of Capture" makes no sense to me for audio.

That has troubled me for some time. Glad to hear it isn't just me.

> - "Point on capture axis" makes no sense to me unless there = is also a
>    "sensitivity pattern".

I guess there are omnidirectional mics where axis of capture makes no
sense. But in my naive view I would think that most mics have some
directional sensitivity and that knowing the axis would be "better tha= n
nothing".

>     I don't expect folks to use sensitivity patter= s within the next year
> or two.
>
>     The current case is using an aimed shotgun to = capture an individual
> with a question from the audience. For that use, I expect folks to mix=
> it into a surround-sound presentation without specifying how they
> derived it.

ISTM that we need to provide *something* that will help the consumer to decide which audio captures to choose if it can't choose them all, and
how to assign them to the speakers it has. I don't know what that
something is.

The one advantage of area of capture for audio is that if you pick a
particular video capture then you might want to look for an audio
capture that covers that area. Axis of capture might also be used as a
hint in the same way. But I realize that is naive.

        Thanks,
        Paul

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1C409AEAESESSMB209erics_-- From Mark.Duckworth@polycom.com Thu Jul 25 13:46:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8B21F933B for ; Thu, 25 Jul 2013 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdvLATYXk+Gq for ; Thu, 25 Jul 2013 13:46:44 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1EECF21F9344 for ; Thu, 25 Jul 2013 13:46:39 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 25 Jul 2013 13:46:31 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 25 Jul 2013 13:46:29 -0700 Thread-Topic: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt Thread-Index: Ac6Jc+KTJB/WsIQ4TAS1r+wZz0OMbAAAtaZQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE4EA9@CRPMBOXPRD07.polycom.com> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> In-Reply-To: <51F1878E.2040703@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:46:49 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, July 25, 2013 4:16 PM > To: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements= - > 04.txt >=20 > I am commenting from the perspective of somebody who knows nothing > special about audio... [Duckworth, Mark] Me too. ..snip.. > The one advantage of area of capture for audio is that if you pick a part= icular > video capture then you might want to look for an audio capture that cover= s > that area. Axis of capture might also be used as a hint in the same way. = But I > realize that is naive. [Duckworth, Mark] Yes, that was part of the original motivation for using a= rea of capture for any media capture, not just video. Also we expected thi= s information to be useful for rendering, so the renderer could use this ar= ea information to mix received audio encodings into its loudspeakers in a s= patially meaningful way. The simple use case for this is for TIP-like mult= i-channel audio, where there is a left, center, and right channel that are = separately available and separately switchable. It seems to me area of cap= ture and/or axis of capture is still useful for this limited purpose. Mark From christer.holmberg@ericsson.com Thu Jul 25 13:48:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565421F933B for ; Thu, 25 Jul 2013 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tKZuAelZuju for ; Thu, 25 Jul 2013 13:48:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35321F9130 for ; Thu, 25 Jul 2013 13:48:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-8a-51f18f155e07 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A6.5F.00725.51F81F15; Thu, 25 Jul 2013 22:48:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 22:48:20 +0200 From: Christer Holmberg To: Roberta Presta , clue_ietf.org Thread-Topic: [clue] draft-ietf-clue-data-model-schema-00 Thread-Index: AQHOhvHyMuMhgIzqgE6akD2JS6NELZlxS0wAgAAjaoCAABQYAIAAgGOAgAPfggc= Date: Thu, 25 Jul 2013 20:48:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C409F43@ESESSMB209.ericsson.se> References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com>,<51EE6B77.2060601@unina.it> In-Reply-To: <51EE6B77.2060601@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C409F43ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra5o/8dAg1lfFS32n7rMbPHqc5UD k8eSJT+ZPH5secoUwBTFZZOSmpNZllqkb5fAlTH/8zG2gsnlFfPeT2VrYDyb0sXIySEhYCLx 9dx2JghbTOLCvfVsILaQwGFGiTfXPSDsJYwS/c+iuxg5ONgELCS6/2mDhEUEvCUuHGgBaxUG Crf3LWGGiFtKbJ/ZxwJh+0mcmXGQFcRmEVCVaGhuABvPK+ArceTtAiCbC2j8SkaJ1d8/MIIk OAU0JI5OOQhWxAh0z/dTa8AWMAuIS9x6Mh/qTgGJJXvOM0PYohIvH/9jhajJl9jx7T4LxAJB iZMzn7BMYBSehaR9FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0 csNNjMD4OLjlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB ccoBW4lMk1n95hIPZ8eu1Gn3s/PvvZ/N/tA4pW6qXHa58qzJ1x4X35/rIVCq7iLwx/zfUy5j Q42t3xncM/mEtY/ws519uyP25an7FQLiuW/XKUc2CBZdj2j0mCV1xsdyLjt3jErbgiVHXZND tgdfFuRwWSrX4idhXLtTalvFT/5/H/JDLscrsRRnJBpqMRcVJwIAKbPsxF0CAAA= Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:48:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C409F43ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Even if the advertiser thinks something has priority, the consumer may have= another opinion. Isn't the role/content information supposed to describe what content is ass= ociated with the capture, and then the consumer chooses what it wants - bas= ed on its own priorities? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Roberta Presta [roberta.presta@unina.it] To: clue@ietf.org [clue@ietf.org] Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 Hi all, another possibility is the following. Priority is an optional attribute. When it is absent, it is intended to be "the lowest priority". When it is present, you have to order the priority values in a way that the most important capture has the lowest numeric value. For example, if I have - the audio of the lecturer AC0, - the video of the lecturer VC0, - the video of the slides VC1, - the video of the overall room VC2 and I want to prioritize the audio of the lecturer, and then the video of the slides, I can set the priority values as follows: - AC0, priority =3D 1 - VC1, priority =3D 2 - other captures, no priority The media consumer will know that: - the most important capture is AC0 - the second one is VC1 - all the other captures have the same level of importance, which is lower than the one of AC0 and VC1. What is your feeling about it? Cheers, Roberta Il 23/07/2013 06:00, Christian Groves ha scritto: > Hello Paul, > > "Audio and video don't "compete" with one another." Currently > priorities can be set across all capture types. E.g. I can say that's > more important for you to get an audio stream and a presentation > stream than it is to get the video if you have to choose because of > some bandwidth/display/etc contraint. It wouldn't be possible if you > consider priority to be scoped to a single media. > > Regards, Christian > > On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >> On 7/22/13 8:41 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> I agree that a default is needed. >>> >>> The reason for a "no priority" I saw a case where an Advertiser for >>> example may offer prioritised audio but choose not to prioritise video >>> or vice versa. Rather than prioritise audio over video or vice versa >>> which would effectively happen if all captures had a default priority >>> level. >> >> Audio and video don't "compete" with one another. I can't see how the >> priority processing of one would interact with the other. >> >> Perhaps we need to say something that audio and video are >> independently prioritized. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>> A couple of things I picked up while reviewing this version: >>>> >>>> Section 3 & Section 22: >>>> >>>> The schema was updated so captureEncodingType references >>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>> so that the intended definition of encodingParametersType actually >>>> redefines captureParametersType. >>>> >>>> Section 10.7 : >>>> >>>> ... The higher the >>>> importance, the lower the contained value. When media captures are >>>> marked with a "0" priority value, it means that they are "not >>>> subject >>>> to priority". >>>> >>>> [edt's note: discussion needed] >>>> >>>> IMO it makes no sense for some captures to be subject to priority and >>>> others to not be subject to priority. What would that mean? The only >>>> thing I can see is that those are *mandatory* to render. But we can't >>>> really mandate that. If you can't do it we can't force you. So the >>>> best it could mean is "really really important" to render. But that is >>>> the same as having the highest priority. >>>> >>>> So I suggest that zero is just the highest priority - no more, no >>>> less. >>>> >>>> And I suggest we also make zero the *default* priority, so that all >>>> captures have one, implicitly or explicitly. Then, if you don't >>>> mention priority at all, then all captures are equal. And you can just >>>> add priority for those captures that are less important. >>>> >>>> Equivalently, we could leave priority optional, and specify that the >>>> absence of a priority implicitly means the highest priority. Then the >>>> presence of priority means a lower priority. But I think this >>>> formulation is a little more confusing to explain. >>>> >>>> Section 10.10. : >>>> >>>> is an optional element indicating wheter or not the >>>> capture device originating the capture moves during the >>>> telepresence >>>> session. ... >>>> >>>> We can't know for sure that it will move, only that it may. Also a >>>> typo. So: >>>> >>>> s/moves/may move/ >>>> s/wheter/whether/ >>>> >>>> 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 --_000_7594FB04B1934943A5C02806D1A2204B1C409F43ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Even if the advertiser thinks something has pri= ority, the consumer may have another opinion.
 
Isn't the role/content information supposed to = describe what content is associated with the capture, and then the consumer= chooses what it wants - based on its own priorities?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Roberta Presta [roberta.presta@unina.it]
To: clue@ietf.org [clue@ietf.org]
Subject: Re: [clue] draft-ietf-clue-data-model-schema-00
Hi all,

another possibility is the following.
Priority is an optional attribute.
When it is absent, it is intended to be "the lowest priority". When it is present, you have to order the priority values in a way that the most important capture has the lowest numeric value.

For example, if I have
- the audio of the lecturer AC0,
- the video of the lecturer VC0,
- the video of the slides VC1,
- the video of the overall room VC2
and I want to prioritize the audio of the lecturer, and then the video
of the slides, I can set the priority values as follows:
- AC0, priority =3D 1
- VC1, priority =3D 2
- other captures, no priority

The media consumer will know that:
- the most important capture is AC0
- the second one is VC1
- all the other captures have the same level of importance, which is
lower than the one of  AC0 and VC1.

What is your feeling about it?
Cheers,

Roberta


Il 23/07/2013 06:00, Christian Groves ha scritto:
> Hello Paul,
>
> "Audio and video don't "compete" with one another."= ; Currently
> priorities can be set across all capture types. E.g. I can say that's =
> more important for you to get an audio stream and a presentation
> stream than it is to get the video if you have to choose because of > some bandwidth/display/etc contraint. It wouldn't be possible if you <= br> > consider priority to be scoped to a single media.
>
> Regards, Christian
>
> On 23/07/2013 12:48 PM, Paul Kyzivat wrote:
>> On 7/22/13 8:41 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> I agree that a default is needed.
>>>
>>> The reason for a "no priority" I saw a case where an= Advertiser for
>>> example may offer prioritised audio but choose not to prioriti= se video
>>> or vice versa. Rather than prioritise audio over video or vice= versa
>>> which would effectively happen if all captures had a default p= riority
>>> level.
>>
>> Audio and video don't "compete" with one another. I can'= t see how the
>> priority processing of one would interact with the other.
>>
>> Perhaps we need to say something that audio and video are
>> independently prioritized.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards, Christian
>>>
>>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote:
>>>> A couple of things I picked up while reviewing this versio= n:
>>>>
>>>> Section 3 & Section 22:
>>>>
>>>> The schema was updated so captureEncodingType references >>>> encodingParametersType, but there is a typo (cut/paste err= or I guess)
>>>> so that the intended definition of encodingParametersType = actually
>>>> redefines captureParametersType.
>>>>
>>>> Section 10.7 <priority>:
>>>>
>>>>    ... The higher the
>>>>    importance, the lower the contained valu= e.  When media captures are
>>>>    marked with a "0" priority val= ue, it means that they are "not
>>>> subject
>>>>    to priority".
>>>>
>>>>    [edt's note: discussion needed]
>>>>
>>>> IMO it makes no sense for some captures to be subject to p= riority and
>>>> others to not be subject to priority. What would that mean= ? The only
>>>> thing I can see is that those are *mandatory* to render. B= ut we can't
>>>> really mandate that. If you can't do it we can't force you= . So the
>>>> best it could mean is "really really important" = to render. But that is
>>>> the same as having the highest priority.
>>>>
>>>> So I suggest that zero is just the highest priority - no m= ore, no
>>>> less.
>>>>
>>>> And I suggest we also make zero the *default* priority, so= that all
>>>> captures have one, implicitly or explicitly. Then, if you = don't
>>>> mention priority at all, then all captures are equal. And = you can just
>>>> add priority for those captures that are less important. >>>>
>>>> Equivalently, we could leave priority optional, and specif= y that the
>>>> absence of a priority implicitly means the highest priorit= y. Then the
>>>> presence of priority means a lower priority. But I think t= his
>>>> formulation is a little more confusing to explain.
>>>>
>>>> Section 10.10. <mobility>:
>>>>
>>>>    <mobility> is an optional element = indicating wheter or not the
>>>>    capture device originating the capture m= oves during the
>>>> telepresence
>>>>    session.  ...
>>>>
>>>> We can't know for sure that it will move, only that it may= . Also a
>>>> typo. So:
>>>>
>>>> s/moves/may move/
>>>> s/wheter/whether/
>>>>
>>>>     Thanks,
>>>>     Paul
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>> 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.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1C409F43ESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu Jul 25 14:28:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3D21F848E for ; Thu, 25 Jul 2013 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjfnvxL3MtFx for ; Thu, 25 Jul 2013 14:28:22 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3E21F9130 for ; Thu, 25 Jul 2013 14:28:19 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id 4hjT1m0031wpRvQ5ClUJaR; Thu, 25 Jul 2013 21:28:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 4lUJ1m00X3ZTu2S3elUJmd; Thu, 25 Jul 2013 21:28:18 +0000 Message-ID: <51F19870.20509@alum.mit.edu> Date: Thu, 25 Jul 2013 17:28:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Duckworth, Mark" References: <51ED62AA.9060802@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4986@CRPMBOXPRD07.polycom.com> <51F14C7E.7010604@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4DD9@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601FE4DD9@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374787698; bh=wbFgbmRewbJvrT8/jwIEiIQgDPaArSnMs8PtQwgLCus=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N3076pxZupcwxp0kfhVTBauuYjDlZTK4t/kcOsun91CUzvph5DhvKQ89ICG0S47K+ PHRA7AsxWsMiddfZiz7mHfQnHoJBUODRRApd0TV3oRXYGtPrIPbtceduM1GTfxN/uU yznffHd7Locc3k9luftsTxVg7EQIFBPshsjSIjpEwiFjn2Ym7mx5goosWNGM94pvwn XElAXrKPd2e7VUn/mPYzPa9BtjD2YM4RkcPAJFHsfN4qmtmOBlKEJzndZPWGA+z2mE B7M4xG8Ctlt9nY6yslIPuPfPqD+i7GV+4wk8M74Kqw23xyrNdAn9ZJBWo11bV7BM8q x9/EIabdPhL/w== Cc: CLUE Subject: Re: [clue] draft-duckworth-clue-switching-example-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 21:28:28 -0000 On 7/25/13 3:06 PM, Duckworth, Mark wrote: > Hi Paul, > > Yeah, it's hard, but I think we can come to a "good enough" solution to cover basic switched capture use cases. It seems to me we are thinking along the same lines, for the most part, in the discussion below. Particularly see my suggestion near the end, to see if it avoids some issues you raise. > > Personally, I now think the scenarios I'm most interested in can be handled with the framework as is, by using the multiple scenes approach in section 3.2 of my draft. > > I was hoping more people would be interested in discussing this on the list. Me too. But we are now into the period when many people are in transit or otherwise very busy. So we can't infer anything from silence right now. I am starting to think that we might want/need to form a group of people who are both knowledgeable and interested in this subject, to pursue it in depth. Ensuring that reasonable choices can be made, especially in common cases, but even in hard cases, will take a lot of thought I think. (And this needs to work for audio as well as video!) It will not be nice to find out after the fact that implementation A can't work in a reasonable way with implementation B because of inadequacies here. More inline. > More inline. > > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, July 25, 2013 12:04 PM >> To: Duckworth, Mark >> Cc: CLUE >> Subject: Re: [clue] draft-duckworth-clue-switching-example-01 >> >> Mark, >> >> More inline. There are some nasty problems here. This is hard! >> >> On 7/24/13 4:11 PM, Duckworth, Mark wrote: >>> Hi Paul, >>> >>> Thanks very much for the comments! >>> >>> Discussion inline. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Monday, July 22, 2013 12:50 PM >>>> To: CLUE >>>> Subject: [clue] draft-duckworth-clue-switching-example-01 >>>> >>>> Section 3.2 (Advertising multiple scenes): >>>> >>>> While I understand what you are trying to do, I can't figure out how >>>> to make this approach work in a sensible way. >>>> >>>> What logic would the MCU use to assign actual captures to the >>>> switched captures in the multiple scenes? >>> >>> [Duckworth, Mark] I see it as an extension of what the MCU could do if >> there was only one scene with a CSE with 3 captures for site switching (just to >> use an example). If the most recent talker has 3 cameras, then use those. If >> the most recent talker has just 1 camera, then what does the MCU do? I >> think the question is fundamentally the same whether there is one simple >> scene with 3 captures, one scene with 12 captures in a CSE, or several scenes >> each with multiple captures. I think a sensible thing for the MCU to do is to >> choose captures form other sites, maybe only the single camera sites, to fill >> in the rest of the switched captures that are not used by the most recent >> talker. >>> >>>> It could use site switching: the site of the most recent speaker in >>>> scene 1, 2nd most recent speaker in Scene 2, etc. As long as each >>>> site has three cameras that would work fine. But in the given example >>>> that isn't so. If the 2nd most recently speaking site only has one >>>> capture, and the 3rd most recently speaking site has three captures, >>>> does it leave VC5 and VC6 empty? That doesn't seem like an ideal choice. >>> >>> [Duckworth, Mark] I expect it would not leave VC5 and VC6 empty. >> >> I agree. >> >>>> Or does it back fill? (Put the most recently speaking four sites into >>>> Scenes 1...4. Then put the 5th most recently speaking site into the >>>> first captures in any of the sites that are still open, etc.) This >>>> would *work*, but it would violate the idea that the scenes are in priority >> order. >>> >>> [Duckworth, Mark] Yes, that sounds the same as what I was suggesting >> above. >>> >>>> So a receiving site that >>>> couldn't take them all might get some lower priority captures while >>>> missing some higher priority ones. >>> >>> [Duckworth, Mark] No, the consumer is getting the captures the consumer >> asked for. The priority of those switched captures does not change. The >> MCU in this case is deciding which streams belong in the switched captures. >> The priority of those switched captures is defined by the MCU. So the MCU >> is the one that sets the priority and makes the decisions based on local policy. >> >> Maybe we are thinking of this differently. >> >> My thinking is that the definition of the content of each capture in the >> advertisement is fixed at the time the advertisement is sent. So the >> configuration of which captures are to be received does not alter that. > > [Duckworth, Mark] I think it is okay if the Provider alters its algorithm for switching depending on what the consumer has configured. I think this is particularly true for the case where the advertisement has a CSE attribute for "explicitly signaling that a subset of the constituent captures can be used to produce a valid representation of that scene." We haven't agreed yet on adding such an attribute, maybe it is a bad idea, see below for another example and question about it. > >> Of course that is tricky for switched captures, especially site-switched. I think >> it can only be defined by an algorithm. >> But it could be defined by an algorithm such as the one I described above. >> >> (I'm not implying that the algorithm needs to be standardized, or even >> advertised, except in the most general terms.) >> >> And of course the captures have their priorities fixed in the advertisement. >> So we presume that those with higher priority are more important to >> receive. >> >> I'll also presume that more recent speakers, (or sites containing more recent >> speakers) are more important to receive that less recent ones. So ideally the >> captures containing the more recent ones should be the captures with the >> highest priority. >> >> But trying to preserve spatial relationships seems to result in assigning some >> sites into captures with lower priority that their desired priority order. > > [Duckworth, Mark] Yes, and I think that is okay. IMO its not ok if it results in displaying less important stuff while omitting more important stuff. >> I *think* you are suggesting that this would be fixed by doing the switching >> assignment to captures based on what captures have been configured, >> rather than only based on the advertisement. > > [Duckworth, Mark] Yes, I'm saying the actual switching algorithm used by the MCU could depend on which captures the consumer has configured. I don't see any problem with that. > >> Now maybe that is ok. But it makes it a real challenge to come up with a good >> definition of what a switched capture is, that makes it possible to make a >> good choice of what to configure. > > [Duckworth, Mark] I think the definition of switching algorithm decisions has to be loose, to let the Provider do what it wants to do. If the consumer wants to have more control, then the consumer should be making more specific decisions about which original captures it wants to receive, including changing that decision fairly frequently as current talkers change. I think this is an interesting topic also, not specific to CLUE. I'm not trying to suggest that the exact switching algorithms need to be specified. But the consumer needs to have some expectations about some properties of the switching algorithms when choosing which switched captures to configure. If there are *no* guarantees, then if there are three switched captures and I only take one of them, then I might get something totally useless. And consider if I must choose one of three switched video captures, and one of three switched audio captures. What guarantee do I have that they go together? The algorithm I construct to decide which captures to configure and how to map them onto local equipment only has a few things to work with: - the available equipment for rendering the received captures - the advertisement - the guarantees (whichever ones we include) in the clue spec about how switching works. Those guarantees are an important part of that. >>> [Duckworth, Mark] Again, I think this issue of how the MCU decides what >> to put in switched captures is really the same issue no matter how many >> capture scenes there are, how many captures in a CSE, or what the priority >> attribute values are. If you think this issue is not really an issue if there is just >> one capture scene, can you explain why? >> >> The constraints on the spatial relationships in a single scene make it simpler, >> at the expense of doing a poorer job of preserving spatial relationships. >> >> It may be that we have simply tried to tackle an intractable problem. >> So far I haven't seen a solution proposed that can do a good job in cases >> where the rooms have significantly different arrangements. > > [Duckworth, Mark] I think the multiple scenes idea from section 3.2 of my draft does a good job for cases I'm interested in, including the example in the draft. You think it works for this case, given your assumptions about how provider makes it right works. I'm not convinced yet. I'll give it a "maybe". >>>> Section 4: >>>> >>>> A consumer that can handle all 12 captures isn't the interesting one >>>> to consider here. More interesting are endpoints E,F,G. Lets consider F: >>>> >>>> It can handle 8 captures: two big and 6 small. Or maybe one big and 12 >> small. >>>> >>>> The quality of the result depends upon the interaction between how >>>> the advertiser chooses to distribute sites among its advertised >>>> captures and the choices the consumer makes to distribute those among >> displays. >>> >>> [Duckworth, Mark] Yes, exactly. draft-hansen-clue-consumer-layout and >> draft-pepperell-clue-switched-attribute suggest a solution for this. That's >> why I'm suggesting it again. >> >> Yes. The essence of these is that the consumer describes the rendering >> capabilities and the provider then chooses what to send that will best portray >> what the advertiser has available. >> >> This is certainly a possible approach. But IMO it is a radical departure from the >> current model where the advertiser describes what is available, and the >> consumer chooses what it wants and how to best render what it has chosen. > > [Duckworth, Mark] Yes, that's one reason why I'm leaning toward using the multiple scenes approach, because it works with the current framework. IIUC what you are talking about is a point between the two extremes. >> I could see choosing either extreme. But it gets messy if we choose some >> halfway point between the two extremes. And that is what seems to have >> been proposed. Again, this is *possible*, but it gets messy. >> >> Either extreme has tradeoffs: >> - for our current approach, we are limited by how much the consumer >> knows about what it is choosing. The advertiser knows more, but >> we have chosen to limit how much is make available to the consumer, >> in order to keep things simple. > > [Duckworth, Mark] Yes. I think this is okay. > >> - for the "provider makes it right" approach, the provider has all >> the info about the sources. But then it is limited by what it knows >> about the consumer. The details about this haven't been worked out >> in great detail. But I think they will be difficult to describe >> thoroughly. >> >> In any case, it seems to me that this is a difficult and important subject. If we >> get it wrong the result may be that the CLUE is found to be unusable. > > [Duckworth, Mark] I still think the multiple scenes advertisement works, along with the "provider makes it right" approach as you say. So this is mostly of the "advertiser specifies fixed choices and consumer chooses", but with a bit of "provider makes it right". But the provider in this case has very limited data to help it decide what is right. Specifically, the only thing it manipulates is the switching algorithm, and the only data it has to work with to choose is which of the switched captures have been configured. I am having trouble getting my head around the possibilities and limitations that are present in that context. >>>> And it doesn't look like there is enough information to allow the >>>> consumer to do the best possible job. >>> >>> [Duckworth, Mark] I think "the best possible job" is very subjective and >> can't be explicitly defined. Different people will have different opinions >> about what is "best". At this point I'm trying to make sure there is a way to >> do what most people would consider a "reasonably good job". >> >> Agreed. Perhaps we should set some metrics for this. E.g., >> >> - that it should produce the ideal result when all sites are identical >> - set low, but attainable, goals for radically dissimilar sites. >> >>>> But I think we need to work the examples to see this. >>>> >>>> Section 4.1 (One big scene): >>>> >>>> Issue: If the single screen endpoint wants to show 1 large image and >>>> three PiPs, then it must ask to receive 4 captures. But how could it >>>> ask for one capture that represents the whole scene, plus 3 others >>>> that are additional lower priority, and that the 3 others shouldn't >>>> have a spatial relationship with the one large one? The "Area of >>>> Display" idea would solve this issue. A 2 screen consumer would be >>>> similar to a single screen endpoint, regarding this issue. >>>> >>>> I think your example doesn't support this case. I thought the >>>> captures, while switched, each represented a single camera. I'm not >>>> sure what kind of advertisement would cover what you are questioning. >>> >>> [Duckworth, Mark] I don't follow you, but I'll try to explain my >>> thoughts better. Yes, each switched capture represents a single >>> camera at a time, but which camera that is can be switched fairly >>> frequently by the MCU. Let's start with the single screen consumer >>> that wants 1 large image to represent the highest priority, plus 3 >>> small images of lower priority, and these 3 small images can be >>> spatially related. If the advertisement is the one in section 3.2, >>> then the consumer would ask for VC1, VC4, VC5, VC6. With VC1 being >>> large (high resolution) and the rest small. I think >> this would work well. >> >> This goes back to my question about whether the mappings are fixed with >> the advertisement, or dependent upon what is configured. >> >> I would expect that VC1 would contain the current talker. If the 2nd most >> recent talker was from a different site with three cameras, then >> VC4..6 would contain that site, which would be ok. >> >> But if the current talker came from a site with only one camera, and the 2nd >> most recent talker came from a site with 1 or 2 cameras, then it is unclear >> that the 2nd most recent talking site will be mapped to VC4..6 - it might be >> mapped to VC2..3. > > [Duckworth, Mark] Yes, could be either, depends on the algorithm/policy in the provider. Consumer doesn't need to have knowledge of this. I think the consumer wants to know that mapping will be a good one, not a bad one. >> So the mapping algorithm must be very well understood by both ends in >> order to for this selection to work well. > > [Duckworth, Mark] I disagree. I am thinking of "the provider makes it right" approach, as you put it. In my view, the consumer doesn't need to know any more details of the provider's switching algorithm. I commented on this one above. > [Duckworth, Mark] Maybe the concept of "explicitly signaling that a subset of the constituent captures can be used to produce a valid representation of that scene" is making this more complicated than it needs to be. Suppose the advertisement was like this, where all the captures are switched: > > Scene 1: (higher priority captures) > CSE1 (VC1, VC2, VC3) > CSE2 (VC4, VC5) > CSE3 (VC6) > Scene 2: (lower priority captures) > CSE1 (VC7, VC8, VC9) > CSE2 (VC10, VC11) > CSE3 (VC12) > and so on... I think I want to know the relative priorities to understand. I'm thinking you must mean something like: Scene 1: (higher priority captures) CSE1 (VC1:100, VC2:101, VC3:102) CSE2 (VC4:100, VC5:101) CSE3 (VC6:100) Scene 2: (lower priority captures) CSE1 (VC7:200, VC8:201, VC9:202) CSE2 (VC10:200, VC11:201) CSE3 (VC12:200) The above assumes lower numbers are higher priorities. I'm not confident in the above. I think using disjoint priority ranges for Scene 1 and Scene 2 is right. But I'm not sure what to do with priorities of the captures in a single scene. Obviously this interacts with how the consumer uses the priorities to assign captures to rendering devices. So what is the algorithm in this case? I can think of two fundamentally different ways to do that: either work through the available rendering devices and choose a capture for each, or else work through the captures in priority order and try to find rendering devices to put them on. I was going to work through the case now using one of those techniques. But it immediately presented complications. Clearly the algorithm is going to be tricky, and I couldn't come up with anything I wanted to write here. So I'm not sure if my assignment of priorities is helpful or not. It is bad if the advertiser can only know how to assign priorities by knowing the algorithm the consumer will use for selection. > Now consider the single screen consumer that wants 1 large image to represent the highest priority, plus 3 small images of lower priority, and these 3 small images can be spatially related. This consumer will ask for VC6 (high resolution), VC7, VC8, VC9 (all low res). Are you assuming that VC6 is only offered in high res, while VC7..9 are only offered in low res? Or are you assuming that all are offered at either res? If each is only offered in one res, then why? > In this case, we can distinguish between VC6 and VC1. Its clear that if you want to represent the scene with one capture then VC6 is the better choice, while if you want to represent the scene with three captures then VC1..3 is a better choice. But since it is *possible* to render scene 1 with one capture, it isn't clear if it is better to do that and save the other devices for other scenes, or if its better to devote more devices to scene 1 and fewer to the other scenes. What is hard about this is to ensure, when thinking about specific cases, that the assumption about how the advertisement is constructed isn't biased by knowledge about characteristics of the consumer that a real advertiser won't know. And conversely when considering the consumer behavior, that it isn't drawing inferences about what the advertisement means that really depend on knowledge about how the advertiser works. > It is more clear now that VC6 should represent the entire scene 1. With scenes like this, it seems the switching algorithm is less dependent (maybe not at all?) on what has been configured by the consumer. Does this approach avoid some issues you raise? > >> Again, this just points to a need be very precise about what we mean by site >> switching. > > [Duckworth, Mark] I think it should be very loose, doesn't need to be precise at all. Again, see earlier comment. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jul 25 15:14:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B26D21F84BB for ; Thu, 25 Jul 2013 15:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m33Ftb+seQfJ for ; Thu, 25 Jul 2013 15:14:39 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC321F84CD for ; Thu, 25 Jul 2013 15:14:38 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 4doE1m0030vyq2s5BmEdDS; Thu, 25 Jul 2013 22:14:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 4mEd1m00o3ZTu2S3RmEdo6; Thu, 25 Jul 2013 22:14:37 +0000 Message-ID: <51F1A34D.80400@alum.mit.edu> Date: Thu, 25 Jul 2013 18:14:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> In-Reply-To: <51EE6B77.2060601@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374790477; bh=AoZwfROVt01IW7wc80/83lTf7sV7Ad8Af29iScT9Uf0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OKEiBOXOa7eJs4zTS9XjRgy/Y/aa4hn4kk9eToxFVdbg+R3EmXlfWRneuQWVMTg3h 0MQgqkITjQQvuOcirsKoXPopXd43eLrKt+4BSdn5PlSGVLYdlF+segbB9nXGXzBcMO XhRHVEx2EBNPoh4o/H7D7FFeo97va3nexx3+A2B2gdXLX3r5KU8+1cBGgzHON9s8Gl 5g11Z87JXTg8lRXNAWKptIK5S70TAiVi201FXRBdTj5yAsMgsOanFvtpdwj5bFqoCG rKkf8DyOpMEL2wAmiT2vVBdPZzJgj+dLlFVUeQMJw6chivWItJX54R9SJUxZNMxGz7 dXyDScbs8uOOg== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:14:45 -0000 On 7/23/13 7:39 AM, Roberta Presta wrote: > Hi all, > > another possibility is the following. > Priority is an optional attribute. > When it is absent, it is intended to be "the lowest priority". > When it is present, you have to order the priority values in a way that > the most important capture has the lowest numeric value. > > For example, if I have > - the audio of the lecturer AC0, > - the video of the lecturer VC0, > - the video of the slides VC1, > - the video of the overall room VC2 > and I want to prioritize the audio of the lecturer, and then the video > of the slides, I can set the priority values as follows: > - AC0, priority = 1 > - VC1, priority = 2 > - other captures, no priority > > The media consumer will know that: > - the most important capture is AC0 > - the second one is VC1 > - all the other captures have the same level of importance, which is > lower than the one of AC0 and VC1. > > What is your feeling about it? > Cheers, It "works". The key advantage is that it provides a concise way to specify "lowest priority". Without this, the lowest priority could be specified as the maximum allowable priority value. (Is there an upper bound for unsigned int? 2^32-1?) Implementations are going to need a representation for all values, including the highest and lowest. If we are to represent priorities as unsigned integers, then I think both lowest and highest should fall into that range so that the implementation can use an unsigned integer too. So *if* we want the default to be lowest priority, then I would vote that we make the default be the highest value representable in the range, rather than something lower than that. I guess the question is whether we want the default to be highest priority or lowest priority. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jul 25 15:16:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7321F85C9 for ; Thu, 25 Jul 2013 15:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ZQ39VrOhBg for ; Thu, 25 Jul 2013 15:16:50 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0921F84CD for ; Thu, 25 Jul 2013 15:16:50 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id 4jRV1m0061ap0As54mGp3r; Thu, 25 Jul 2013 22:16:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 4mGp1m00J3ZTu2S3imGpEn; Thu, 25 Jul 2013 22:16:49 +0000 Message-ID: <51F1A3D1.3070905@alum.mit.edu> Date: Thu, 25 Jul 2013 18:16:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com>, <51EE6B77.2060601@unina.it> <7594FB04B1934943A5C02806D1A2204B1C409F43@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C409F43@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374790609; bh=BIFW3Xf4L+P5fHbm126OW/o+TBXVTuJzIdjwrkAC0vM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e5gwVVSNovV+x+tMp0NUhQ+B3IFi9rZEl7Gl2FoXrnCwbLEH6nDTHGjdZpFz+xR8A 3yNMO9rkLKUUHwffRMlxJ4fllw5rw5BApowNs6FT5VoYIxkWqmVbx6uuZ01KM4A9ZD 7L32hfD2cYaUthSsrko3RWC4J16nfXAyCgvTbGM0GAhuOil9b8X8x3JFS3JzfrF928 LaPEse/l9JpokHXj0OnxDrOmszxKVNnzY12AvvixGCI4K92BYF/DS9Ct0yA2j4Umjt 5gClXqzCdeMSJ52fuyrl3bHMZmpqamit/WiE6RVjMVjw4z/vnMDbIK9S81Aei2JAbg 6ujIsCp6eHlzA== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:16:55 -0000 On 7/25/13 4:48 PM, Christer Holmberg wrote: > Hi, > Even if the advertiser thinks something has priority, the consumer may > have another opinion. > Isn't the role/content information supposed to describe what content is > associated with the capture, and then the consumer chooses what it wants > - based on its own priorities? Its another attribute that the consumer can consider (or ignore). Thanks Paul > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Roberta Presta [roberta.presta@unina.it] > *To:* clue@ietf.org [clue@ietf.org] > *Subject:* Re: [clue] draft-ietf-clue-data-model-schema-00 > Hi all, > > another possibility is the following. > Priority is an optional attribute. > When it is absent, it is intended to be "the lowest priority". > When it is present, you have to order the priority values in a way that > the most important capture has the lowest numeric value. > > For example, if I have > - the audio of the lecturer AC0, > - the video of the lecturer VC0, > - the video of the slides VC1, > - the video of the overall room VC2 > and I want to prioritize the audio of the lecturer, and then the video > of the slides, I can set the priority values as follows: > - AC0, priority = 1 > - VC1, priority = 2 > - other captures, no priority > > The media consumer will know that: > - the most important capture is AC0 > - the second one is VC1 > - all the other captures have the same level of importance, which is > lower than the one of AC0 and VC1. > > What is your feeling about it? > Cheers, > > Roberta > > > Il 23/07/2013 06:00, Christian Groves ha scritto: >> Hello Paul, >> >> "Audio and video don't "compete" with one another." Currently >> priorities can be set across all capture types. E.g. I can say that's >> more important for you to get an audio stream and a presentation >> stream than it is to get the video if you have to choose because of >> some bandwidth/display/etc contraint. It wouldn't be possible if you >> consider priority to be scoped to a single media. >> >> Regards, Christian >> >> On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >>> On 7/22/13 8:41 PM, Christian Groves wrote: >>>> Hello Paul, >>>> >>>> I agree that a default is needed. >>>> >>>> The reason for a "no priority" I saw a case where an Advertiser for >>>> example may offer prioritised audio but choose not to prioritise video >>>> or vice versa. Rather than prioritise audio over video or vice versa >>>> which would effectively happen if all captures had a default priority >>>> level. >>> >>> Audio and video don't "compete" with one another. I can't see how the >>> priority processing of one would interact with the other. >>> >>> Perhaps we need to say something that audio and video are >>> independently prioritized. >>> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>>> A couple of things I picked up while reviewing this version: >>>>> >>>>> Section 3 & Section 22: >>>>> >>>>> The schema was updated so captureEncodingType references >>>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>>> so that the intended definition of encodingParametersType actually >>>>> redefines captureParametersType. >>>>> >>>>> Section 10.7 : >>>>> >>>>> ... The higher the >>>>> importance, the lower the contained value. When media captures are >>>>> marked with a "0" priority value, it means that they are "not >>>>> subject >>>>> to priority". >>>>> >>>>> [edt's note: discussion needed] >>>>> >>>>> IMO it makes no sense for some captures to be subject to priority and >>>>> others to not be subject to priority. What would that mean? The only >>>>> thing I can see is that those are *mandatory* to render. But we can't >>>>> really mandate that. If you can't do it we can't force you. So the >>>>> best it could mean is "really really important" to render. But that is >>>>> the same as having the highest priority. >>>>> >>>>> So I suggest that zero is just the highest priority - no more, no >>>>> less. >>>>> >>>>> And I suggest we also make zero the *default* priority, so that all >>>>> captures have one, implicitly or explicitly. Then, if you don't >>>>> mention priority at all, then all captures are equal. And you can just >>>>> add priority for those captures that are less important. >>>>> >>>>> Equivalently, we could leave priority optional, and specify that the >>>>> absence of a priority implicitly means the highest priority. Then the >>>>> presence of priority means a lower priority. But I think this >>>>> formulation is a little more confusing to explain. >>>>> >>>>> Section 10.10. : >>>>> >>>>> is an optional element indicating wheter or not the >>>>> capture device originating the capture moves during the >>>>> telepresence >>>>> session. ... >>>>> >>>>> We can't know for sure that it will move, only that it may. Also a >>>>> typo. So: >>>>> >>>>> s/moves/may move/ >>>>> s/wheter/whether/ >>>>> >>>>> 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@alum.mit.edu Thu Jul 25 15:24:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FD21F84EF for ; Thu, 25 Jul 2013 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkM4Ek+SL8tZ for ; Thu, 25 Jul 2013 15:23:59 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 190F421F8B12 for ; Thu, 25 Jul 2013 15:23:59 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta08.westchester.pa.mail.comcast.net with comcast id 4dS41m0090SCNGk58mPyGQ; Thu, 25 Jul 2013 22:23:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 4mPy1m00C3ZTu2S3VmPyFm; Thu, 25 Jul 2013 22:23:58 +0000 Message-ID: <51F1A57D.5040405@alum.mit.edu> Date: Thu, 25 Jul 2013 18:23:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> In-Reply-To: <51EDFFC4.1090803@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374791038; bh=KeKaS9tDyI9MotR6ubsfCQrOHntvKb8dY7oHxV5yLcA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U++x91kPpJmMyzHrV5Un67HfUtGk0xYDFKOhUIfcubNrBhC19QUcKynQlWVMEKRqQ C32WnT4lBNs1L6SbO33ypjjRqy63GVlT3tIifw3f0fRjD2mWq16rdIsSLQqCS+7bJM /VInhdZNsa7t4AC4r7Y+iWWy6All/iuk9cdt8Vq5MAwou9msHTH9rcoh+znkR589Xd Vs9NZwUfr43Ux+VSAHSW5RYncBKLVSjhb+l8EEGiFL3yWr7O6+ab/MG84mye0RI6Ws VawmiT99vw/zIO7wJ25YrmoecjWvx7KDq+hVMj59YdJ9fzN3TtW57ujgUJTMWU1ktK 18uQTsW35s0iA== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:24:04 -0000 On 7/23/13 12:00 AM, Christian Groves wrote: > Hello Paul, > > "Audio and video don't "compete" with one another." Currently priorities > can be set across all capture types. E.g. I can say that's more > important for you to get an audio stream and a presentation stream than > it is to get the video if you have to choose because of some > bandwidth/display/etc contraint. It wouldn't be possible if you consider > priority to be scoped to a single media. OK. So they do compete with one another for bandwidth. So maybe if that is a constraint you may want to take that into account. But isn't video bw usually so much higher than audio bw that audio bw is insignificant to the decisions? If we think video and audio should be sorted together for prioritization then it is going to complicate assigning priorities. As I commented to mark, how to select captures is starting to look very complex. We also have the problem of how to select audio captures that "go with" particular video captures. I guess priorities might be one way to do that. Some sort of spatial information might be another. Thanks Paul > Regards, Christian > > On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >> On 7/22/13 8:41 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> I agree that a default is needed. >>> >>> The reason for a "no priority" I saw a case where an Advertiser for >>> example may offer prioritised audio but choose not to prioritise video >>> or vice versa. Rather than prioritise audio over video or vice versa >>> which would effectively happen if all captures had a default priority >>> level. >> >> Audio and video don't "compete" with one another. I can't see how the >> priority processing of one would interact with the other. >> >> Perhaps we need to say something that audio and video are >> independently prioritized. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>> A couple of things I picked up while reviewing this version: >>>> >>>> Section 3 & Section 22: >>>> >>>> The schema was updated so captureEncodingType references >>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>> so that the intended definition of encodingParametersType actually >>>> redefines captureParametersType. >>>> >>>> Section 10.7 : >>>> >>>> ... The higher the >>>> importance, the lower the contained value. When media captures are >>>> marked with a "0" priority value, it means that they are "not >>>> subject >>>> to priority". >>>> >>>> [edt's note: discussion needed] >>>> >>>> IMO it makes no sense for some captures to be subject to priority and >>>> others to not be subject to priority. What would that mean? The only >>>> thing I can see is that those are *mandatory* to render. But we can't >>>> really mandate that. If you can't do it we can't force you. So the >>>> best it could mean is "really really important" to render. But that is >>>> the same as having the highest priority. >>>> >>>> So I suggest that zero is just the highest priority - no more, no less. >>>> >>>> And I suggest we also make zero the *default* priority, so that all >>>> captures have one, implicitly or explicitly. Then, if you don't >>>> mention priority at all, then all captures are equal. And you can just >>>> add priority for those captures that are less important. >>>> >>>> Equivalently, we could leave priority optional, and specify that the >>>> absence of a priority implicitly means the highest priority. Then the >>>> presence of priority means a lower priority. But I think this >>>> formulation is a little more confusing to explain. >>>> >>>> Section 10.10. : >>>> >>>> is an optional element indicating wheter or not the >>>> capture device originating the capture moves during the telepresence >>>> session. ... >>>> >>>> We can't know for sure that it will move, only that it may. Also a >>>> typo. So: >>>> >>>> s/moves/may move/ >>>> s/wheter/whether/ >>>> >>>> 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 john@jlc.net Thu Jul 25 15:35:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B69B21F84B6 for ; Thu, 25 Jul 2013 15:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXWs1nb9Zc8j for ; Thu, 25 Jul 2013 15:35:21 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F208421F849C for ; Thu, 25 Jul 2013 15:35:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9927633C23; Thu, 25 Jul 2013 18:35:20 -0400 (EDT) Date: Thu, 25 Jul 2013 18:35:20 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20130725223520.GC8295@verdi> References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F1878E.2040703@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:35:26 -0000 Paul Kyzivat wrote: > > I am commenting from the perspective of somebody who knows nothing > special about audio... Fundamentally, audio is pressure-changes in the air itself. These propagate (at the speed of sound) in every direction and reflect off most surfaces. > On 7/25/13 4:04 PM, John Leslie wrote: > >> - "Area of Capture" makes no sense to me for audio. > > That has troubled me for some time. Glad to hear it isn't just me. > >> - "Point on capture axis" makes no sense to me unless there is also a >> "sensitivity pattern". > > I guess there are omnidirectional mics where axis of capture makes no > sense. Not so. There is a "generic omnidirectional" sensitivity pattern which has a definite axis of capture; but it is _not_ equal in every direction. > But in my naive view I would think that most mics have some directional > sensitivity and that knowing the axis would be "better than nothing". Indeed, all microphones have directional sensitivity. "Generic cardioad" is a more pronounced pattern than "generic omnidirectional;" but they both are optimized for best fidelity on the axis of capture. >> I don't expect folks to use sensitivity patterns within the next year >> or two. Using "generic omni" and "generic cardioid" would be a good thing: I merely don't expect it. The difference is nowhere nearly as great as folks think it is. > ISTM that we need to provide *something* that will help the consumer to > decide which audio captures to choose if it can't choose them all, and > how to assign them to the speakers it has. I don't know what that > something is. There _should_ be a "room mix" to gather "everything in the room". This may be monaural, stereo, or surround; and adapting from one of these to another is straightforward. > The one advantage of area of capture for audio is that if you pick a > particular video capture then you might want to look for an audio > capture that covers that area. Alas, there is no standard way to specify "area" covered by a microphone. Unless we can define one, any such parameter would be less than useful. > Axis of capture might also be used as a hint in the same way. But I > realize that is naive. It, at least, has a meaning. In point of fact, nearest point-of- capture is your best bet -- even if the mike in question is cardioid and you're >90 degrees off-axis. If you really care about this, I strongly recommend keeping "point on axis of capture" and adding "sensitivity pattern" -- at least "generic omni" and "generic cardioid". -- John Leslie From pkyzivat@alum.mit.edu Thu Jul 25 15:49:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDBB21F9130 for ; Thu, 25 Jul 2013 15:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuijzTN6pxZR for ; Thu, 25 Jul 2013 15:48:59 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8787821F8A85 for ; Thu, 25 Jul 2013 15:48:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id 4mmr1m0041ZXKqc56moz2u; Thu, 25 Jul 2013 22:48:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 4moy1m00Y3ZTu2S3hmoyTy; Thu, 25 Jul 2013 22:48:59 +0000 Message-ID: <51F1AB5A.5090403@alum.mit.edu> Date: Thu, 25 Jul 2013 18:48:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Leslie References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> In-Reply-To: <20130725223520.GC8295@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374792539; bh=n1aojiGKVIe0nbjdpHvb3RTgN95eVqeB+Spb5bnPiM4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MKZDoJ5NloLfu1eSgZ5ESyKvMr57v3QNfNf7YDOF0L6h7QQchcWBkjKhrPtn/uqOQ 6MFEcTge5P5cgcbVuxkUuh0Sxa6hpkEijg8S7BnFBSqCTNlXkcwW/fP7JP1qHU5yAU YV45TVpU1s5HXzXoW8i15DmLoIi85Wl8IXkoaTZ+PziKM6fXqWrcvyqj0ShoygVrsJ kRX7z9W6sAquopXsWTYVYtKm2cW/BFN7i7qMOrOrAyQXMdoWDO3NvKkcwD8nr8e802 Ns6ONHv4NbOO9zKOk2Zz8f283xOGbc4IiufeBjG60pnMXkgUcYLH+ovvbiDXyzH7F5 8rNixSpnkMUpw== Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:49:05 -0000 To cut to the chase... I think John should make a proposal for what we ought to have in the fw & data model for this, that will be "enough" without going overboard. I don't sense that anybody else here is competent to make this call. Thanks, Paul (as co-chair) On 7/25/13 6:35 PM, John Leslie wrote: > Paul Kyzivat wrote: >> >> I am commenting from the perspective of somebody who knows nothing >> special about audio... > > Fundamentally, audio is pressure-changes in the air itself. These > propagate (at the speed of sound) in every direction and reflect off > most surfaces. > >> On 7/25/13 4:04 PM, John Leslie wrote: >> >>> - "Area of Capture" makes no sense to me for audio. >> >> That has troubled me for some time. Glad to hear it isn't just me. >> >>> - "Point on capture axis" makes no sense to me unless there is also a >>> "sensitivity pattern". >> >> I guess there are omnidirectional mics where axis of capture makes no >> sense. > > Not so. There is a "generic omnidirectional" sensitivity pattern > which has a definite axis of capture; but it is _not_ equal in every > direction. > >> But in my naive view I would think that most mics have some directional >> sensitivity and that knowing the axis would be "better than nothing". > > Indeed, all microphones have directional sensitivity. "Generic > cardioad" is a more pronounced pattern than "generic omnidirectional;" > but they both are optimized for best fidelity on the axis of capture. > >>> I don't expect folks to use sensitivity patterns within the next year >>> or two. > > Using "generic omni" and "generic cardioid" would be a good thing: > I merely don't expect it. The difference is nowhere nearly as great as > folks think it is. > >> ISTM that we need to provide *something* that will help the consumer to >> decide which audio captures to choose if it can't choose them all, and >> how to assign them to the speakers it has. I don't know what that >> something is. > > There _should_ be a "room mix" to gather "everything in the room". > This may be monaural, stereo, or surround; and adapting from one of > these to another is straightforward. > >> The one advantage of area of capture for audio is that if you pick a >> particular video capture then you might want to look for an audio >> capture that covers that area. > > Alas, there is no standard way to specify "area" covered by a > microphone. Unless we can define one, any such parameter would be > less than useful. > >> Axis of capture might also be used as a hint in the same way. But I >> realize that is naive. > > It, at least, has a meaning. In point of fact, nearest point-of- > capture is your best bet -- even if the mike in question is cardioid > and you're >90 degrees off-axis. > > If you really care about this, I strongly recommend keeping > "point on axis of capture" and adding "sensitivity pattern" -- at > least "generic omni" and "generic cardioid". > > -- > John Leslie > From john@jlc.net Thu Jul 25 15:50:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6521F8F67 for ; Thu, 25 Jul 2013 15:50:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfmb8bew2Z4V for ; Thu, 25 Jul 2013 15:50:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D021B21F9130 for ; Thu, 25 Jul 2013 15:50:51 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 453A733C23; Thu, 25 Jul 2013 18:50:51 -0400 (EDT) Date: Thu, 25 Jul 2013 18:50:51 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20130725225051.GA3328@verdi> References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4EA9@CRPMBOXPRD07.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D601FE4EA9@CRPMBOXPRD07.polycom.com> User-Agent: Mutt/1.4.1i Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:50:57 -0000 Duckworth, Mark wrote: > > ... that was part of the original motivation for using area of > capture for any media capture, not just video. Also we expected this > information to be useful for rendering, so the renderer could use > this area information to mix received audio encodings into its > loudspeakers in a spatially meaningful way. _Somebody's_ hands are waving here... When mixing audio, you aim for a limited number of sources; and aim for a constant apparent room acoustic. The video can jump around quite a bit; but the audio needs to "feel" constant. In a dialogue, the two actors are "placed" in positions and _stay_there_ as far as the audio is concerned. Either or both actors may be shown by any number of cameras (some moving) without dis-orienting the audience; but if the audio tries to "follow" the cameras (whatever that might mean) the audience gets confused. > The simple use case for this is for TIP-like multi-channel audio, > where there is a left, center, and right channel that are separately > available and separately switchable. I advise _great_ care in "switching". Done too frequently, the audience won't be able to follow it. > It seems to me area of capture and/or axis of capture is still > useful for this limited purpose. Axis of capture can be useful, but excessive switching will still confuse the audience. Professionals try to depend on a mike as close as possible to the speaker; then _mix_ that into the multi-channel audio in a way to keep the apparent location constant. -- John Leslie From pkyzivat@alum.mit.edu Thu Jul 25 17:23:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6269921F844D for ; Thu, 25 Jul 2013 17:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caZsOJDos6QL for ; Thu, 25 Jul 2013 17:23:13 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1021F8447 for ; Thu, 25 Jul 2013 17:23:13 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4nzG1m0020QuhwU5DoPCsZ; Fri, 26 Jul 2013 00:23:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 4oPC1m00n3ZTu2S3NoPCDY; Fri, 26 Jul 2013 00:23:12 +0000 Message-ID: <51F1C16F.1060901@alum.mit.edu> Date: Thu, 25 Jul 2013 20:23:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D601FE4EA9@CRPMBOXPRD07.polycom.com> <20130725225051.GA3328@verdi> In-Reply-To: <20130725225051.GA3328@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374798192; bh=kjg08DkAemIg/D1iQQPai55fY/VpcboeTqToWzE0JMI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jQiQPQa7N8pAW34noBuOyi2dxjXn8Tg5tMQU/jBW7jy0VzZDzHZSvahFMPNWQgU+j pS7LzAXZdPg6WXW/SUbToARvsxQD60bFlyeOK1f4LBj8wbPd6KDiUn2BpVK1cC5P06 OtZTCmYwtvaEqujiqry5+RbmhfuFq1gOlPU1TpoCu34b0ebBV49YgerEVAcOx8iwQ8 x3AZUxu2nurWBCYtPLE0ya3iGs1PV8YvmjMdVCp7xgU0DwzwiD0dmKwYMfeFY0vlZp iGHtG1KWzSifQzz31FKlX3cuZYAzw0s3DdCDmQMKWvLV+9WoRA4sIkW5CdkIw+hB8R Z2fSXA2NT7XvQ== Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 00:23:18 -0000 John, If we are doing site switching based on voice activity, then surely we must switch the audio to match, right? I guess what you are saying might pertain if we are switching among cameras in a single room. Thanks, Paul On 7/25/13 6:50 PM, John Leslie wrote: > Duckworth, Mark wrote: >> >> ... that was part of the original motivation for using area of >> capture for any media capture, not just video. Also we expected this >> information to be useful for rendering, so the renderer could use >> this area information to mix received audio encodings into its >> loudspeakers in a spatially meaningful way. > > _Somebody's_ hands are waving here... > > When mixing audio, you aim for a limited number of sources; and > aim for a constant apparent room acoustic. The video can jump around > quite a bit; but the audio needs to "feel" constant. In a dialogue, > the two actors are "placed" in positions and _stay_there_ as far as > the audio is concerned. Either or both actors may be shown by any > number of cameras (some moving) without dis-orienting the audience; > but if the audio tries to "follow" the cameras (whatever that might > mean) the audience gets confused. > >> The simple use case for this is for TIP-like multi-channel audio, >> where there is a left, center, and right channel that are separately >> available and separately switchable. > > I advise _great_ care in "switching". Done too frequently, the > audience won't be able to follow it. > >> It seems to me area of capture and/or axis of capture is still >> useful for this limited purpose. > > Axis of capture can be useful, but excessive switching will still > confuse the audience. Professionals try to depend on a mike as close > as possible to the speaker; then _mix_ that into the multi-channel > audio in a way to keep the apparent location constant. > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Jul 25 22:13:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6921F8476 for ; Thu, 25 Jul 2013 22:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMLtLzHa1anc for ; Thu, 25 Jul 2013 22:13:02 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC521F8475 for ; Thu, 25 Jul 2013 22:13:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADgE8lF20ep2/2dsb2JhbAANTYM7vjaBLIMYAQEBAwEBAQE1GxsKBgsLGAkWDwkDAgECARUwEwYCAQGIBhKmXZIxBJAEhAADlAiYSg Received: from ppp118-209-234-118.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.234.118]) by ipmail06.adl6.internode.on.net with ESMTP; 26 Jul 2013 14:42:59 +0930 Message-ID: <51F20553.8030101@nteczone.com> Date: Fri, 26 Jul 2013 15:12:51 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> In-Reply-To: <51F1A34D.80400@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 05:13:02 -0000 Hello Roberta and Paul, Please see my comments below. Regards, Christian On 26/07/2013 8:14 AM, Paul Kyzivat wrote: > On 7/23/13 7:39 AM, Roberta Presta wrote: >> Hi all, >> >> another possibility is the following. >> Priority is an optional attribute. >> When it is absent, it is intended to be "the lowest priority". >> When it is present, you have to order the priority values in a way that >> the most important capture has the lowest numeric value. [CNG] What do you mean by "is present"? If an endpoint needs to set the priority on one capture does this mean it is forced to set the priority on all the captures? >> >> >> For example, if I have >> - the audio of the lecturer AC0, >> - the video of the lecturer VC0, >> - the video of the slides VC1, >> - the video of the overall room VC2 >> and I want to prioritize the audio of the lecturer, and then the video >> of the slides, I can set the priority values as follows: >> - AC0, priority = 1 >> - VC1, priority = 2 >> - other captures, no priority >> >> The media consumer will know that: >> - the most important capture is AC0 >> - the second one is VC1 >> - all the other captures have the same level of importance, which is >> lower than the one of AC0 and VC1. >> >> What is your feeling about it? [CNG] It makes sense. I think the test is how the logic works for multiple captures for each media type. I've thought about that aspect an I couldn't see an issue. I think you have to assume that the consumer will not use the priority exclusively to determine which capture it wants. >> Cheers, > > It "works". The key advantage is that it provides a concise way to > specify "lowest priority". Without this, the lowest priority could be > specified as the maximum allowable priority value. (Is there an upper > bound for unsigned int? 2^32-1?) [CNG] Perhaps we should just make this a btye 0-255 possible values? And perhaps we need to say there is no inference to how much more important the priority based on the position. e.g. 1 is not 100x times more important than 100. If you have two captures one with priority 1 and the other priority 100 the priority one capture is simply more important. No difference to 1 & 2, 1 & 50 etc. > > Implementations are going to need a representation for all values, > including the highest and lowest. [CNG] Strictly speaking we probably only need the "highest" priority. The lowest is effectively the number before or after (depending on whether 1 is highest or not) those that have been set in the captures. > If we are to represent priorities as unsigned integers, then I think > both lowest and highest should fall into that range so that the > implementation can use an unsigned integer too. So *if* we want the > default to be lowest priority, then I would vote that we make the > default be the highest value representable in the range, rather than > something lower than that. > > I guess the question is whether we want the default to be highest > priority or lowest priority. [CNG] I think the "lowest priority". > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Fri Jul 26 01:41:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D021F873C for ; Fri, 26 Jul 2013 01:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DkO6Rt4oJmn for ; Fri, 26 Jul 2013 01:41:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3ADD21F860B for ; Fri, 26 Jul 2013 01:41:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-86-51f2364ee06b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B0.0E.00725.E4632F15; Fri, 26 Jul 2013 10:41:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 10:41:50 +0200 From: Christer Holmberg To: Paul Kyzivat , clue_ietf.org Thread-Topic: [clue] draft-ietf-clue-data-model-schema-00 Thread-Index: AQHOhvHyMuMhgIzqgE6akD2JS6NELZlxS0wAgAAjaoCAABQYAIAAgGOAgAPfggf///cygIAA0CdA Date: Fri, 26 Jul 2013 08:41:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40A7D0@ESESSMB209.ericsson.se> References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com>, <51EE6B77.2060601@unina.it> <7594FB04B1934943A5C02806D1A2204B1C409F43@ESESSMB209.ericsson.se>, <51F1A3D1.3070905@alum.mit.edu> In-Reply-To: <51F1A3D1.3070905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40A7D0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra6/2adAg7fLmC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjddsploIdvYwVd9fcYmxgXFPRxcjJISFg InF96VlmCFtM4sK99WwgtpDAYUaJZXPTuxi5gOwljBK3l75j6mLk4GATsJDo/qcNUiMi4C7x fN8UVhBbGCjc3reEGSJuKbF9Zh8LhB0lceDrbLA4i4CqxJqZu8HqeQV8Jb4d3MYEsauPSeLe sgwQm1NAR+LfuvVgvYxA93w/tQashllAXOLWk/lMEHcKSCzZcx7qZlGJl4//sULU5Ess+7GA EWK+oMTJmU9YJjAKz0LSPgtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI3tu YmZOernhJkZgjBzc8lt3B+OpcyKHGKU5WJTEeTfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwOi5/3pxklVm74c5DgK1K+wfb+Gr1W11nC/Bp1gR9X/O5Z9+S6e8DGQM+CnF0bS0xDyo X7VD4ZXHi9V/Wpnv7WefkDpz+bHv7pWVLJcvOn01stk/d8EqwRWX1i/1eWrvdnyFwY6Q8L7O FmOHFvtV+a/WHoi4/OIRv8zj/nrNdwKmhSvuhz3drqzEUpyRaKjFXFScCAAiPNYQXwIAAA== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:41:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40A7D0ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We can define all kind of attributes, but what case is this needed for? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: clue@ietf.org [clue@ietf.org] Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 On 7/25/13 4:48 PM, Christer Holmberg wrote: > Hi, > Even if the advertiser thinks something has priority, the consumer may > have another opinion. > Isn't the role/content information supposed to describe what content is > associated with the capture, and then the consumer chooses what it wants > - based on its own priorities? Its another attribute that the consumer can consider (or ignore). Thanks Paul > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Roberta Presta [roberta.presta@unina.it] > *To:* clue@ietf.org [clue@ietf.org] > *Subject:* Re: [clue] draft-ietf-clue-data-model-schema-00 > Hi all, > > another possibility is the following. > Priority is an optional attribute. > When it is absent, it is intended to be "the lowest priority". > When it is present, you have to order the priority values in a way that > the most important capture has the lowest numeric value. > > For example, if I have > - the audio of the lecturer AC0, > - the video of the lecturer VC0, > - the video of the slides VC1, > - the video of the overall room VC2 > and I want to prioritize the audio of the lecturer, and then the video > of the slides, I can set the priority values as follows: > - AC0, priority =3D 1 > - VC1, priority =3D 2 > - other captures, no priority > > The media consumer will know that: > - the most important capture is AC0 > - the second one is VC1 > - all the other captures have the same level of importance, which is > lower than the one of AC0 and VC1. > > What is your feeling about it? > Cheers, > > Roberta > > > Il 23/07/2013 06:00, Christian Groves ha scritto: >> Hello Paul, >> >> "Audio and video don't "compete" with one another." Currently >> priorities can be set across all capture types. E.g. I can say that's >> more important for you to get an audio stream and a presentation >> stream than it is to get the video if you have to choose because of >> some bandwidth/display/etc contraint. It wouldn't be possible if you >> consider priority to be scoped to a single media. >> >> Regards, Christian >> >> On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >>> On 7/22/13 8:41 PM, Christian Groves wrote: >>>> Hello Paul, >>>> >>>> I agree that a default is needed. >>>> >>>> The reason for a "no priority" I saw a case where an Advertiser for >>>> example may offer prioritised audio but choose not to prioritise video >>>> or vice versa. Rather than prioritise audio over video or vice versa >>>> which would effectively happen if all captures had a default priority >>>> level. >>> >>> Audio and video don't "compete" with one another. I can't see how the >>> priority processing of one would interact with the other. >>> >>> Perhaps we need to say something that audio and video are >>> independently prioritized. >>> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>>> A couple of things I picked up while reviewing this version: >>>>> >>>>> Section 3 & Section 22: >>>>> >>>>> The schema was updated so captureEncodingType references >>>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>>> so that the intended definition of encodingParametersType actually >>>>> redefines captureParametersType. >>>>> >>>>> Section 10.7 : >>>>> >>>>> ... The higher the >>>>> importance, the lower the contained value. When media captures ar= e >>>>> marked with a "0" priority value, it means that they are "not >>>>> subject >>>>> to priority". >>>>> >>>>> [edt's note: discussion needed] >>>>> >>>>> IMO it makes no sense for some captures to be subject to priority and >>>>> others to not be subject to priority. What would that mean? The only >>>>> thing I can see is that those are *mandatory* to render. But we can't >>>>> really mandate that. If you can't do it we can't force you. So the >>>>> best it could mean is "really really important" to render. But that i= s >>>>> the same as having the highest priority. >>>>> >>>>> So I suggest that zero is just the highest priority - no more, no >>>>> less. >>>>> >>>>> And I suggest we also make zero the *default* priority, so that all >>>>> captures have one, implicitly or explicitly. Then, if you don't >>>>> mention priority at all, then all captures are equal. And you can jus= t >>>>> add priority for those captures that are less important. >>>>> >>>>> Equivalently, we could leave priority optional, and specify that the >>>>> absence of a priority implicitly means the highest priority. Then the >>>>> presence of priority means a lower priority. But I think this >>>>> formulation is a little more confusing to explain. >>>>> >>>>> Section 10.10. : >>>>> >>>>> is an optional element indicating wheter or not the >>>>> capture device originating the capture moves during the >>>>> telepresence >>>>> session. ... >>>>> >>>>> We can't know for sure that it will move, only that it may. Also a >>>>> typo. So: >>>>> >>>>> s/moves/may move/ >>>>> s/wheter/whether/ >>>>> >>>>> 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 --_000_7594FB04B1934943A5C02806D1A2204B1C40A7D0ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
We can define all kind of attributes, but what = case is this needed for?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: clue@ietf.org [clue@ietf.org]
Subject: Re: [clue] draft-ietf-clue-data-model-schema-00
On 7/25/13 4:48 PM, Christer Holmberg wrote:
> Hi,
> Even if the advertiser thinks something has priority, the consumer may=
> have another opinion.
> Isn't the role/content information supposed to describe what content i= s
> associated with the capture, and then the consumer chooses what it wan= ts
> - based on its own priorities?

Its another attribute that the consumer can consider (or ignore).

        Thanks
        Paul

> Regards,
> Christer
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Roberta Presta [roberta.presta@unina.it]
> *To:* clue@ietf.org [clue@ietf.org]
> *Subject:* Re: [clue] draft-ietf-clue-data-model-schema-00
> Hi all,
>
> another possibility is the following.
> Priority is an optional attribute.
> When it is absent, it is intended to be "the lowest priority"= ;.
> When it is present, you have to order the priority values in a way tha= t
> the most important capture has the lowest numeric value.
>
> For example, if I have
> - the audio of the lecturer AC0,
> - the video of the lecturer VC0,
> - the video of the slides VC1,
> - the video of the overall room VC2
> and I want to prioritize the audio of the lecturer, and then the video=
> of the slides, I can set the priority values as follows:
> - AC0, priority =3D 1
> - VC1, priority =3D 2
> - other captures, no priority
>
> The media consumer will know that:
> - the most important capture is AC0
> - the second one is VC1
> - all the other captures have the same level of importance, which is > lower than the one of  AC0 and VC1.
>
> What is your feeling about it?
> Cheers,
>
> Roberta
>
>
> Il 23/07/2013 06:00, Christian Groves ha scritto:
>> Hello Paul,
>>
>> "Audio and video don't "compete" with one another.&= quot; Currently
>> priorities can be set across all capture types. E.g. I can say tha= t's
>> more important for you to get an audio stream and a presentation >> stream than it is to get the video if you have to choose because o= f
>> some bandwidth/display/etc contraint. It wouldn't be possible if y= ou
>> consider priority to be scoped to a single media.
>>
>> Regards, Christian
>>
>> On 23/07/2013 12:48 PM, Paul Kyzivat wrote:
>>> On 7/22/13 8:41 PM, Christian Groves wrote:
>>>> Hello Paul,
>>>>
>>>> I agree that a default is needed.
>>>>
>>>> The reason for a "no priority" I saw a case wher= e an Advertiser for
>>>> example may offer prioritised audio but choose not to prio= ritise video
>>>> or vice versa. Rather than prioritise audio over video or = vice versa
>>>> which would effectively happen if all captures had a defau= lt priority
>>>> level.
>>>
>>> Audio and video don't "compete" with one another. I = can't see how the
>>> priority processing of one would interact with the other.
>>>
>>> Perhaps we need to say something that audio and video are
>>> independently prioritized.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Regards, Christian
>>>>
>>>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote:
>>>>> A couple of things I picked up while reviewing this ve= rsion:
>>>>>
>>>>> Section 3 & Section 22:
>>>>>
>>>>> The schema was updated so captureEncodingType referenc= es
>>>>> encodingParametersType, but there is a typo (cut/paste= error I guess)
>>>>> so that the intended definition of encodingParametersT= ype actually
>>>>> redefines captureParametersType.
>>>>>
>>>>> Section 10.7 <priority>:
>>>>>
>>>>>    ... The higher the
>>>>>    importance, the lower the contained = value.  When media captures are
>>>>>    marked with a "0" priority= value, it means that they are "not
>>>>> subject
>>>>>    to priority".
>>>>>
>>>>>    [edt's note: discussion needed]
>>>>>
>>>>> IMO it makes no sense for some captures to be subject = to priority and
>>>>> others to not be subject to priority. What would that = mean? The only
>>>>> thing I can see is that those are *mandatory* to rende= r. But we can't
>>>>> really mandate that. If you can't do it we can't force= you. So the
>>>>> best it could mean is "really really important&qu= ot; to render. But that is
>>>>> the same as having the highest priority.
>>>>>
>>>>> So I suggest that zero is just the highest priority - = no more, no
>>>>> less.
>>>>>
>>>>> And I suggest we also make zero the *default* priority= , so that all
>>>>> captures have one, implicitly or explicitly. Then, if = you don't
>>>>> mention priority at all, then all captures are equal. = And you can just
>>>>> add priority for those captures that are less importan= t.
>>>>>
>>>>> Equivalently, we could leave priority optional, and sp= ecify that the
>>>>> absence of a priority implicitly means the highest pri= ority. Then the
>>>>> presence of priority means a lower priority. But I thi= nk this
>>>>> formulation is a little more confusing to explain.
>>>>>
>>>>> Section 10.10. <mobility>:
>>>>>
>>>>>    <mobility> is an optional elem= ent indicating wheter or not the
>>>>>    capture device originating the captu= re moves during the
>>>>> telepresence
>>>>>    session.  ...
>>>>>
>>>>> We can't know for sure that it will move, only that it= may. Also a
>>>>> typo. So:
>>>>>
>>>>> s/moves/may move/
>>>>> s/wheter/whether/
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org
>>>>>= https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>>http= s://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.iet= f.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1C40A7D0ESESSMB209erics_-- From roberta.presta@unina.it Fri Jul 26 02:17:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44221F8F29 for ; Fri, 26 Jul 2013 02:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A4VL-dJXxCU for ; Fri, 26 Jul 2013 02:17:40 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5B21F86B2 for ; Fri, 26 Jul 2013 02:17:35 -0700 (PDT) Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r6Q9HV5a019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 11:17:32 +0200 Message-ID: <51F23EAC.6020309@unina.it> Date: Fri, 26 Jul 2013 11:17:32 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51F1A57D.5040405@alum.mit.edu> In-Reply-To: <51F1A57D.5040405@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130725-1, 25/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 09:17:46 -0000 Hi Paul, Il 26/07/2013 00:23, Paul Kyzivat ha scritto: > We also have the problem of how to select audio captures that "go > with" particular video captures. I guess priorities might be one way > to do that. Some sort of spatial information might be another. > I think a mechanism to associate a capture to another one is needed or at least it is worth to be discussed. We have currently two mechanisms to group captures semantically: 1) putting them into the same capture scene 2) using the tag to indicate that a capture is linked to another one. The first one is coarse-grained, while the second one has been conceived for linking "secondary" information, such as subtitles or translations, to a "primary" capture, like for example the lecturer's audio. However, we could exploit such element to link an audio capture to a video capture. For example you could have the audio of the presenter - AC0, and the video of the presenter is marked with a field containing AC0, and/or viceversa. Alternatively, we can design a specialized field to do the task. Capture scene entries have been designed to group captures of the same media type, so we can not use them to answer that need. How do you think priority and spatial information could be used to couple captures together? For example, if we force captures that go together to have the same priority, we are "overloading" the meaning and probably making the priority settings (and its interpretation) even more complex. Cheers, Roberta From roberta.presta@unina.it Fri Jul 26 03:35:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7046B21F8C66 for ; Fri, 26 Jul 2013 03:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_24=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEi1a6SJ8+eV for ; Fri, 26 Jul 2013 03:35:27 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4921D21F87B7 for ; Fri, 26 Jul 2013 03:35:25 -0700 (PDT) Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6QAZLgE015825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 12:35:23 +0200 Message-ID: <51F250EB.4060802@unina.it> Date: Fri, 26 Jul 2013 12:35:23 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> In-Reply-To: <51F20553.8030101@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130725-1, 25/07/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:35:33 -0000 Hi Christian, please see inline. Il 26/07/2013 07:12, Christian Groves ha scritto: > > On 26/07/2013 8:14 AM, Paul Kyzivat wrote: >> On 7/23/13 7:39 AM, Roberta Presta wrote: >>> Hi all, >>> >>> another possibility is the following. >>> Priority is an optional attribute. >>> When it is absent, it is intended to be "the lowest priority". >>> When it is present, you have to order the priority values in a way that >>> the most important capture has the lowest numeric value. > [CNG] What do you mean by "is present"? If an endpoint needs to set > the priority on one capture does this mean it is forced to set the > priority on all the captures? > [RP] No, the media provider is not forced to set the priority on all the captures. The media provider can mark the captures that, according to its point of view, are the most relevant ones. The other captures are left without the element - it means that they are not carrying the main information, from the provider perspective. By this way the media provider is making a suggestion to the media consumer. >>> >>> >>> For example, if I have >>> - the audio of the lecturer AC0, >>> - the video of the lecturer VC0, >>> - the video of the slides VC1, >>> - the video of the overall room VC2 >>> and I want to prioritize the audio of the lecturer, and then the video >>> of the slides, I can set the priority values as follows: >>> - AC0, priority = 1 >>> - VC1, priority = 2 >>> - other captures, no priority >>> >>> The media consumer will know that: >>> - the most important capture is AC0 >>> - the second one is VC1 >>> - all the other captures have the same level of importance, which is >>> lower than the one of AC0 and VC1. >>> >>> What is your feeling about it? > [CNG] It makes sense. I think the test is how the logic works for > multiple captures for each media type. I've thought about that aspect > an I couldn't see an issue. I think you have to assume that the > consumer will not use the priority exclusively to determine which > capture it wants. > [RP] I totally agree on the fact that the consumer will not use exclusively to select the captures it needs. >> >> It "works". The key advantage is that it provides a concise way to >> specify "lowest priority". Without this, the lowest priority could be >> specified as the maximum allowable priority value. (Is there an upper >> bound for unsigned int? 2^32-1?) [RP] Yes, that is the upper bound. > [CNG] Perhaps we should just make this a btye 0-255 possible values? [RP] We can use "unsignedByte" as xs:type in that case. > And perhaps we need to say there is no inference to how much more > important the priority based on the position. e.g. 1 is not 100x times > more important than 100. If you have two captures one with priority 1 > and the other priority 100 the priority one capture is simply more > important. No difference to 1 & 2, 1 & 50 etc. > [RP] +1. >> Implementations are going to need a representation for all values, >> including the highest and lowest. > [CNG] Strictly speaking we probably only need the "highest" priority. > The lowest is effectively the number before or after (depending on > whether 1 is highest or not) those that have been set in the captures. > [RP] The values (highest and lowest) should be defined both. >> If we are to represent priorities as unsigned integers, then I think >> both lowest and highest should fall into that range so that the >> implementation can use an unsigned integer too. So *if* we want the >> default to be lowest priority, then I would vote that we make the >> default be the highest value representable in the range, rather than >> something lower than that. >> >> I guess the question is whether we want the default to be highest >> priority or lowest priority. > [CNG] I think the "lowest priority". > [RP] I agree with Paul, we have to arrange the priority interpretation, otherwise talking about the lowest priority and the highest priority is misleading. What is the clearest definition between the following alternatives? "the highest value = the highest relevance score (e.g. 255)" or "the highest value = the first relevance rank (e.g. 1)" ? Thanks, Roberta From mary.ietf.barnes@gmail.com Fri Jul 26 04:30:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4AA21F8C9D for ; Fri, 26 Jul 2013 04:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N81Lvo6xmCL4 for ; Fri, 26 Jul 2013 04:30:12 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4C74321F8C72 for ; Fri, 26 Jul 2013 04:30:12 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so1516764qcw.15 for ; Fri, 26 Jul 2013 04:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=epzpbSGy2Fb0YgREDKt8i9ZXkQTLbsxdHGB/OkAtgoI=; b=MrgSiWXQsCIr1Eeh6pelrdRIAma2jSn9gXbrHAF6I+H8EyaWGxHQGtXkBla/qh/Ze5 JjQUYfVOxAysLrEA2q6U8uGnLyEeYUsNlD3tQFE795PeBsXpRsXzX8LjVHiEupl0iKmK Q8p9Pg7papr6NY6WHwOXBPM/u1VzClsyWw3EpYfYzIm5H89eEi9FnKuAtgrghBfs6xON 5cCENbAewgFzPD88SPYC6Fm6btBPggFnKPpndCdOXOm9ELM1DC7JKCeXLTTRLu41AY51 /9FWpaAWQYl7nkaQ4dNMPpHeqRS2qUcUKYy9WUjWZBOoGYCpC1gqtnhuk/vhtLm9ZyQ2 oGyw== MIME-Version: 1.0 X-Received: by 10.224.169.3 with SMTP id w3mr22370627qay.13.1374838211754; Fri, 26 Jul 2013 04:30:11 -0700 (PDT) Received: by 10.49.48.42 with HTTP; Fri, 26 Jul 2013 04:30:11 -0700 (PDT) Date: Fri, 26 Jul 2013 06:30:11 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e011823a23c3fc904e2687797 Subject: [clue] CLUE @ IETF-87: Updated Agenda and materials X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 11:30:12 -0000 --089e011823a23c3fc904e2687797 Content-Type: text/plain; charset=ISO-8859-1 There is now an updated agenda available as well as the slides the chairs have received to date. https://datatracker.ietf.org/meeting/87/materials.html Note that the agenda has links to all the relevant drafts. We have a lot to discuss so it's *extremely* important for folks to have read the documents before the WG session. Note. a link to the tar & pdf files that contain all the CLUE WG related docs is also at the top of the agenda so you can pull them all down at once (for reading on the airplane ;) Thanks, Mary. --089e011823a23c3fc904e2687797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is now an updated agenda available as well as the sl= ides the chairs have received to date. =A0

Note that the agenda has links to all the relevan= t drafts. =A0We have a lot to discuss so it's *extremely* important for= folks to have read the documents before the WG session. =A0 Note. a link t= o the tar & pdf files that contain all the CLUE WG related docs is also= at the top of the agenda so you can pull them all down at once (for readin= g on the airplane ;)=A0

Thanks,
Mary.
--089e011823a23c3fc904e2687797-- From stephen.botzko@gmail.com Fri Jul 26 04:52:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27321F937E for ; Fri, 26 Jul 2013 04:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-hjtBEDi6QZ for ; Fri, 26 Jul 2013 04:52:29 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA321F9360 for ; Fri, 26 Jul 2013 04:52:29 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ia10so411507vcb.6 for ; Fri, 26 Jul 2013 04:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6QxK1o1TKUru+Oxud5DOFsd1HqaYmfju0ZIn5HIQ/ZM=; b=flx9jK/D0q0acze4jwR8gG+XGV/dGlJ6WF3/WbKX2oaP0FBgbpXZdJDneXGJXuuNgK h8we1x7+hKM49cZ134joJOFiDpPfbkSdJaSEaLfjt6VdB/1fI9zlo3l4KZRiSiY7H5Ok edom0jCQ3ubD4uM/3VZ4fFfe1Tk8KBVA1E24j8RjHbqgdFxoYBwAMJSFR+gQBYladPh+ CNRZ6X/7CuizHoPvcs3mb+BCe2h1fpU/s9S3olFJobjEUBvCTzv4Y5aHNnHum7zSr2r3 pRBb5vy+DWgTIGlgkGUq5vIJ9tnmZwHeHfYpZ7xQtSadnAly9euyXmYhJWQu8c6fpgFJ gnVA== MIME-Version: 1.0 X-Received: by 10.58.187.4 with SMTP id fo4mr20319094vec.55.1374839547357; Fri, 26 Jul 2013 04:52:27 -0700 (PDT) Received: by 10.220.162.72 with HTTP; Fri, 26 Jul 2013 04:52:27 -0700 (PDT) In-Reply-To: <51EF1C78.6080809@nteczone.com> References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> <092001ce87db$4bb87350$e32959f0$@gmail.com> <51EF1C78.6080809@nteczone.com> Date: Fri, 26 Jul 2013 07:52:27 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b5db9f4d7edae04e268c6fa Cc: clue@ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 11:52:30 -0000 --047d7b5db9f4d7edae04e268c6fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian Per the use case text: >>> "In this case each participant has a fixed "seat" in the virtual room so each participant expects to see a different view having a different participant on his left and right side." >>> This requires the captures from different physical rooms to be related to each other (that is, there needs to be shared "virtual room" coordinate system that is conference-wide). CLUE presently does not have this. One consequence is that gaze awareness is not fully preserved in multipoint layouts. That is, if I am viewing Bob and Alice on my monitors, I can see that Bob is looking at Alice if they are in the same physical room (if I use the capture coordinates to inform my layout). However, I can not see that Bob is looking at Alice if they are in different physical rooms. I don't personally think this needs to be added to the protocol now - preserving third-party gaze awareness throughout the entire conference requires maintaining scale as well the shared coordinate system. The virtual "table" grows with the conference, as that happens the apparent distance across that table gets further, and people are rendered smaller and smaller. Fairly quickly you reach a point where the cost of preserving gaze awareness exceeds the benefit. This should not be surprising, since it happens in a physical meeting as well. Sitting around a table works for small groups, but for large groups it is better to use a classroom seating arrangement. But I think it is a reasonable extensibility test. Steve On Tue, Jul 23, 2013 at 8:14 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > I agree with Steve, although I'm interested in his comment with regards t= o > the location in the virtual room. > > Steve: can you elaborate on what you see the issue is here? > > Regards, Christian > > > On 24/07/2013 6:03 AM, Stephen Botzko wrote: > >> Section 3.7 describes the case where different cameras are aimed at the >> same participant, to get different perspectives. Other systems receive a= nd >> present the capture that gives the correct eye-contact for the display t= hey >> chose to render it on. >> >> The attributes in the framework already allow such captures to be >> signaled and selected. What is perhaps missing is a way for all the >> endpoints to know their assigned location in the virtual room. >> >> I agree with Roni (and the previous mailing list discussion) that this >> use case could be used to test extensibility - so no requirements would = be >> needed. >> >> Steve >> >> On Tue, Jul 23, 2013 at 3:31 PM, Roni Even > ron.even.tlv@gmail.com**>> wrote: >> >> Mary, >> >> It is in the use cases =96 section 3.7, still looking back at the >> mailing list discussion the feeling is this use case is to test >> extensibility of the CLUE solution and there would be no specific >> requirements >> >> Roni >> >> *From:*clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org **] *On >> Behalf Of *Mary Barnes >> *Sent:* 23 July, 2013 8:36 PM >> *To:* clue issue tracker >> *Cc:* CLUE; >> draft-ietf-clue-telepresence-**requirements@tools.ietf.org >> >> > >> *Subject:* Re: [clue] #42: OPEN-6. Multi-view >> >> >> I propose to just close this issue with the answer being "No". I >> don't know even what's meant by that term - it's not used in the >> FW or usecases. >> >> If you have any concerns, or you have more info about what this is >> intended for, please respond no later than August 12, 2013. >> >> Mary. >> >> On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker >> > >> >> wrote: >> >> #42: OPEN-6. Multi-view >> >> Is there a requirement needed? >> >> -- >> ------------------------------**-------+----------------------** >> --------------- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com > >> | >> telepresence- >> Type: enhancement | requirements@tools.ietf.org >> > >> >> Priority: minor | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------**-------+----------------------** >> --------------- >> >> Ticket URL: >> > >> clue >> > >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7b5db9f4d7edae04e268c6fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian

Per the use case text:
>>>
"In this case each par= ticipant has a fixed "seat" in the virtual room so each participa= nt expects to see a different view having a different participant on his le= ft and right side."
>>>
This requires the captures from different physical rooms to= be related to each other (that is, there needs to be shared "virtual = room" coordinate system that is conference-wide).=A0 CLUE presently do= es not have this.=A0 One consequence is that gaze awareness is not fully pr= eserved in multipoint layouts.=A0

That is, if I am viewing Bob and Alice on my monitors, I can see that B= ob is looking at Alice if they are in the same physical room (if I use the = capture coordinates to inform my layout).=A0 However, I can not see that Bo= b is looking at Alice if they are in different physical rooms.

I don't personally think this needs to be added to the protocol now= - preserving third-party gaze awareness throughout the entire conference r= equires maintaining scale as well the shared coordinate system.=A0 The virt= ual "table" grows with the conference, as that happens the appare= nt distance across that table gets further, and people are rendered smaller= and smaller.=A0 Fairly quickly you reach a point where the cost of preserv= ing gaze awareness exceeds the benefit.=A0 This should not be surprising, s= ince it happens in a physical meeting as well.=A0 Sitting around a table wo= rks for small groups, but for large groups it is better to use a classroom = seating arrangement.=A0 But I think it is a reasonable extensibility test.<= br>
Steve

On Tue, Jul 23, 2013 at 8:14 PM= , Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Mary,

I agree with Steve, although I'm interested in his comment with regards= to the location in the virtual room.

Steve: can you elaborate on what you see the issue is here?

Regards, Christian


On 24/07/2013 6:03 AM, Stephen Botzko wrote:
Section 3.7 describes the case where different cameras are aimed at the sam= e participant, to get different perspectives. Other systems receive and pre= sent the capture that gives the correct eye-contact for the display they ch= ose to render it on.

The attributes in the framework already allow such captures to be signaled = and selected. What is perhaps missing is a way for all the endpoints to kno= w their assigned location in the virtual room.

I agree with Roni (and the previous mailing list discussion) that this use = case could be used to test extensibility - so no requirements would be need= ed.

Steve

On Tue, Jul 23, 2013 at 3:31 PM, Roni Even <ron.even.tlv@gmail.com <mailto:ron.even.tlv@gmail.c= om>> wrote:

=A0 =A0 Mary,

=A0 =A0 It is in the use cases =96 section 3.7, still looking back at the =A0 =A0 mailing list discussion the feeling is this use case is to test
=A0 =A0 extensibility of the CLUE solution and there would be no specific =A0 =A0 requirements

=A0 =A0 Roni

=A0 =A0 *From:*c= lue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
=A0 =A0 [mailto:= clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>] *On
=A0 =A0 Behalf Of *Mary Barnes
=A0 =A0 *Sent:* 23 July, 2013 8:36 PM
=A0 =A0 *To:* clue issue tracker
=A0 =A0 *Cc:* CLUE;
=A0 =A0 draft-ietf-clue-telepresence-requirements= @tools.ietf.org
=A0 =A0 <mailto:draft-ietf-clue-telepresence-r= equirements@tools.ietf.org>
=A0 =A0 *Subject:* Re: [clue] #42: OPEN-6. Multi-view


=A0 =A0 I propose to just close this issue with the answer being "No&q= uot;. I
=A0 =A0 don't know even what's meant by that term - it's not us= ed in the
=A0 =A0 FW or usecases.

=A0 =A0 If you have any concerns, or you have more info about what this is<= br> =A0 =A0 intended for, please respond no later than August 12, 2013.

=A0 =A0 Mary.

=A0 =A0 On Tue, Jul 23, 2013 at 10:06 AM, clue issue tracker
=A0 =A0 <trac+clue@trac.tools.ietf.org
=A0 =A0 <mailto:trac+clue@trac.tools.ietf.org>> wrote:

=A0 =A0 #42: OPEN-6. Multi-view

=A0 =A0 Is there a requirement needed?

=A0 =A0 --
=A0 =A0 -------------------------------------+----------------------= ---------------
=A0 =A0 Reporter: | Owner: draft-ietf-clue-
=A0 =A0 mar= y.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com> |
=A0 =A0 telepresence-
=A0 =A0 Type: enhancement | requirements@tools.ietf.org
=A0 =A0 <mailto:requirements@tools.ietf.org>

=A0 =A0 Priority: minor | Status: new
=A0 =A0 Component: telepresence- | Milestone: milestone1
=A0 =A0 requirements | Version:
=A0 =A0 Severity: Active WG Document | Keywords:
=A0 =A0 -------------------------------------+----------------------= ---------------

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


=A0 =A0 _______________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 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

--047d7b5db9f4d7edae04e268c6fa-- From mary.ietf.barnes@gmail.com Fri Jul 26 05:00:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80221F92A5 for ; Fri, 26 Jul 2013 05:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVzhgB-NZD6q for ; Fri, 26 Jul 2013 05:00:13 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D021F91F4 for ; Fri, 26 Jul 2013 05:00:12 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id u12so210404qcx.35 for ; Fri, 26 Jul 2013 05:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0gxnEW+8F0OzHf3/nsHEa8ETb5+F3VNBBoImMpAle6Y=; b=ZAiMSy5WZdNepSVfq+EG3z5e6qzs79B2rupywdYp3F0gx3kz2wzm8yn5JJzdfv4c6A YGF3IZ4YGtKssVCwqzCGGhlttVYSvzQGcKfwMEtalQuxYGaeOl2sWGn+QEU3UzXZ/alD fPWGjS9Q2sMDRyUjEjLOPFm4w6XZWj8uCP5edkZbbuOIR23nGxKUa2IRAwXAT+7ZbHzV JiMKpDs9fXcxg+UEX9HB2e0I1OAegUTnDV/kZsdVcp3R/BSAQzLGtODo2EpyLrKVmdZg XX5rIWNg8J1gZl/WaatQUWiwwSfA0sEZoZJJaceOO13bgxYdICwSl3DmT4QKaamrRN21 Feuw== MIME-Version: 1.0 X-Received: by 10.49.71.99 with SMTP id t3mr37437638qeu.46.1374840011005; Fri, 26 Jul 2013 05:00:11 -0700 (PDT) Received: by 10.49.48.42 with HTTP; Fri, 26 Jul 2013 05:00:10 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C408993@ESESSMB209.ericsson.se> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> <7594FB04B1934943A5C02806D1A2204B1C405C77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C408993@ESESSMB209.ericsson.se> Date: Fri, 26 Jul 2013 07:00:10 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b677f587aa51b04e268e2b3 Cc: CLUE Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 12:00:14 -0000 --047d7b677f587aa51b04e268e2b3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 25, 2013 at 2:01 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I am sure use-cases were discussed at the time, but they may not have been > documented in the draft. Anyway, let's get back to this later. > [MB] As long as folks follow-up on this prior to August 12th.[/MB] > > Also, I am not asking anyone to shut down the WG, but I think we are > allowed to remove requirements etc also at other times than during the > summer vacation months... :) > [MB] Sure. But, it is extremely common for WGs to discuss and close issues in preparation for and right after one of the 3 major meetings we have each year. The fact that the summer meeting often overlaps with vacation months is an issue for many folks. But, many of us have a similar issue with the March meeting since it often overlaps with Spring Break for many of us in the US. As I said before, we can't have blackouts on getting work done. If we did, we would get even less done than we do as is. [/MB] > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Mary Barnes [mary.ietf.barnes@gmail.com] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* CLUE [clue@ietf.org] > *Subject:* Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] > On Wed, Jul 24, 2013 at 2:35 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> I have a concern with removing the requirement at this point. The main >> reason it hasn't been discussed much is because I believe it impacts the >> signaling, rather than the framework. >> > [MB] So, what is your use case. Can you point to a use case in the WG > use case document? My personal opinion is that this is something that > could be added later with extensions - I don't see this as a primary > requirement for CLUE. [/MB] > >> >> Also, in general, keep in mind that July is a main holiday season in >> northern Europe, which means many (including myself, and more or less all >> of my colleagues working on telepresence) aren't able to comment at this >> point. >> > [MB] That's why the deadline for comments for these issues is August 12th. > In the US, there's always someone that is away at any given period during > the summer. We can't shutdown the WG because folks are on holiday. We can > extend deadlines, which was done for these comments. And, given that none > of these issues are new at all, folks have had plenty of time to read the > document at other times and provide comments. [/MB] > >> >> Regards, >> >> Christer >> >> >> >> Sent from *Windows* using *TouchDown* (www.nitrodesk.com) >> >> -----Original Message----- >> *From:* Mary Barnes [mary.ietf.barnes@gmail.com] >> *To:* CLUE [clue@ietf.org] >> *Subject:* Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] >> My suggestion is to just remove this requirement. We haven't discussed >> it at all in the framework as far as I can tell and it's not in the use >> cases. I know we talked about this way, way early on. But, at this point, >> I think we should consider it out of scope. We have the extensibility >> requirement, so I think that's sufficient in terms of not precluding >> additional new behaviors in the future. >> >> If you have any concerns about removing this requirement and closing >> this issue, please respond no later than August 12, 2013. >> >> Thanks, >> Mary. >> >> >> On Tue, Jul 23, 2013 at 9:19 AM, clue issue tracker < >> trac+clue@trac.tools.ietf.org> wrote: >> >>> #37: OPEN 1: Binaural Audio [REQMT-2C] >>> >>> The need to support of binaural >>> audio is unresolved, and the "MUST NOT preclude" language in >>> this requirement is problematic. The authors believe this >>> requirement needs to be either changed or withdrawn, >>> depending on how the issue is resolved. >>> >>> -- >>> >>> -------------------------------------+------------------------------------- >>> Reporter: | Owner: draft-ietf-clue- >>> mary.ietf.barnes@gmail.com | telepresence- >>> Type: enhancement | requirements@tools.ietf.org >>> Priority: major | Status: new >>> Component: telepresence- | Milestone: milestone1 >>> requirements | Version: >>> Severity: Active WG Document | Keywords: >>> >>> -------------------------------------+------------------------------------- >>> >>> Ticket URL: >>> clue >>> >>> >> > --047d7b677f587aa51b04e268e2b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 25, 2013 at 2:01 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,
=A0
I am sure use-cases were discussed at the time,= but they may not have been documented in the draft. Anyway, let's get = back to this later.
[MB] As long as fol= ks follow-up on this prior to August 12th.[/MB]=A0
=A0
Also, I am not asking anyone to shut down the WG, but I think we are a= llowed to remove requirements etc also at other times than during the summe= r vacation months... :)
[MB] =A0Sure. =A0But, = it is extremely common for WGs to discuss and close issues in preparation f= or and right after one of the 3 major meetings we have each year. =A0The fa= ct that the summer meeting often overlaps with vacation months is an issue = for many folks. =A0But, many of us have a similar issue with the March meet= ing since it often overlaps with Spring Break for many of us in the US. =A0= As I said before, we can't have blackouts on getting work done. =A0If w= e did, we would get even less done than we do as is. [/MB]
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: Christer Holmberg [christer.holmberg@erics= son.com]
CC: CLUE [clue@ie= tf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
On Wed, Jul 24, 2013 at 2:35 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,
=A0
I have a concern with removing the requirement = at this point. The main reason it hasn't been discussed much is because= I believe it impacts the signaling, rather than the framework.
[MB] =A0So, what is your use case. =A0Can you point to a use case in t= he WG use case document? =A0My personal opinion is that this is something t= hat could be added later with extensions - I don't see this as a primar= y requirement for CLUE. =A0[/MB]=A0
=A0
Also, in general,=A0keep in mind that July is a= main holiday season in northern Europe, which means many (including myself= , and more or less all of my colleagues working on telepresence) aren't= able to comment at this point.
[MB] That's why the deadline for comments for these issues is Augu= st 12th. =A0In the US, there's always someone that is away at any given= period during the summer. =A0We can't shutdown the WG because folks ar= e on holiday. =A0We can extend deadlines, which was done for these comments. =A0And, given that none of these issues are new a= t all, folks have had plenty of time to read the document at other times an= d provide comments. [/MB]
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Mary Barnes [mary.ietf.barnes@gmail.com]
To: CLUE [clue@ie= tf.org]
Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C]
My suggestion is to just remove this requirement. =A0We ha= ven't discussed it at all in the framework as far as I can tell and it&= #39;s not in the use cases. =A0I know we talked about this way, way early o= n. But, at this point, I think we should consider it out of scope. =A0We have the extensibility requirement, so I think that= 's sufficient in terms of not precluding additional new behaviors in th= e future.=A0

If you have any concerns about removing this requirement and closing t= his issue, please respond no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 9:19 AM, clue issue trac= ker <trac= +clue@trac.tools.ietf.org> wrote:
#37: OPEN 1: Binaural Audio [REQMT-2C]

=A0The need to support of binaural
=A0 audio is unresolved, and the "MUST NOT preclude" language in<= br> =A0 this requirement is problematic. =A0The authors believe this
=A0 requirement needs to be either changed or withdrawn,
=A0 depending on how the issue is resolved.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Owner: =A0draft-ietf-clue-
=A0 mary.ie= tf.barnes@gmail.com =A0 =A0 =A0 =A0 | =A0telepresence-
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0requirements@tools.ie= tf.org
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Stat= us: =A0new
Component: =A0telepresence- =A0 =A0 =A0 =A0 =A0 =A0| =A0Milestone: =A0miles= tone1
=A0 requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Versi= on:
=A0Severity: =A0Active WG Document =A0 =A0 =A0 | =A0 Keywords:
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/37&= gt;
clue <http:= //tools.ietf.org/wg/clue/>




--047d7b677f587aa51b04e268e2b3-- From pkyzivat@alum.mit.edu Fri Jul 26 08:03:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41F11E80FE for ; Fri, 26 Jul 2013 08:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQyAQvQ4nQK0 for ; Fri, 26 Jul 2013 08:03:11 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA711E80F1 for ; Fri, 26 Jul 2013 08:03:05 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4z0s1m00416LCl055335hz; Fri, 26 Jul 2013 15:03:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 53341m01P3ZTu2S3S334z6; Fri, 26 Jul 2013 15:03:05 +0000 Message-ID: <51F28FA7.5090603@alum.mit.edu> Date: Fri, 26 Jul 2013 11:03:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> In-Reply-To: <51F20553.8030101@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374850985; bh=jTGR4h5O1Z4BcCGlRLcG4rYXrr9PA46MlxG1arWPUBw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YkCcJwTOWpFJRZ/7qk+UiDsvkyTxRTf6XI8T7OQ3AiCiS0cAaIciolm24omzwxAJp 1cWrWcy+x+qgyJFIzguNTcWzDkWXeDeMQqxtbcNYchSAjJ34KblFMV4UTAzq1LVTl0 6YJ2dixS9MGiMPeW+V5+fuM5jtZD79tmjghiZBv9+5Yzl4C+ta45OSlaxg5L87CuMf cKk7bB6k8FvrA3vDgEtgMM24dIDvtpMcU34cUPDzuPk8UjfwgXWo3gPDE/gOZF+z1P ENvw0ldbnmZaHQPdCQJhehH+xmqky2PSfID61tpOZg+Ro8WYfejHqratobgRu5aCG8 KfJRBZEksmSJg== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:03:17 -0000 On 7/26/13 1:12 AM, Christian Groves wrote: > [CNG] Perhaps we should just make this a btye 0-255 possible values? And > perhaps we need to say there is no inference to how much more important > the priority based on the position. e.g. 1 is not 100x times more > important than 100. If you have two captures one with priority 1 and the > other priority 100 the priority one capture is simply more important. No > difference to 1 & 2, 1 & 50 etc. Why would we want to restrict to 256 values? To save 3 bytes in the implementation? While people can probably settle with that, why? >> Implementations are going to need a representation for all values, >> including the highest and lowest. > [CNG] Strictly speaking we probably only need the "highest" priority. > The lowest is effectively the number before or after (depending on > whether 1 is highest or not) those that have been set in the captures. The highest is zero, so that is easy. The lowest you can specify is currently 2^32-1. Suppose somebody decides to set some captures to 2^32-1, and leaves some unspecified? What value does the implementation give to them? So just say the the default is 2^32-1, or maxint. XML allows you to put a default in the schema. So we can just use that. This is assuming we want the default to be "lowest priority". If the default is "highest priority" then of course it is zero. >> If we are to represent priorities as unsigned integers, then I think >> both lowest and highest should fall into that range so that the >> implementation can use an unsigned integer too. So *if* we want the >> default to be lowest priority, then I would vote that we make the >> default be the highest value representable in the range, rather than >> something lower than that. >> >> I guess the question is whether we want the default to be highest >> priority or lowest priority. > [CNG] I think the "lowest priority". I don't much care. But I think it should be based on what we think the most common case is. Will people want to just mark a few captures as lower than the rest? Or just mark a few higher than the rest? Thanks, Paul From pkyzivat@alum.mit.edu Fri Jul 26 08:04:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7C21F8A85 for ; Fri, 26 Jul 2013 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE9zIu0VMCs9 for ; Fri, 26 Jul 2013 08:04:22 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0FB21F8E79 for ; Fri, 26 Jul 2013 08:04:22 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta08.westchester.pa.mail.comcast.net with comcast id 50Jl1m0030ldTLk5834Mxn; Fri, 26 Jul 2013 15:04:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 534M1m00f3ZTu2S0134M0Y; Fri, 26 Jul 2013 15:04:21 +0000 Message-ID: <51F28FF5.1040506@alum.mit.edu> Date: Fri, 26 Jul 2013 11:04:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com>, <51EE6B77.2060601@unina.it> <7594FB04B1934943A5C02806D1A2204B1C409F43@ESESSMB209.ericsson.se>, <51F1A3D1.3070905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C40A7D0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C40A7D0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374851061; bh=sNg/UAn3JOU2Qu/rG672BH0adBHZYK9D8fnVd93qqDI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SxEcHTEbu2v4ki3GmJelIdwYEWVyPHVhoDao9u33u7fIVlGbzyeUC47h0psrej+4K 1/codVxq5FclfkSatHOxdFsiowtAGot/lYSC2QC7xJmnVX2xv+U8z6JOnXEejybxyA f/5BbKmD7nCgVsT36fipJQUv68gm6+3fA7kgfH7SEZx/sb1mzvJ2B6j4cM1yw220AX fQGS0/hx+dwRuJ3kaYu2/3BunieNLBOachB0s5iPKytXAOkzLB3E+3wVuq94u22g5X w2CZ25aQu4WceecFRKHeHir3PJ8QvJQl0NJIMlpQ03GJP/9M4l98pSexNgtCYIF/2B UyU0uXA65NCZA== Cc: "clue_ietf.org" Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:04:27 -0000 On 7/26/13 4:41 AM, Christer Holmberg wrote: > Hi, > We can define all kind of attributes, but what case is this needed for? > Regards, > Christer We've had this one for awhile. We are just discussing the details. IMO its just a way for the advertiser to make recommendations. Thanks, Paul > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *To:* clue@ietf.org [clue@ietf.org] > *Subject:* Re: [clue] draft-ietf-clue-data-model-schema-00 > On 7/25/13 4:48 PM, Christer Holmberg wrote: >> Hi, >> Even if the advertiser thinks something has priority, the consumer may >> have another opinion. >> Isn't the role/content information supposed to describe what content is >> associated with the capture, and then the consumer chooses what it wants >> - based on its own priorities? > > Its another attribute that the consumer can consider (or ignore). > > Thanks > Paul > >> Regards, >> Christer >> >> >> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com ) >> >> -----Original Message----- >> *From:* Roberta Presta [roberta.presta@unina.it] >> *To:* clue@ietf.org [clue@ietf.org] >> *Subject:* Re: [clue] draft-ietf-clue-data-model-schema-00 >> Hi all, >> >> another possibility is the following. >> Priority is an optional attribute. >> When it is absent, it is intended to be "the lowest priority". >> When it is present, you have to order the priority values in a way that >> the most important capture has the lowest numeric value. >> >> For example, if I have >> - the audio of the lecturer AC0, >> - the video of the lecturer VC0, >> - the video of the slides VC1, >> - the video of the overall room VC2 >> and I want to prioritize the audio of the lecturer, and then the video >> of the slides, I can set the priority values as follows: >> - AC0, priority = 1 >> - VC1, priority = 2 >> - other captures, no priority >> >> The media consumer will know that: >> - the most important capture is AC0 >> - the second one is VC1 >> - all the other captures have the same level of importance, which is >> lower than the one of AC0 and VC1. >> >> What is your feeling about it? >> Cheers, >> >> Roberta >> >> >> Il 23/07/2013 06:00, Christian Groves ha scritto: >>> Hello Paul, >>> >>> "Audio and video don't "compete" with one another." Currently >>> priorities can be set across all capture types. E.g. I can say that's >>> more important for you to get an audio stream and a presentation >>> stream than it is to get the video if you have to choose because of >>> some bandwidth/display/etc contraint. It wouldn't be possible if you >>> consider priority to be scoped to a single media. >>> >>> Regards, Christian >>> >>> On 23/07/2013 12:48 PM, Paul Kyzivat wrote: >>>> On 7/22/13 8:41 PM, Christian Groves wrote: >>>>> Hello Paul, >>>>> >>>>> I agree that a default is needed. >>>>> >>>>> The reason for a "no priority" I saw a case where an Advertiser for >>>>> example may offer prioritised audio but choose not to prioritise video >>>>> or vice versa. Rather than prioritise audio over video or vice versa >>>>> which would effectively happen if all captures had a default priority >>>>> level. >>>> >>>> Audio and video don't "compete" with one another. I can't see how the >>>> priority processing of one would interact with the other. >>>> >>>> Perhaps we need to say something that audio and video are >>>> independently prioritized. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 23/07/2013 1:41 AM, Paul Kyzivat wrote: >>>>>> A couple of things I picked up while reviewing this version: >>>>>> >>>>>> Section 3 & Section 22: >>>>>> >>>>>> The schema was updated so captureEncodingType references >>>>>> encodingParametersType, but there is a typo (cut/paste error I guess) >>>>>> so that the intended definition of encodingParametersType actually >>>>>> redefines captureParametersType. >>>>>> >>>>>> Section 10.7 : >>>>>> >>>>>> ... The higher the >>>>>> importance, the lower the contained value. When media captures are >>>>>> marked with a "0" priority value, it means that they are "not >>>>>> subject >>>>>> to priority". >>>>>> >>>>>> [edt's note: discussion needed] >>>>>> >>>>>> IMO it makes no sense for some captures to be subject to priority and >>>>>> others to not be subject to priority. What would that mean? The only >>>>>> thing I can see is that those are *mandatory* to render. But we can't >>>>>> really mandate that. If you can't do it we can't force you. So the >>>>>> best it could mean is "really really important" to render. But that is >>>>>> the same as having the highest priority. >>>>>> >>>>>> So I suggest that zero is just the highest priority - no more, no >>>>>> less. >>>>>> >>>>>> And I suggest we also make zero the *default* priority, so that all >>>>>> captures have one, implicitly or explicitly. Then, if you don't >>>>>> mention priority at all, then all captures are equal. And you can just >>>>>> add priority for those captures that are less important. >>>>>> >>>>>> Equivalently, we could leave priority optional, and specify that the >>>>>> absence of a priority implicitly means the highest priority. Then the >>>>>> presence of priority means a lower priority. But I think this >>>>>> formulation is a little more confusing to explain. >>>>>> >>>>>> Section 10.10. : >>>>>> >>>>>> is an optional element indicating wheter or not the >>>>>> capture device originating the capture moves during the >>>>>> telepresence >>>>>> session. ... >>>>>> >>>>>> We can't know for sure that it will move, only that it may. Also a >>>>>> typo. So: >>>>>> >>>>>> s/moves/may move/ >>>>>> s/wheter/whether/ >>>>>> >>>>>> 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@alum.mit.edu Fri Jul 26 08:08:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D4D11E8107 for ; Fri, 26 Jul 2013 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XNbQzEZ1bsA for ; Fri, 26 Jul 2013 08:08:32 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DB21F859A for ; Fri, 26 Jul 2013 08:07:55 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 4zAb1m00617dt5G5B37vNW; Fri, 26 Jul 2013 15:07:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 537v1m00B3ZTu2S3Z37vrz; Fri, 26 Jul 2013 15:07:55 +0000 Message-ID: <51F290CA.2030608@alum.mit.edu> Date: Fri, 26 Jul 2013 11:07:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51F1A57D.5040405@alum.mit.edu> <51F23EAC.6020309@unina.it> In-Reply-To: <51F23EAC.6020309@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374851275; bh=2P4CUWUjKom7nc91YAHROJ88mkEjbSHeNpDuCiwIFtE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m2z5VvjkgMOaXm2HKiAcUHkZGdA7LGVl8LdSzOE1qebUal4vonLIoY+P9LS4CzjOi 4flVN5EOpXH4LEbCS5KuKySJRxn4qoGJjOaehVwEUR3hviZ4Pnd8c1TsZMDk+fngkg Zcq4j4zHNad6KWao6hyhmmzqidhwrDD9SwP/PlDI9akU+CwD9jyWcBBPMam+NJdmMr evAAmkNk3jVGCK4Fl8Gfec2l+zAow9zU86H8o8Xp0qkKwmMRgDv/AYNXOAG1TEZAb5 fKT462vCPRNP68MUDwZFPpD5cjaHn2vgbCAOSEJtigonOcCtwa7xlAuqwFXKvaB2ys TAPIn8pQSs7wg== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:08:38 -0000 On 7/26/13 5:17 AM, Roberta Presta wrote: > Hi Paul, > > Il 26/07/2013 00:23, Paul Kyzivat ha scritto: >> We also have the problem of how to select audio captures that "go >> with" particular video captures. I guess priorities might be one way >> to do that. Some sort of spatial information might be another. >> > > I think a mechanism to associate a capture to another one is needed or > at least it is worth to be discussed. +1 > We have currently two mechanisms to group captures semantically: > 1) putting them into the same capture scene > 2) using the tag to indicate that a capture is linked to > another one. > > The first one is coarse-grained, while the second one has been conceived > for linking "secondary" information, such as subtitles or translations, > to a "primary" capture, like for example the lecturer's audio. > However, we could exploit such element to link an audio capture to a > video capture. For example you could have the audio of the presenter - > AC0, and the video of the presenter is marked with a field > containing AC0, and/or viceversa. Alternatively, we can design a > specialized field to do the task. Good idea. seems to do the job. > Capture scene entries have been designed to group captures of the same > media type, so we can not use them to answer that need. > How do you think priority and spatial information could be used to > couple captures together? Well, there has been some discussion that spatial info could be used to tie an audio capture to a video capture. But John has debunked that idea. > For example, if we force captures that go together to have the same > priority, we are "overloading" the meaning and probably > making the priority settings (and its interpretation) even more complex. I agree. Thanks, Paul From Mark.Duckworth@polycom.com Sat Jul 27 04:59:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADADA21F9D28 for ; Sat, 27 Jul 2013 04:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaJ8kRj2gfRK for ; Sat, 27 Jul 2013 04:59:33 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 419D521E805D for ; Sat, 27 Jul 2013 04:59:24 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Sat, 27 Jul 2013 04:59:23 -0700 From: "Duckworth, Mark" To: "Christian Groves (Christian.Groves@nteczone.com)" , "clue@ietf.org" Date: Sat, 27 Jul 2013 04:59:21 -0700 Thread-Topic: How to use roles in multipoint? Thread-Index: Ac6KwAj+bYuzuTRoTCaiaQouAwpb+w== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D601FE535B@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D601FE535BCRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] How to use roles in multipoint? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2013 11:59:38 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D601FE535BCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christian, Regarding your role proposals, I'm trying to understand how it could be use= d in a multipoint conference. The endpoint consumers do not see the advert= isements of all the other endpoint providers, so I don't see how the role i= nformation in advertisements is useful. Are you envisioning a scenario whe= re a middlebox distributes endpoint advertisements to other endpoints? How= would this be done? I'm not convinced that attributes in a CLUE advertisement are the right pla= ce for this role information. Would it make sense to put this role informa= tion someplace else, like the SIP event package? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D601FE535BCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

= Regarding your role proposals, I’m trying to understand how it could = be used in a multipoint conference.  The endpoint consumers do not see= the advertisements of all the other endpoint providers, so I don’t s= ee how the role information in advertisements is useful.  Are you envi= sioning a scenario where a middlebox distributes endpoint advertisements to= other endpoints?  How would this be done?

 

I’m not convinced t= hat attributes in a CLUE advertisement are the right place for this role in= formation.  Would it make sense to put this role information someplace= else, like the SIP event package?

=  

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D601FE535BCRPMBOXPRD07pol_-- From Christian.Groves@nteczone.com Sun Jul 28 17:46:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4A21F9E85 for ; Sun, 28 Jul 2013 17:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTzarOn1vU+v for ; Sun, 28 Jul 2013 17:46:33 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3A421F9E83 for ; Sun, 28 Jul 2013 17:46:31 -0700 (PDT) Received: from ppp118-209-104-211.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.211]) by ipmail07.adl2.internode.on.net with ESMTP; 29 Jul 2013 10:16:02 +0930 Message-ID: <51F5BB45.5010009@nteczone.com> Date: Mon, 29 Jul 2013 10:45:57 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> <51F28FA7.5090603@alum.mit.edu> In-Reply-To: <51F28FA7.5090603@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 00:46:33 -0000 Hello Paul, Please see below. Regards, Christian On 27/07/2013 1:03 AM, Paul Kyzivat wrote: > On 7/26/13 1:12 AM, Christian Groves wrote: > >> [CNG] Perhaps we should just make this a btye 0-255 possible values? And >> perhaps we need to say there is no inference to how much more important >> the priority based on the position. e.g. 1 is not 100x times more >> important than 100. If you have two captures one with priority 1 and the >> other priority 100 the priority one capture is simply more important. No >> difference to 1 & 2, 1 & 50 etc. > > Why would we want to restrict to 256 values? To save 3 bytes in the > implementation? > > While people can probably settle with that, why? [CNG] Its not to save the 3 bytes in signalling. I just think it is logically better to give a finite set of priorities within the realms of day to day experience. If I was to set this via some UI I think its easier present a range 0 - 256 rather than 0-2,147,483,647. > >>> Implementations are going to need a representation for all values, >>> including the highest and lowest. >> [CNG] Strictly speaking we probably only need the "highest" priority. >> The lowest is effectively the number before or after (depending on >> whether 1 is highest or not) those that have been set in the captures. > > The highest is zero, so that is easy. The lowest you can specify is > currently 2^32-1. Suppose somebody decides to set some captures to > 2^32-1, and leaves some unspecified? What value does the > implementation give to them? > > So just say the the default is 2^32-1, or maxint. XML allows you to > put a default in the schema. So we can just use that. > > This is assuming we want the default to be "lowest priority". If the > default is "highest priority" then of course it is zero. [CNG] I'm OK with Roberta's proposal: "the highest value = the first relevance rank (e.g. 1)" default lowest value 255. > >>> If we are to represent priorities as unsigned integers, then I think >>> both lowest and highest should fall into that range so that the >>> implementation can use an unsigned integer too. So *if* we want the >>> default to be lowest priority, then I would vote that we make the >>> default be the highest value representable in the range, rather than >>> something lower than that. >>> >>> I guess the question is whether we want the default to be highest >>> priority or lowest priority. >> [CNG] I think the "lowest priority". > > I don't much care. But I think it should be based on what we think the > most common case is. Will people want to just mark a few captures as > lower than the rest? Or just mark a few higher than the rest? > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Jul 28 18:10:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245421F9D93 for ; Sun, 28 Jul 2013 18:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uWFgt2FdznF for ; Sun, 28 Jul 2013 18:10:25 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id A89F221F9E85 for ; Sun, 28 Jul 2013 18:10:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAMi/9VF20WjT/2dsb2JhbAANToM7viOBK4MYAQEBAwEBAQE1GxUGChELGAkWDwkDAgECARUwEwYCAQGIBhKlT5FUBJAEhAUDrFE Received: from ppp118-209-104-211.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.211]) by ipmail07.adl2.internode.on.net with ESMTP; 29 Jul 2013 10:40:23 +0930 Message-ID: <51F5C0FC.2020206@nteczone.com> Date: Mon, 29 Jul 2013 11:10:20 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51F1A57D.5040405@alum.mit.edu> <51F23EAC.6020309@unina.it> <51F290CA.2030608@alum.mit.edu> In-Reply-To: <51F290CA.2030608@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 01:10:25 -0000 Hello Roberta, Please see my comments below. Regards, Christian On 27/07/2013 1:07 AM, Paul Kyzivat wrote: > On 7/26/13 5:17 AM, Roberta Presta wrote: >> Hi Paul, >> >> Il 26/07/2013 00:23, Paul Kyzivat ha scritto: >>> We also have the problem of how to select audio captures that "go >>> with" particular video captures. I guess priorities might be one way >>> to do that. Some sort of spatial information might be another. >>> >> >> I think a mechanism to associate a capture to another one is needed or >> at least it is worth to be discussed. > > +1 > >> We have currently two mechanisms to group captures semantically: >> 1) putting them into the same capture scene >> 2) using the tag to indicate that a capture is linked to >> another one. >> >> The first one is coarse-grained, while the second one has been conceived >> for linking "secondary" information, such as subtitles or translations, >> to a "primary" capture, like for example the lecturer's audio. >> However, we could exploit such element to link an audio capture to a >> video capture. For example you could have the audio of the presenter - >> AC0, and the video of the presenter is marked with a field >> containing AC0, and/or viceversa. Alternatively, we can design a >> specialized field to do the task. > > Good idea. seems to do the job. [CNG] It could be made to work but it might be clearer to have a separate attribute with similar syntax. The original intention behind the "relatedTo" was that the capture provided "additional or complementary information" to another capture. e.g. There's a main audio capture AC1. I have a capture which is a commentary of the conference AC2(relatedTo(AC1)) [btw. as current defined in the framework there's only one value for the relatedTo capture]. Semantically this is different from "this capture is an audio representation of these video captures". > >> Capture scene entries have been designed to group captures of the same >> media type, so we can not use them to answer that need. >> How do you think priority and spatial information could be used to >> couple captures together? > > Well, there has been some discussion that spatial info could be used > to tie an audio capture to a video capture. But John has debunked that > idea. [CNG] As Paul mentioned it seems the current point is that audio captures won't have the same spatial information as video so if won't be possible to tie audio and video through spatial information. That's where the will probably become more important. > >> For example, if we force captures that go together to have the same >> priority, we are "overloading" the meaning and probably >> making the priority settings (and its interpretation) even more complex. > > I agree. [CNG] I don't think we want to overload priority. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From john@jlc.net Sun Jul 28 21:51:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32721F9FDA for ; Sun, 28 Jul 2013 21:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwprOBDozD2U for ; Sun, 28 Jul 2013 21:51:51 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7078721F9E46 for ; Sun, 28 Jul 2013 21:51:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5743233C21; Mon, 29 Jul 2013 00:51:38 -0400 (EDT) Date: Mon, 29 Jul 2013 00:51:38 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20130729045138.GB3328@verdi> References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F1AB5A.5090403@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 04:51:57 -0000 Paul Kyzivat wrote: > > I think John should make a proposal for what we ought to have in the fw > & data model for this, that will be "enough" without going overboard. I > don't sense that anybody else here is competent to make this call. Well, you asked... "Be careful what you ask for..." I see three different kinds of audio - microphones; - microphone sets; and - mixes. A microphone is simply a transducer, with gain "fixed" for the duration of its use. Its characteristics include - capture point; - point on axis of capture; and - sensitivity pattern. The first two are where it's placed and where it's "pointing". The third is a sensitivity graph. For starters we should have three pre-defined graphs: - generic omni; - generic cardioid; and - unknown. There will eventually be others, e.g. "shotgun", and we should allow for accurate graphs for specific microphones; but I don't propose any more at this time. A microphone set is a collection of transducers in a fixed arrangement. The common case right now is "XY stereo" which is two transducers at 90-degrees to each other. Each transducer has its own characteristics and its own audio stream; but it will be set up as a single unit with: - capture point; - point on axis of capture; and - list of individual transducers with offsets. A "mix" is a managed combination of sound sources (which can no longer be individually identified). The gain of each can be varied at any time, without warning or even notice of change. Mixes should be given human- readable names, and should also have a machine-readable tag. Initially, that tag should cover: - room mix; and - presentation mix. More will follow eventually, but I see no reason to discuss those now. The output of a mix will be one or more audio streams, specifically we should expect: - mono; - stereo; and - surround. ==== Discussion, IMHO, should be on the list. I will not be in Berlin; but I will be following today's session via MeetEcho. I can type fast enough to answer questions in jabber, should you have any... -- John Leslie From coverdale@sympatico.ca Sun Jul 28 23:54:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9421F95BD for ; Sun, 28 Jul 2013 23:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfvguA2mMuf7 for ; Sun, 28 Jul 2013 23:53:37 -0700 (PDT) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id C1DBB21F93F3 for ; Sun, 28 Jul 2013 23:53:13 -0700 (PDT) Received: from BLU0-SMTP56 ([65.55.116.8]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Jul 2013 23:53:13 -0700 X-EIP: [cjIOBlKDstxfkL4UxyKfCm/CKlArFfH8] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([130.129.18.59]) by BLU0-SMTP56.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Jul 2013 23:53:10 -0700 From: Paul Coverdale To: "'John Leslie'" , "'Paul Kyzivat'" References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> In-Reply-To: <20130729045138.GB3328@verdi> Date: Mon, 29 Jul 2013 08:53:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6MF2qL60hVQT2yQn+BbMmVrNb/awAD4rqw Content-Language: en-us X-OriginalArrivalTime: 29 Jul 2013 06:53:10.0555 (UTC) FILETIME=[49D43EB0:01CE8C28] Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 06:54:12 -0000 It's a while I was formally involved in the electro-acoustics world, but this proposal makes sense to me. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >John Leslie >Sent: Monday, July 29, 2013 6:52 AM >To: Paul Kyzivat >Cc: clue@ietf.org >Subject: [clue] Data Model for audio > >Paul Kyzivat wrote: >> >> I think John should make a proposal for what we ought to have in the >> fw & data model for this, that will be "enough" without going >> overboard. I don't sense that anybody else here is competent to make >this call. > > Well, you asked... "Be careful what you ask for..." > > I see three different kinds of audio > >- microphones; >- microphone sets; and >- mixes. > > A microphone is simply a transducer, with gain "fixed" for the >duration of its use. Its characteristics include > >- capture point; >- point on axis of capture; and >- sensitivity pattern. > > The first two are where it's placed and where it's "pointing". >The third is a sensitivity graph. For starters we should have three pre- >defined graphs: > >- generic omni; >- generic cardioid; and >- unknown. > > There will eventually be others, e.g. "shotgun", and we should allow >for accurate graphs for specific microphones; but I don't propose any >more at this time. > > A microphone set is a collection of transducers in a fixed >arrangement. >The common case right now is "XY stereo" which is two transducers at 90- >degrees to each other. Each transducer has its own characteristics and >its own audio stream; but it will be set up as a single unit with: > >- capture point; >- point on axis of capture; and >- list of individual transducers with offsets. > > A "mix" is a managed combination of sound sources (which can no >longer be individually identified). The gain of each can be varied at >any time, without warning or even notice of change. Mixes should be >given human- readable names, and should also have a machine-readable >tag. Initially, that tag should cover: > >- room mix; and >- presentation mix. > > More will follow eventually, but I see no reason to discuss those >now. > > The output of a mix will be one or more audio streams, specifically >we should expect: > >- mono; >- stereo; and >- surround. > >==== > > Discussion, IMHO, should be on the list. > > I will not be in Berlin; but I will be following today's session via >MeetEcho. I can type fast enough to answer questions in jabber, should >you have any... > >-- >John Leslie >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From spromano@unina.it Mon Jul 29 00:20:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAE421F9C41 for ; Mon, 29 Jul 2013 00:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98B8mq9JBROK for ; Mon, 29 Jul 2013 00:20:01 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7E21F8FD5 for ; Mon, 29 Jul 2013 00:19:59 -0700 (PDT) Received: from dhcp-1483.meeting.ietf.org (dhcp-1483.meeting.ietf.org [130.129.20.131]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r6T7Jpfr021057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 09:19:53 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2FAF31AC-4472-4A71-885D-D8AEDF6348B0" From: Simon Pietro Romano In-Reply-To: Date: Mon, 29 Jul 2013 09:19:51 +0200 Message-Id: <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> To: Paul Coverdale X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 07:20:19 -0000 --Apple-Mail=_2FAF31AC-4472-4A71-885D-D8AEDF6348B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 from my side. We had this kind of stuff in the data model (based on = one of the first e-mails on this subject from John) before and = unfortunately we were forced to remove it in order to get aligned with = the framework. I will propose today to put such information both in the = former (framework) and in the latter (data model) documents. Simon Il giorno 29/lug/2013, alle ore 08:53, Paul Coverdale ha scritto: > It's a while I was formally involved in the electro-acoustics world, = but > this proposal makes sense to me. >=20 > ...Paul >=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of >> John Leslie >> Sent: Monday, July 29, 2013 6:52 AM >> To: Paul Kyzivat >> Cc: clue@ietf.org >> Subject: [clue] Data Model for audio >>=20 >> Paul Kyzivat wrote: >>>=20 >>> I think John should make a proposal for what we ought to have in the >>> fw & data model for this, that will be "enough" without going >>> overboard. I don't sense that anybody else here is competent to make >> this call. >>=20 >> Well, you asked... "Be careful what you ask for..." >>=20 >> I see three different kinds of audio >>=20 >> - microphones; >> - microphone sets; and >> - mixes. >>=20 >> A microphone is simply a transducer, with gain "fixed" for the >> duration of its use. Its characteristics include >>=20 >> - capture point; >> - point on axis of capture; and >> - sensitivity pattern. >>=20 >> The first two are where it's placed and where it's "pointing". >> The third is a sensitivity graph. For starters we should have three = pre- >> defined graphs: >>=20 >> - generic omni; >> - generic cardioid; and >> - unknown. >>=20 >> There will eventually be others, e.g. "shotgun", and we should allow >> for accurate graphs for specific microphones; but I don't propose any >> more at this time. >>=20 >> A microphone set is a collection of transducers in a fixed >> arrangement. >> The common case right now is "XY stereo" which is two transducers at = 90- >> degrees to each other. Each transducer has its own characteristics = and >> its own audio stream; but it will be set up as a single unit with: >>=20 >> - capture point; >> - point on axis of capture; and >> - list of individual transducers with offsets. >>=20 >> A "mix" is a managed combination of sound sources (which can no >> longer be individually identified). The gain of each can be varied at >> any time, without warning or even notice of change. Mixes should be >> given human- readable names, and should also have a machine-readable >> tag. Initially, that tag should cover: >>=20 >> - room mix; and >> - presentation mix. >>=20 >> More will follow eventually, but I see no reason to discuss those >> now. >>=20 >> The output of a mix will be one or more audio streams, specifically >> we should expect: >>=20 >> - mono; >> - stereo; and >> - surround. >>=20 >> =3D=3D=3D=3D >>=20 >> Discussion, IMHO, should be on the list. >>=20 >> I will not be in Berlin; but I will be following today's session via >> MeetEcho. I can type fast enough to answer questions in jabber, = should >> you have any... >>=20 >> -- >> John Leslie >> _______________________________________________ >> 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_2FAF31AC-4472-4A71-885D-D8AEDF6348B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +1 = from my side. We had this kind of stuff in the data model (based on one = of the first e-mails on this subject from John) before and unfortunately = we were forced to remove it in order to get aligned with the framework. = I will propose today to put such information both in the former = (framework) and in the latter (data model) = documents.

Simon

Il giorno = 29/lug/2013, alle ore 08:53, Paul Coverdale ha scritto:

It's = a while I was formally involved in the electro-acoustics world, = but
this proposal makes sense to = me.

...Paul

-----Original = Message-----
From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of
John Leslie
Sent: = Monday, July 29, 2013 6:52 AM
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: [clue] Data Model for = audio

Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

I think John should make a = proposal for what we ought to have in = the
fw & data model for this, that will be "enough" = without going
overboard. I don't sense that = anybody else here is competent to = make
this = call.

 Well, = you asked... "Be careful what you ask = for..."

 I see = three different kinds of audio

- = microphones;
- microphone = sets; and
- = mixes.

 A = microphone is simply a transducer, with gain "fixed" for = the
duration of its use. Its = characteristics include

- capture = point;
- point on axis of = capture; and
- sensitivity = pattern.

 The = first two are where it's placed and where it's = "pointing".
The third is a = sensitivity graph. For starters we should have three = pre-
defined = graphs:

- generic = omni;
- generic cardioid; = and
- = unknown.

 There = will eventually be others, e.g. "shotgun", and we should = allow
for accurate graphs for = specific microphones; but I don't propose = any
more at this = time.

 A = microphone set is a collection of transducers in a = fixed
arrangement.
The = common case right now is "XY stereo" which is two transducers at = 90-
degrees to each other. = Each transducer has its own characteristics = and
its own audio stream; but = it will be set up as a single unit with:

- capture = point;
- point on axis of = capture; and
- list of = individual transducers with offsets.

 A "mix" = is a managed combination of sound sources (which can = no
longer be individually = identified). The gain of each can be varied = at
any time, without warning = or even notice of change. Mixes should be
given human- readable names, and should also have a = machine-readable
tag. = Initially, that tag should cover:

- room mix; = and
- presentation = mix.

 More = will follow eventually, but I see no reason to discuss = those
now.

 The = output of a mix will be one or more audio streams, = specifically
we should = expect:

- = mono;
- stereo; = and
- = surround.

=3D=3D=3D=3D

=  Discussion, IMHO, should be on the = list.

 I will = not be in Berlin; but I will be following today's session = via
MeetEcho. I can type fast = enough to answer questions in jabber, should
you have any...

--
John Leslie = <john@jlc.net>
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/m= ailman/listinfo/clue

_____________________________= __________________
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue


      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_2FAF31AC-4472-4A71-885D-D8AEDF6348B0-- From espeberg@cisco.com Mon Jul 29 01:04:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7C921F9B21 for ; Mon, 29 Jul 2013 01:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH9ZRtwUsBCQ for ; Mon, 29 Jul 2013 01:03:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 31DB721F9B0D for ; Mon, 29 Jul 2013 01:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33420; q=dns/txt; s=iport; t=1375085030; x=1376294630; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6T7vThU8CYj57wrqWRoM4TKbrp7ndhG7No3ZbGty99U=; b=NbLUJ2bg+KzjxmaB5aH8HEmQp2KL0/vJETHl/bdmtGfF6gV7b8P2m4cC dQfPHzHEBJIfyp5/aYMKxpm/oz4JzsNb+VQ4oiXnGs1cgGQZ4k595r7ZZ M8kkDA1orEKf/s6eAkfTiyzodEdKQYANwe6up78sQ/blSrwlYc+1VQP9u Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAAgh9lGtJV2Z/2dsb2JhbABbgkJENVC9VYEVFnSCJAEBAQQBAQEqPwIIAwwCAgIBCBEEAQELFgEGBxsMCxQJCAIEAQ0FCBGHdwy3TgQEjkp+BgcgBAYBAgSDEm8DiHKCPIhalSODFIFxOQ X-IronPort-AV: E=Sophos;i="4.89,767,1367971200"; d="scan'208,217";a="240706909" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2013 08:03:48 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6T83m6G027058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 08:03:48 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.116]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 03:03:48 -0500 From: "Espen Berger (espeberg)" To: Simon Pietro Romano , Paul Coverdale Thread-Topic: [clue] Data Model for audio Thread-Index: AQHOjBdp2J3h0STsdk6lwJSrAZcZo5l7jDEAgAAHeYD//7Nz4A== Date: Mon, 29 Jul 2013 08:03:48 +0000 Message-ID: References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> In-Reply-To: <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.81] Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D1A496BAExmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:04:06 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D1A496BAExmbrcdx11ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Together with the framework and data model suggestion we should also do det= ailed use cases to have common understanding of what we want to achieve wit= h an extended audio model within CLUE. Without clear use cases it is hard t= o discuss the extensions and how they can be applied to real-life use case= s. It is not clear to me how much of the capture information I need to play ou= t audio, so I need examples to be able to review the suggestions. Regards -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Sim= on Pietro Romano Sent: 29. juli 2013 09:20 To: Paul Coverdale Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio +1 from my side. We had this kind of stuff in the data model (based on one = of the first e-mails on this subject from John) before and unfortunately we= were forced to remove it in order to get aligned with the framework. I wil= l propose today to put such information both in the former (framework) and = in the latter (data model) documents. Simon Il giorno 29/lug/2013, alle ore 08:53, Paul Coverdale ha scritto: It's a while I was formally involved in the electro-acoustics world, but this proposal makes sense to me. ...Paul -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of John Leslie Sent: Monday, July 29, 2013 6:52 AM To: Paul Kyzivat Cc: clue@ietf.org Subject: [clue] Data Model for audio Paul Kyzivat > wrote: I think John should make a proposal for what we ought to have in the fw & data model for this, that will be "enough" without going overboard. I don't sense that anybody else here is competent to make this call. Well, you asked... "Be careful what you ask for..." I see three different kinds of audio - microphones; - microphone sets; and - mixes. A microphone is simply a transducer, with gain "fixed" for the duration of its use. Its characteristics include - capture point; - point on axis of capture; and - sensitivity pattern. The first two are where it's placed and where it's "pointing". The third is a sensitivity graph. For starters we should have three pre- defined graphs: - generic omni; - generic cardioid; and - unknown. There will eventually be others, e.g. "shotgun", and we should allow for accurate graphs for specific microphones; but I don't propose any more at this time. A microphone set is a collection of transducers in a fixed arrangement. The common case right now is "XY stereo" which is two transducers at 90- degrees to each other. Each transducer has its own characteristics and its own audio stream; but it will be set up as a single unit with: - capture point; - point on axis of capture; and - list of individual transducers with offsets. A "mix" is a managed combination of sound sources (which can no longer be individually identified). The gain of each can be varied at any time, without warning or even notice of change. Mixes should be given human- readable names, and should also have a machine-readable tag. Initially, that tag should cover: - room mix; and - presentation mix. More will follow eventually, but I see no reason to discuss those now. The output of a mix will be one or more audio streams, specifically we should expect: - mono; - stereo; and - surround. =3D=3D=3D=3D Discussion, IMHO, should be on the list. I will not be in Berlin; but I will be following today's session via MeetEcho. I can type fast enough to answer questions in jabber, should you have any... -- John Leslie > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _\= \|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Feder= ico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Ma= gritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) = ) / (_/ --_000_E8F5F2C7B2623641BD9ABF0B622D726D1A496BAExmbrcdx11ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Together w= ith the framework and data model suggestion we should also do detailed use = cases to have common understanding of what we want to achieve with an extended audio model within CLUE. Without clear use cases it is ha= rd to discuss the extensions  and how they can be applied to real-life= use cases.

 = ;

It is not = clear to me how much of the capture information I need to play out audio, s= o I need examples to be able to review the suggestions. 

 = ;

Regards

 = ;

-Espen

 = ;

 = ;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano
Sent: 29. juli 2013 09:20
To: Paul Coverdale
Cc: clue@ietf.org
Subject: Re: [clue] Data Model for audio

 

+1 from my side. We had this kind of stuff in th= e data model (based on one of the first e-mails on this subject from John) = before and unfortunately we were forced to remove it in order to get aligne= d with the framework. I will propose today to put such information both in the former (framework) and in the latter (= data model) documents.

 

Simon

 

Il giorno 29/lug/2013, alle ore 08:53, Paul Coverdal= e ha scritto:



It's a while I was formally involved in the electro-= acoustics world, but
this proposal makes sense to me.

...Paul


-----Original Message-----

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

John Leslie

Sent: Monday, July 29, 2013 6:52 AM

To: Paul Kyzivat

Cc: clue@ietf.org

Subject: [clue] Data Model for audio

 

Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

 

I think John should make a proposal for what we ough= t to have in the

fw & data model for this, that will be "eno= ugh" without going

overboard. I don't sense that anybody else here is c= ompetent to make

this call.

 

 Well, you asked... "Be careful what you a= sk for..."

 

 I see three different kinds of audio

 

- microphones;

- microphone sets; and

- mixes.

 

 A microphone is simply a transducer, with gain= "fixed" for the

duration of its use. Its characteristics include

 

- capture point;

- point on axis of capture; and

- sensitivity pattern.

 

 The first two are where it's placed and where = it's "pointing".

The third is a sensitivity graph. For starters we sh= ould have three pre-

defined graphs:

 

- generic omni;

- generic cardioid; and

- unknown.

 

 There will eventually be others, e.g. "sh= otgun", and we should allow

for accurate graphs for specific microphones; but I = don't propose any

more at this time.

 

 A microphone set is a collection of transducer= s in a fixed

arrangement.

The common case right now is "XY stereo" w= hich is two transducers at 90-

degrees to each other. Each transducer has its own c= haracteristics and

its own audio stream; but it will be set up as a sin= gle unit with:

 

- capture point;

- point on axis of capture; and

- list of individual transducers with offsets.<= /o:p>

 

 A "mix" is a managed combination of = sound sources (which can no

longer be individually identified). The gain of each= can be varied at

any time, without warning or even notice of change. = Mixes should be

given human- readable names, and should also have a = machine-readable

tag. Initially, that tag should cover:

 

- room mix; and

- presentation mix.

 

 More will follow eventually, but I see no reas= on to discuss those

now.

 

 The output of a mix will be one or more audio = streams, specifically

we should expect:

 

- mono;

- stereo; and

- surround.

 

=3D=3D=3D=3D

 

 Discussion, IMHO, should be on the list.<= /o:p>

 

 I will not be in Berlin; but I will be followi= ng today's session via

MeetEcho. I can type fast enough to answer questions= in jabber, should

you have any...

 

--

John Leslie <john= @jlc.net>

_______________________________________________=

clue mailing list

clue@ietf.org

https://www.ietf.org/mailman/listinfo/clue


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

 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;             &nb= sp; _\\|//_

      &nbs= p;                            = ;            &n= bsp;              ( O-O )

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =        Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;      Universita' di Na= poli Federico II

      &nbs= p;          &n= bsp;               Computer Engineering Department =

                  =     Phone: +39 081 7683823 -- Fax: +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: spromano@unina.it

 <= /p>

           &nb= sp;           <<Molti mi dic= ono che lo scoraggiamento =CB l'alibi degli 

           &nb= sp;           idioti. Ci rifl= etto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                        = ;  oooO

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                   =        \ (            ( =   )

           &nb= sp;            =              =                     &nbs= p;   \_)          ) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 <= /p>



 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D1A496BAExmbrcdx11ciscoc_-- From coverdale@sympatico.ca Mon Jul 29 01:39:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE24E21F9E6C for ; Mon, 29 Jul 2013 01:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvQi1hjga+XB for ; Mon, 29 Jul 2013 01:39:31 -0700 (PDT) Received: from blu0-omc1-s16.blu0.hotmail.com (blu0-omc1-s16.blu0.hotmail.com [65.55.116.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCCC21F9D52 for ; Mon, 29 Jul 2013 01:39:31 -0700 (PDT) Received: from BLU0-SMTP48 ([65.55.116.9]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 01:39:30 -0700 X-EIP: [bMeOyX2q2EZR1JIDmsrIiOcnNWoRyMR9] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([130.129.18.59]) by BLU0-SMTP48.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 01:39:26 -0700 From: Paul Coverdale To: "'Espen Berger \(espeberg\)'" , "'Simon Pietro Romano'" References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> In-Reply-To: Date: Mon, 29 Jul 2013 10:39:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CE8C47.E5305640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOjBdp2J3h0STsdk6lwJSrAZcZo5l7jDEAgAAHeYD//7Nz4IAADiQQ Content-Language: en-us X-OriginalArrivalTime: 29 Jul 2013 08:39:27.0467 (UTC) FILETIME=[22C3CBB0:01CE8C37] Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:39:36 -0000 ------=_NextPart_000_0019_01CE8C47.E5305640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don=92t understand why we need to get into detailed use cases for = =93extended audio=94. The proposal seems pretty fundamental to me. How many = microphones does a provider have, where are they located and what is their = directivity pattern (if any). =20 ...Paul =20 From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]=20 Sent: Monday, July 29, 2013 10:04 AM To: Simon Pietro Romano; Paul Coverdale Cc: clue@ietf.org Subject: RE: [clue] Data Model for audio =20 Together with the framework and data model suggestion we should also do detailed use cases to have common understanding of what we want to = achieve with an extended audio model within CLUE. Without clear use cases it is = hard to discuss the extensions and how they can be applied to real-life use cases.=20 =20 It is not clear to me how much of the capture information I need to play = out audio, so I need examples to be able to review the suggestions. =20 =20 Regards =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano Sent: 29. juli 2013 09:20 To: Paul Coverdale Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio =20 +1 from my side. We had this kind of stuff in the data model (based on = one of the first e-mails on this subject from John) before and unfortunately = we were forced to remove it in order to get aligned with the framework. I = will propose today to put such information both in the former (framework) and = in the latter (data model) documents. =20 Simon =20 Il giorno 29/lug/2013, alle ore 08:53, Paul Coverdale ha scritto: =20 It's a while I was formally involved in the electro-acoustics world, but this proposal makes sense to me. ...Paul -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie Sent: Monday, July 29, 2013 6:52 AM To: Paul Kyzivat Cc: clue@ietf.org Subject: [clue] Data Model for audio =20 Paul Kyzivat wrote: =20 I think John should make a proposal for what we ought to have in the fw & data model for this, that will be "enough" without going overboard. I don't sense that anybody else here is competent to make this call. =20 Well, you asked... "Be careful what you ask for..." =20 I see three different kinds of audio =20 - microphones; - microphone sets; and - mixes. =20 A microphone is simply a transducer, with gain "fixed" for the duration of its use. Its characteristics include =20 - capture point; - point on axis of capture; and - sensitivity pattern. =20 The first two are where it's placed and where it's "pointing". The third is a sensitivity graph. For starters we should have three pre- defined graphs: =20 - generic omni; - generic cardioid; and - unknown. =20 There will eventually be others, e.g. "shotgun", and we should allow for accurate graphs for specific microphones; but I don't propose any more at this time. =20 A microphone set is a collection of transducers in a fixed arrangement. The common case right now is "XY stereo" which is two transducers at 90- degrees to each other. Each transducer has its own characteristics and its own audio stream; but it will be set up as a single unit with: =20 - capture point; - point on axis of capture; and - list of individual transducers with offsets. =20 A "mix" is a managed combination of sound sources (which can no longer be individually identified). The gain of each can be varied at any time, without warning or even notice of change. Mixes should be given human- readable names, and should also have a machine-readable tag. Initially, that tag should cover: =20 - room mix; and - presentation mix. =20 More will follow eventually, but I see no reason to discuss those now. =20 The output of a mix will be one or more audio streams, specifically we should expect: =20 - mono; - stereo; and - surround. =20 =3D=3D=3D=3D =20 Discussion, IMHO, should be on the list. =20 I will not be in Berlin; but I will be following today's session via MeetEcho. I can type fast enough to answer questions in jabber, should you have any... =20 -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro = Romano Universita' di Napoli Federico II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it =20 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) = ) / = (_/ =20 =20 =20 =20 ------=_NextPart_000_0019_01CE8C47.E5305640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t understand why we need to get into detailed use cases = for “extended audio”. The proposal seems pretty fundamental = to me.=A0 How many microphones does a provider have, where are they = located and what is their directivity pattern (if = any).

 

...Paul

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: = Monday, July 29, 2013 10:04 AM
To: Simon Pietro Romano; Paul = Coverdale
Cc: clue@ietf.org
Subject: RE: [clue] Data = Model for audio

 

Together with the framework and data model suggestion we should also = do detailed use cases to have common understanding of what we want to = achieve with an extended audio model within CLUE. Without clear use = cases it is hard to discuss the extensions  and how they can be = applied to real-life use cases.

 

It is not clear to me how much of the capture information I need to = play out audio, so I need examples to be able to review the = suggestions. 

 

Regards

 

-Espen

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Simon Pietro Romano
Sent: 29. juli 2013 = 09:20
To: Paul Coverdale
Cc: clue@ietf.org
Subject: Re: = [clue] Data Model for audio

 

+1 from my side. We had this kind = of stuff in the data model (based on one of the first e-mails on this = subject from John) before and unfortunately we were forced to remove it = in order to get aligned with the framework. I will propose today to put = such information both in the former (framework) and in the latter (data = model) documents.

 

Simon

 

Il giorno 29/lug/2013, alle ore = 08:53, Paul Coverdale ha scritto:

 

It's a while I was = formally involved in the electro-acoustics world, but
this proposal = makes sense to me.

...Paul

-----Original = Message-----

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

John = Leslie

Sent: Monday, July 29, 2013 6:52 = AM

To: Paul = Kyzivat

Cc: clue@ietf.org

Subject: [clue] Data Model for = audio

 

Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

 

I think John should make a = proposal for what we ought to have in = the

fw & data model for this, that = will be "enough" without = going

overboard. I don't sense that = anybody else here is competent to = make

this = call.

 

 Well, you asked... "Be = careful what you ask = for..."

 

 I see three different kinds = of audio

 

- = microphones;

- microphone sets; = and

- = mixes.

 

 A microphone is simply a = transducer, with gain "fixed" for = the

duration of its use. Its = characteristics include

 

- capture = point;

- point on axis of capture; = and

- sensitivity = pattern.

 

 The first two are where it's = placed and where it's = "pointing".

The third is a sensitivity graph. = For starters we should have three = pre-

defined = graphs:

 

- generic = omni;

- generic cardioid; = and

- = unknown.

 

 There will eventually be = others, e.g. "shotgun", and we should = allow

for accurate graphs for specific = microphones; but I don't propose = any

more at this = time.

 

 A microphone set is a = collection of transducers in a = fixed

arrangement.

The common case right now is = "XY stereo" which is two transducers at = 90-

degrees to each other. Each = transducer has its own characteristics = and

its own audio stream; but it will = be set up as a single unit = with:

 

- capture = point;

- point on axis of capture; = and

- list of individual transducers = with offsets.

 

 A "mix" is a = managed combination of sound sources (which can = no

longer be individually = identified). The gain of each can be varied = at

any time, without warning or even = notice of change. Mixes should = be

given human- readable names, and = should also have a = machine-readable

tag. Initially, that tag should = cover:

 

- room mix; = and

- presentation = mix.

 

 More will follow eventually, = but I see no reason to discuss = those

now.

 

 The output of a mix will be = one or more audio streams, = specifically

we should = expect:

 

- = mono;

- stereo; = and

- = surround.

 

=3D=3D=3D=3D

 

 Discussion, IMHO, should be = on the list.

 

 I will not be in Berlin; but = I will be following today's session = via

MeetEcho. I can type fast enough = to answer questions in jabber, = should

you have = any...

 

--

John Leslie <john@jlc.net>

_______________________________________________<= /span>

clue mailing = list

clue@ietf.org

https://www.ietf.org/= mailman/listinfo/clue


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

 

                    =          &n= bsp;           &nb= sp;           &nbs= p;            =      =   _\\|//_

                    =                &n= bsp;           &nb= sp;            =   ( O-O )

  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

                  =           &n= bsp;           &nb= sp;           &nbs= p;   Simon Pietro = Romano

                     &n= bsp;           &nb= sp;           &nbs= p;  Universita' = di Napoli Federico II

                        &n= bsp;        Computer Engineering = Department 

                      Phone: +39 081 = 7683823 -- Fax: +39 081 7683816

                    =                     =    e-mail: spromano@unina.it=

 

           &nbs= p;           <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 

           &nbs= p;           idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.

                       &n= bsp;           &nb= sp;                  =      oooO

  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

<= p class=3DMsoNormal>           &nbs= p;            = ;            =            =                  \ ( =            (   = )

           &nbs= p;            = ;                        =               \_)     =      ) /

                    =                     =                     =           =  (_/

 

 

 

 

------=_NextPart_000_0019_01CE8C47.E5305640-- From john@jlc.net Mon Jul 29 02:41:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980F11E80EC for ; Mon, 29 Jul 2013 02:41:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJNWiaqNQA+9 for ; Mon, 29 Jul 2013 02:41:09 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE211E80DF for ; Mon, 29 Jul 2013 02:41:09 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F405733C22; Mon, 29 Jul 2013 05:41:08 -0400 (EDT) Date: Mon, 29 Jul 2013 05:41:08 -0400 From: John Leslie To: "Espen Berger (espeberg)" Message-ID: <20130729094108.GC3328@verdi> References: <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "clue@ietf.org" Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 09:41:14 -0000 Espen Berger (espeberg) wrote: > > Together with the framework and data model suggestion we should also > do detailed use cases to have common understanding of what we want to > achieve with an extended audio model within CLUE. I'm not unwilling to do this, although I can't tackle it today and may not be able to do so anytime this week. > Without clear use cases it is hard to discuss the extensions and how > they can be applied to real-life use cases. What I proposed is describing what microphones and mixes _are_. I don't see how use-cases have anything to do with that. > It is not clear to me how much of the capture information I need to > play out audio, so I need examples to be able to review the suggestions. You don't need _any_ of this information to play an audio stream. OTOH, it's easy to imagine potential uses where this information would inform the process of making an _effective_ audio environment. We should not (IMHO) prevent such an outcome based upon how many of us want to do this right away. (I will be mostly off-Net until Tuesday morning.) -- John Leslie From mary.ietf.barnes@gmail.com Mon Jul 29 09:42:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD4921E805D for ; Mon, 29 Jul 2013 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJgb0MxdVUiG for ; Mon, 29 Jul 2013 09:42:39 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 838BE21F9E0D for ; Mon, 29 Jul 2013 09:42:39 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so2969728qcw.2 for ; Mon, 29 Jul 2013 09:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YTp8Wg1g4ED+pL0s+yZG6DrXV3SDAB5yRqcLepf9iII=; b=u3xw1gXsEU1f5H4DSOEnLFER6BqpUvcLDb1YtN+HkOumiIi9ucInEoLvbxtNLy5EIf kwT67uUiCQv5u+QNSO6bK8GBA7TShGdAbU/ravrqxLrmG2PBNkqptvE687fFhnUtZ5Gq x7woET/Ks52KD/nn+4Lnh7HNRwjHWanp6cFDgYgEZp0WlfJ7CE/kgVT3Ord6vNBu9Kpu npFluDFh2s968vdhH8J5bM4wKAP7pha43v2FmJxs2NJRuFjTaITkTUgw9XT8BqZeXpMd zZofuDXEyDNZ52VImhsyI5c1VgvjGJ9Q4+4Zx7wDx6yioZKDo2AeQp/XRnfAa0/VxPpu 7z3A== MIME-Version: 1.0 X-Received: by 10.229.77.65 with SMTP id f1mr3489319qck.25.1375116158899; Mon, 29 Jul 2013 09:42:38 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Mon, 29 Jul 2013 09:42:38 -0700 (PDT) Date: Mon, 29 Jul 2013 11:42:38 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=0023543333222d20f604e2a92e52 Subject: [clue] Draft notes from CLUE WG Session - Monday, July 29, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 16:42:43 -0000 --0023543333222d20f604e2a92e52 Content-Type: text/plain; charset=ISO-8859-1 As an FYI, I have uploaded the raw notes that the chairs have received thus far: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue In the end, due to my pleas, we had an abundance of notetakers, including Richard Ejzak, Rob Hansen, Stephen Botzko, Christer Holmberg and myself. I will try to get the summary and action item list added before the Wed. WG session. We will need at least two other notetakers for our session on Wed. afternoon. If folks can volunteer before the session we can spend our time discussing real stuff. Thanks, Mary. --0023543333222d20f604e2a92e52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As an FYI, I have uploaded the raw notes that the chairs h= ave received thus far:

In the end, due to my pleas, we had an abundance = of notetakers, including Richard Ejzak, Rob Hansen, Stephen Botzko, Christe= r Holmberg and myself. =A0=A0

I will try to get the summ= ary and action item list added before the Wed. WG session.

We will need at least two other notetakers for our sess= ion on Wed. afternoon. =A0If folks can volunteer before the session we can = spend our time discussing real stuff.

Thanks,
Mary.=A0
--0023543333222d20f604e2a92e52-- From pkyzivat@alum.mit.edu Mon Jul 29 13:35:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909BE21F9971 for ; Mon, 29 Jul 2013 13:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFpHsx5WxGN6 for ; Mon, 29 Jul 2013 13:34:55 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68921F997B for ; Mon, 29 Jul 2013 13:34:55 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 6JlU1m00617UAYkAELavEf; Mon, 29 Jul 2013 20:34:55 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta13.emeryville.ca.mail.comcast.net with comcast id 6LYh1m00G4YBfqS8ZLYkBA; Mon, 29 Jul 2013 20:32:52 +0000 Message-ID: <51F6D169.80906@alum.mit.edu> Date: Mon, 29 Jul 2013 22:32:41 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Leslie References: <51E75A6C.3090707@nteczone.com> <20130718111602.GD5411@verdi> <51E89391.30507@nteczone.com> <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> In-Reply-To: <20130729045138.GB3328@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375130095; bh=hTtLfaxOVi4M7SzD2tk1ANUeis0fIkugl2EAUxP0Fv0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CmEdwXT2Ym++z/VmRq0yRd646H+UwHNMUt5spink5NgcwbhK+A5PG2NEZLVC324x4 nkIEOyeZVMMw2moLsojvA0P2+dfy2b+sqJzuQdbeJV5d/3MCzW3L31u+U0LB/HS4rA wdRXKjVdYcPOVhMRhwc3vO4cIsrVpm6F/l1KVG5so4NoHB/EVGTeyW532td6Ami46U mgPRsSWkCITwgHcJDXY/QuIqD0ncn5zJLJOcHfVA6SWsML+Ev28L81MumXYiMB45cO nkNfkn2CzIvT9vMFgE65KQHFQiR02yTc6tt3UHotOM9eRudmJI7yrsjmh3kD4DCq/X 0fPw3caya448g== Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 20:35:01 -0000 On 7/29/13 6:51 AM, John Leslie wrote: > Paul Kyzivat wrote: >> >> I think John should make a proposal for what we ought to have in the fw >> & data model for this, that will be "enough" without going overboard. I >> don't sense that anybody else here is competent to make this call. > > Well, you asked... "Be careful what you ask for..." I don't understand the details, but I get the gist. It sounds "plausible" to me. Here are some dumb questions: IIUC, when describing audio for a scene, it might make sense to have one CSE that contains one or more microphones and/or microphone sets, and one or more additional CSEs that contain mixes. Is that right? If a microphone set consists of several audio streams, then doesn't that mean it must be multiple captures? But if it has a single description, currently the only place we have to put that is on a CSE. That in turn means that if a CSE contains a microphone set, then all the captures in it must be part of the same microphone set. So then we couldn't have a CSE that had multiple microphone sets, or one set and some individual microphones or mixes. Maybe that's ok - I'm not sure. If not, then we may need some other aggregate mechanism to describe a microphone set. Thanks, Paul > I see three different kinds of audio > > - microphones; > - microphone sets; and > - mixes. > > A microphone is simply a transducer, with gain "fixed" for the > duration of its use. Its characteristics include > > - capture point; > - point on axis of capture; and > - sensitivity pattern. > > The first two are where it's placed and where it's "pointing". > The third is a sensitivity graph. For starters we should have three > pre-defined graphs: > > - generic omni; > - generic cardioid; and > - unknown. > > There will eventually be others, e.g. "shotgun", and we should allow > for accurate graphs for specific microphones; but I don't propose any > more at this time. > > A microphone set is a collection of transducers in a fixed arrangement. > The common case right now is "XY stereo" which is two transducers at > 90-degrees to each other. Each transducer has its own characteristics > and its own audio stream; but it will be set up as a single unit with: > > - capture point; > - point on axis of capture; and > - list of individual transducers with offsets. > > A "mix" is a managed combination of sound sources (which can no longer > be individually identified). The gain of each can be varied at any time, > without warning or even notice of change. Mixes should be given human- > readable names, and should also have a machine-readable tag. Initially, > that tag should cover: > > - room mix; and > - presentation mix. > > More will follow eventually, but I see no reason to discuss those now. > > The output of a mix will be one or more audio streams, specifically > we should expect: > > - mono; > - stereo; and > - surround. > > ==== > > Discussion, IMHO, should be on the list. > > I will not be in Berlin; but I will be following today's session > via MeetEcho. I can type fast enough to answer questions in jabber, > should you have any... > > -- > John Leslie > From pkyzivat@alum.mit.edu Mon Jul 29 14:28:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85C621F9C86 for ; Mon, 29 Jul 2013 14:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWznGE3cPIlR for ; Mon, 29 Jul 2013 14:28:10 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id A0DDA21F9C05 for ; Mon, 29 Jul 2013 14:28:10 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 6M311m0031smiN4A8MUAgN; Mon, 29 Jul 2013 21:28:10 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta20.emeryville.ca.mail.comcast.net with comcast id 6MS01m00S4YBfqS8gMS3PT; Mon, 29 Jul 2013 21:26:08 +0000 Message-ID: <51F6DDE7.1070206@alum.mit.edu> Date: Mon, 29 Jul 2013 23:25:59 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> <51F28FA7.5090603@alum.mit.edu> <51F5BB45.5010009@nteczone.com> In-Reply-To: <51F5BB45.5010009@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375133290; bh=+XpTT/GhFja7OmzPw27OATUbc/pdW/xDnj80OEqZ8CE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JioXWjJVBfNMCy3aKD4/WSJlpP/xXA0mdzdqqKiz42Bsq2oJBiCteX5ZrD+G+ZXhz RBitXr5guMn4XDwEp3OB5rrZ8seMdYk0iyk2Fu1c3S8FVtUiGM8vnee6NAcTbNQrHW w198LMStf/X7GZc0Cjssn5rb1xhkZKOcI3ouPtHyrsD+76X0Y3m6idudGcj0Fz0HfC CHVsN+MN7NIkp+fw6s6sF+riDVwAqxEh55L9RknTwRM34EvWDssXf7cegS/vxZ6glB ZsN+3l4AkrmwqM3NOzpD2z/2ErL9D3Fi6fHinazgzd1hKHvI3zl2NtU29UgQiDVyQ6 2tKbjlm9s2qww== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:28:16 -0000 On 7/29/13 2:45 AM, Christian Groves wrote: > Hello Paul, > > Please see below. > > Regards, Christian > > On 27/07/2013 1:03 AM, Paul Kyzivat wrote: >> On 7/26/13 1:12 AM, Christian Groves wrote: >> >>> [CNG] Perhaps we should just make this a btye 0-255 possible values? And >>> perhaps we need to say there is no inference to how much more important >>> the priority based on the position. e.g. 1 is not 100x times more >>> important than 100. If you have two captures one with priority 1 and the >>> other priority 100 the priority one capture is simply more important. No >>> difference to 1 & 2, 1 & 50 etc. >> >> Why would we want to restrict to 256 values? To save 3 bytes in the >> implementation? >> >> While people can probably settle with that, why? > > [CNG] Its not to save the 3 bytes in signalling. I just think it is > logically better to give a finite set of priorities within the realms of > day to day experience. If I was to set this via some UI I think its > easier present a range 0 - 256 rather than 0-2,147,483,647. I don't imagine a UI for setting these, at least not for regular people. Do you? Its more conceivable that a UI for users might *show* priorities. But then you only show the ones that were used. When I was looking at one example, I was thinking I would like to use values like: - 100, 101, 102, ... for one CSE or scene - 200, 201, 202, ... for a different CSE or scene One can easily use up more than 256 that way. Another possibility is to use real numbers in range [0,1]. Then I can use 0.1, 0.2, ... or 0.10, 0.11, 0.12,... 0.20, 0.21, ... and can in general stick something between any two I have previously defined. Thanks, Paul >>>> Implementations are going to need a representation for all values, >>>> including the highest and lowest. >>> [CNG] Strictly speaking we probably only need the "highest" priority. >>> The lowest is effectively the number before or after (depending on >>> whether 1 is highest or not) those that have been set in the captures. >> >> The highest is zero, so that is easy. The lowest you can specify is >> currently 2^32-1. Suppose somebody decides to set some captures to >> 2^32-1, and leaves some unspecified? What value does the >> implementation give to them? >> >> So just say the the default is 2^32-1, or maxint. XML allows you to >> put a default in the schema. So we can just use that. >> >> This is assuming we want the default to be "lowest priority". If the >> default is "highest priority" then of course it is zero. > > [CNG] I'm OK with Roberta's proposal: > "the highest value = the first relevance rank (e.g. 1)" > default lowest value 255. >> >>>> If we are to represent priorities as unsigned integers, then I think >>>> both lowest and highest should fall into that range so that the >>>> implementation can use an unsigned integer too. So *if* we want the >>>> default to be lowest priority, then I would vote that we make the >>>> default be the highest value representable in the range, rather than >>>> something lower than that. >>>> >>>> I guess the question is whether we want the default to be highest >>>> priority or lowest priority. >>> [CNG] I think the "lowest priority". >> >> I don't much care. But I think it should be based on what we think the >> most common case is. Will people want to just mark a few captures as >> lower than the rest? Or just mark a few higher than the rest? >> >> 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 Christian.Groves@nteczone.com Mon Jul 29 16:53:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5721F99BF for ; Mon, 29 Jul 2013 16:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDE3JT0V8uTf for ; Mon, 29 Jul 2013 16:53:26 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4EF21F99B7 for ; Mon, 29 Jul 2013 16:53:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkDAEL/9lF20T03/2dsb2JhbAANToM7vjgEAwGBMoMYAQEBBAEBATUbFQYKEQsYCRYPCQMCAQIBFTATBgIBAYgYphiSTwSQBIQHA6xR Received: from ppp118-209-61-55.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.61.55]) by ipmail06.adl6.internode.on.net with ESMTP; 30 Jul 2013 09:23:23 +0930 Message-ID: <51F7006E.6040701@nteczone.com> Date: Tue, 30 Jul 2013 09:53:18 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> <51F28FA7.5090603@alum.mit.edu> <51F5BB45.5010009@nteczone.com> <51F6DDE7.1070206@alum.mit.edu> In-Reply-To: <51F6DDE7.1070206@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:53:27 -0000 Hello Paul, I'm thinking that this could be set by whoever is configuring the system at installation or at the start of a conference. Not something that is hard coded. So that's why I thought a more "user friendly" range would be good. Utilising 100, 101, 102, 200, 201, 202 etc... I think is more of a programmer's view on the world. I do the same thing when writing g-code for my mill but I'm not sure its a practise for telepresence endpoints. It would be good to get other views on this. Regards, Christian On 30/07/2013 7:25 AM, Paul Kyzivat wrote: > On 7/29/13 2:45 AM, Christian Groves wrote: >> Hello Paul, >> >> Please see below. >> >> Regards, Christian >> >> On 27/07/2013 1:03 AM, Paul Kyzivat wrote: >>> On 7/26/13 1:12 AM, Christian Groves wrote: >>> >>>> [CNG] Perhaps we should just make this a btye 0-255 possible >>>> values? And >>>> perhaps we need to say there is no inference to how much more >>>> important >>>> the priority based on the position. e.g. 1 is not 100x times more >>>> important than 100. If you have two captures one with priority 1 >>>> and the >>>> other priority 100 the priority one capture is simply more >>>> important. No >>>> difference to 1 & 2, 1 & 50 etc. >>> >>> Why would we want to restrict to 256 values? To save 3 bytes in the >>> implementation? >>> >>> While people can probably settle with that, why? >> >> [CNG] Its not to save the 3 bytes in signalling. I just think it is >> logically better to give a finite set of priorities within the realms of >> day to day experience. If I was to set this via some UI I think its >> easier present a range 0 - 256 rather than 0-2,147,483,647. > > I don't imagine a UI for setting these, at least not for regular > people. Do you? Its more conceivable that a UI for users might *show* > priorities. But then you only show the ones that were used. > > When I was looking at one example, I was thinking I would like to use > values like: > - 100, 101, 102, ... for one CSE or scene > - 200, 201, 202, ... for a different CSE or scene > > One can easily use up more than 256 that way. > > Another possibility is to use real numbers in range [0,1]. > > Then I can use 0.1, 0.2, ... or 0.10, 0.11, 0.12,... 0.20, 0.21, ... > and can in general stick something between any two I have previously > defined. > > Thanks, > Paul > >>>>> Implementations are going to need a representation for all values, >>>>> including the highest and lowest. >>>> [CNG] Strictly speaking we probably only need the "highest" priority. >>>> The lowest is effectively the number before or after (depending on >>>> whether 1 is highest or not) those that have been set in the captures. >>> >>> The highest is zero, so that is easy. The lowest you can specify is >>> currently 2^32-1. Suppose somebody decides to set some captures to >>> 2^32-1, and leaves some unspecified? What value does the >>> implementation give to them? >>> >>> So just say the the default is 2^32-1, or maxint. XML allows you to >>> put a default in the schema. So we can just use that. >>> >>> This is assuming we want the default to be "lowest priority". If the >>> default is "highest priority" then of course it is zero. >> >> [CNG] I'm OK with Roberta's proposal: >> "the highest value = the first relevance rank (e.g. 1)" >> default lowest value 255. >>> >>>>> If we are to represent priorities as unsigned integers, then I think >>>>> both lowest and highest should fall into that range so that the >>>>> implementation can use an unsigned integer too. So *if* we want the >>>>> default to be lowest priority, then I would vote that we make the >>>>> default be the highest value representable in the range, rather than >>>>> something lower than that. >>>>> >>>>> I guess the question is whether we want the default to be highest >>>>> priority or lowest priority. >>>> [CNG] I think the "lowest priority". >>> >>> I don't much care. But I think it should be based on what we think the >>> most common case is. Will people want to just mark a few captures as >>> lower than the rest? Or just mark a few higher than the rest? >>> >>> 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@alum.mit.edu Mon Jul 29 22:58:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A71921E80BC for ; Mon, 29 Jul 2013 22:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdFtBozL9+vz for ; Mon, 29 Jul 2013 22:58:20 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA621F9F1C for ; Mon, 29 Jul 2013 22:58:20 -0700 (PDT) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 6Vih1m0051HpZEsAFVyLiF; Tue, 30 Jul 2013 05:58:20 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta14.emeryville.ca.mail.comcast.net with comcast id 6VwA1m00L4YBfqS8aVwDR7; Tue, 30 Jul 2013 05:56:18 +0000 Message-ID: <51F7557A.7050406@alum.mit.edu> Date: Tue, 30 Jul 2013 07:56:10 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: clue@ietf.org References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> <51F28FA7.5090603@alum.mit.edu> <51F5BB45.5010009@nteczone.com> <51F6DDE7.1070206@alum.mit.edu> <51F7006E.6040701@nteczone.com> In-Reply-To: <51F7006E.6040701@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375163900; bh=Z7J0CT0GyNhwLJTlBDadbv3oUSDLxPtjSOY3gETQhWo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rgPnMjLOfBvsIZtUOjtgik+WiZhSnFl1KGdutYyS8mAhTW9zy8S9gvsejhvYeCX8N l8PKOL59JjLZRnag5iGvjZWlLna3bUTZDSapWwwcVzOJVBy4tFQg9s06vo4cE1HYnI uKGxY50LuZoOGyJmVQFnfYxpTkeZ21lVxvoGG2PLupKPeQoSoOb+yyClURupMdl8mU LjqCcBptLWBNdyjBvLX+IfTj7VWoT87rQre5ssCzn//OESPUdBNGzpCSCPew/iydVT H/ivM6VFOvSzpXJ8cBbuHdPcxS1r89PILK/JP2PfqyiJSq8XkP6a8UwTLou1wItXcU 6b36W9l4fYA7w== Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:58:25 -0000 On 7/30/13 1:53 AM, Christian Groves wrote: > Hello Paul, > > I'm thinking that this could be set by whoever is configuring the system > at installation or at the start of a conference. Not something that is > hard coded. So that's why I thought a more "user friendly" range would > be good. Utilising 100, 101, 102, 200, 201, 202 etc... I think is more > of a programmer's view on the world. I do the same thing when writing > g-code for my mill but I'm not sure its a practise for telepresence > endpoints. If the goal is to make the *range* "user friendly" for non-programmers, then it ought to be some number of decimal digits rather than powers of two. > It would be good to get other views on this. Yep. Thanks, Paul > Regards, Christian > > On 30/07/2013 7:25 AM, Paul Kyzivat wrote: >> On 7/29/13 2:45 AM, Christian Groves wrote: >>> Hello Paul, >>> >>> Please see below. >>> >>> Regards, Christian >>> >>> On 27/07/2013 1:03 AM, Paul Kyzivat wrote: >>>> On 7/26/13 1:12 AM, Christian Groves wrote: >>>> >>>>> [CNG] Perhaps we should just make this a btye 0-255 possible >>>>> values? And >>>>> perhaps we need to say there is no inference to how much more >>>>> important >>>>> the priority based on the position. e.g. 1 is not 100x times more >>>>> important than 100. If you have two captures one with priority 1 >>>>> and the >>>>> other priority 100 the priority one capture is simply more >>>>> important. No >>>>> difference to 1 & 2, 1 & 50 etc. >>>> >>>> Why would we want to restrict to 256 values? To save 3 bytes in the >>>> implementation? >>>> >>>> While people can probably settle with that, why? >>> >>> [CNG] Its not to save the 3 bytes in signalling. I just think it is >>> logically better to give a finite set of priorities within the realms of >>> day to day experience. If I was to set this via some UI I think its >>> easier present a range 0 - 256 rather than 0-2,147,483,647. >> >> I don't imagine a UI for setting these, at least not for regular >> people. Do you? Its more conceivable that a UI for users might *show* >> priorities. But then you only show the ones that were used. >> >> When I was looking at one example, I was thinking I would like to use >> values like: >> - 100, 101, 102, ... for one CSE or scene >> - 200, 201, 202, ... for a different CSE or scene >> >> One can easily use up more than 256 that way. >> >> Another possibility is to use real numbers in range [0,1]. >> >> Then I can use 0.1, 0.2, ... or 0.10, 0.11, 0.12,... 0.20, 0.21, ... >> and can in general stick something between any two I have previously >> defined. >> >> Thanks, >> Paul >> >>>>>> Implementations are going to need a representation for all values, >>>>>> including the highest and lowest. >>>>> [CNG] Strictly speaking we probably only need the "highest" priority. >>>>> The lowest is effectively the number before or after (depending on >>>>> whether 1 is highest or not) those that have been set in the captures. >>>> >>>> The highest is zero, so that is easy. The lowest you can specify is >>>> currently 2^32-1. Suppose somebody decides to set some captures to >>>> 2^32-1, and leaves some unspecified? What value does the >>>> implementation give to them? >>>> >>>> So just say the the default is 2^32-1, or maxint. XML allows you to >>>> put a default in the schema. So we can just use that. >>>> >>>> This is assuming we want the default to be "lowest priority". If the >>>> default is "highest priority" then of course it is zero. >>> >>> [CNG] I'm OK with Roberta's proposal: >>> "the highest value = the first relevance rank (e.g. 1)" >>> default lowest value 255. >>>> >>>>>> If we are to represent priorities as unsigned integers, then I think >>>>>> both lowest and highest should fall into that range so that the >>>>>> implementation can use an unsigned integer too. So *if* we want the >>>>>> default to be lowest priority, then I would vote that we make the >>>>>> default be the highest value representable in the range, rather than >>>>>> something lower than that. >>>>>> >>>>>> I guess the question is whether we want the default to be highest >>>>>> priority or lowest priority. >>>>> [CNG] I think the "lowest priority". >>>> >>>> I don't much care. But I think it should be based on what we think the >>>> most common case is. Will people want to just mark a few captures as >>>> lower than the rest? Or just mark a few higher than the rest? >>>> >>>> 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 mary.ietf.barnes@gmail.com Tue Jul 30 05:58:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3C811E81F4 for ; Tue, 30 Jul 2013 05:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuVV6YwsWmwU for ; Tue, 30 Jul 2013 05:58:42 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5321E80E3 for ; Tue, 30 Jul 2013 05:58:36 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id k5so2506421qej.2 for ; Tue, 30 Jul 2013 05:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HdYE8j+2yVFpGC/aNe+FoUklBLclp04VPBf8sVvHOls=; b=huJPqw46MnixpvWYZG0QYonOFV4X6tFiLjjzp3gf2LD7lwFPA6Gdp9yfJpaboq67gs b+Xo7/WTKu0u8sfB+oIOQx7P70/eqiW5auyqnpPV0hGfs7xOqNywne0fXlXQIfqD7bbw IaLJlS7M6in56jVRv+TO6Uu8VlC7UXzkUkJ7Z5bn0aeWKdRkwSCVMAGyBU9uSGdpAFIP bpqKHs2fyocWw3zDK7dKc9xPDWA2/GdT6OF5zxWAGzUwocuoiTdLORkVB0e10EgIx0wT +4PC9gyFicPIFgVJ6a/DegtJeHSXFKT3USaRfwqp3mzhdygojn4LhEXMfVCahGqpeYRy WJKA== MIME-Version: 1.0 X-Received: by 10.49.53.10 with SMTP id x10mr9596011qeo.46.1375189108525; Tue, 30 Jul 2013 05:58:28 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Tue, 30 Jul 2013 05:58:28 -0700 (PDT) Date: Tue, 30 Jul 2013 07:58:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bd766de500fdc04e2ba2ab4 Subject: [clue] CLUE meeting on Wed. July 31 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2013 12:58:43 -0000 --047d7bd766de500fdc04e2ba2ab4 Content-Type: text/plain; charset=ISO-8859-1 HI folks, I have updated the agenda to reflect the additional 1+ hour we will have tomorrow. There is an updated version for the FW charts (starting with slide 12) for the switched captures discussion. I strongly encourage folks to review the documents/presentations ahead of time, so that you are ready with questions and it's not the first time you are seeing the material. Also, we will be recruiting volunteers to contribute to the signaling document. We can't get the work done without people willing to contribute. Please consider how and where you are able to contribute. Regards, Mary. --047d7bd766de500fdc04e2ba2ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI folks,

I have updated the agenda to = reflect the additional 1+ hour we will have tomorrow. =A0

There is an updated version for the FW charts (starting with slide = 12) for the switched captures discussion.=A0

I strongly encourage folks to review the documents/pres= entations ahead of time, so that you are ready with questions and it's = not the first time you are seeing the material. =A0

Also, we will be recruiting volunteers to contribute to the signaling docum= ent. =A0We can't get the work done without people willing to contribute= . =A0Please consider how and where you are able to contribute.
Regards,
Mary.=A0
--047d7bd766de500fdc04e2ba2ab4-- From espeberg@cisco.com Tue Jul 30 09:27:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344CE21F99DE for ; Tue, 30 Jul 2013 09:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RetYVurnxFVQ for ; Tue, 30 Jul 2013 09:27:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3376421F9C83 for ; Tue, 30 Jul 2013 09:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2325; q=dns/txt; s=iport; t=1375201622; x=1376411222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C06HRmmCqG8j5zduYkVfskCQKE2usGE7WZd/EB1gQFE=; b=Po47xTJnNhawssFN1VMq45UX6bx/qoGEfj0l7m301yqfq/hixUl6deI7 nFWmF09W6V0qZEeIjp7Fbbx5w+qTzxYmVm1CLVH2fEkx4+fRC80fhzvk1 iL7PzH6e1/7hBIc0FvGVMCsGQliUVX/MLivMge6NgMDnhwI99Hrf2cd3D k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAKzo91GtJXHB/2dsb2JhbABbgwaBBb4TgR4WdIIkAQEBAwE6PwUHBAIBCBEEAQEBChQJBzIUCQgCBA4FCBGHcQa4W49NMQcGgxJxA6krgxSCKg X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241168186" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2013 16:27:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6UGR18Q025130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 16:27:01 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.174]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 11:27:01 -0500 From: "Espen Berger (espeberg)" To: John Leslie Thread-Topic: [clue] Data Model for audio Thread-Index: AQHOjBdp2J3h0STsdk6lwJSrAZcZo5l7jDEAgAAHeYD//7Nz4IAAdAYAgAGpYiA= Date: Tue, 30 Jul 2013 16:27:00 +0000 Message-ID: References: <20130723184052.GA8295@verdi> <51EF1DEE.9010708@nteczone.com> <20130725200444.GB8295@verdi> <51F1878E.2040703@alum.mit.edu> <20130725223520.GC8295@verdi> <51F1AB5A.5090403@alum.mit.edu> <20130729045138.GB3328@verdi> <322F6C34-1636-40D1-B54D-A06D9D9FED6D@unina.it> <20130729094108.GC3328@verdi> In-Reply-To: <20130729094108.GC3328@verdi> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Data Model for audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2013 16:27:09 -0000 Hi John=20 A do understand that describing the audio environment is useful. My request= is to add some examples and guiding on how the information should be used = to be useful to a media receiver.=20 As an example a receiver of a single audio stream does not need to know if = the original audio pickup is done by a single microphone or by mixing two m= icrophones together. It is common to have two (or more) microphone in the = same room to have proper microphone pickup in large rooms and send a mixed = audio stream from the room. In other cases you use multiple microphones t= o do spatial audio, so it depends on the room setup.=20 Is the audio model meant to describe physical or logical aspect of the audi= o setup? Or better, make it flexible to allow the media provider to choose = what to describe.=20 I look forward to see a concrete proposal for an audio model. =20 Regards=20 -Espen=20 -----Original Message----- From: John Leslie [mailto:john@jlc.net]=20 Sent: 29. juli 2013 11:41 To: Espen Berger (espeberg) Cc: clue@ietf.org Subject: Re: [clue] Data Model for audio Espen Berger (espeberg) wrote: >=20 > Together with the framework and data model suggestion we should also=20 > do detailed use cases to have common understanding of what we want to=20 > achieve with an extended audio model within CLUE. I'm not unwilling to do this, although I can't tackle it today and may n= ot be able to do so anytime this week. > Without clear use cases it is hard to discuss the extensions and how=20 > they can be applied to real-life use cases. What I proposed is describing what microphones and mixes _are_. I don't = see how use-cases have anything to do with that. > It is not clear to me how much of the capture information I need to=20 > play out audio, so I need examples to be able to review the suggestions. You don't need _any_ of this information to play an audio stream. OTOH, it's easy to imagine potential uses where this information would info= rm the process of making an _effective_ audio environment. We should not (IMHO) prevent such an outcome based upon how many of us w= ant to do this right away. (I will be mostly off-Net until Tuesday morning.) -- John Leslie From ron.even.tlv@gmail.com Wed Jul 31 08:07:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0221F9E8B for ; Wed, 31 Jul 2013 08:07:08 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20KabNhL5gpE for ; Wed, 31 Jul 2013 08:07:07 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1732421F9E7C for ; Wed, 31 Jul 2013 08:07:07 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so876800pbc.35 for ; Wed, 31 Jul 2013 08:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=m3KL7D5bNHRtDyzpK4UsJPxx/3cJ+nrKgNJWj9b7WSI=; b=rurW++ZwUSx3kzhYBVlmIbOaKlTgnQHSO9PeKJwkOfJ2dvc916Q59lBPG+/SYr1M96 kZEGSDswzvg5SpCrxfybOKNnB4ewJ27SpSw+eLm3iuYU5ssQuYekEBMNEx+B8CW/pAxd kohkBh0uHbC0oBIA4CNFLzZdU2kcBaoaVpwb2PQj3O2dqUPKWvw7ATwwng3uwK7Raj1R gwEI3Dhvm6uaV8P5/q67mrYQ6pdeyT2L3nLY0BNsPGHz5S+ylpylHf+PoP6pYux9BMdu Vt/zk9J6k1D2hIyRUMPhkONqX/ztSLPa+s7vNmUnrfKu+r0mJZWzPp3d9vdiuJBGwr3c TkiQ== X-Received: by 10.66.122.41 with SMTP id lp9mr82416979pab.6.1375283226798; Wed, 31 Jul 2013 08:07:06 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:94d7:eace:737a:6444]) by mx.google.com with ESMTPSA id qv4sm2689732pbc.16.2013.07.31.08.07.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 08:07:05 -0700 (PDT) From: "Roni Even" To: Date: Wed, 31 Jul 2013 18:05:03 +0300 Message-ID: <00f401ce8dff$58527960$08f76c20$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01CE8E18.7DA074B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6N/wr9ecuL2r5FTGWcBcW3HfT8eg== Content-Language: en-us Subject: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 15:07:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F5_01CE8E18.7DA074B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In the following paragraph the text says that Bob has no simultaneous constrains and list all three captures but the advertisement have only to individual encodes so it look like he can send only two captures? "Bob also sends his CLUE Advertisement (ADVERTISEMENT 2). He advertises two static captures representing his cameras. He also includes a single composed capture for single-screen systems, in which he will composite the two camera views into a single video stream. All three captures are in a single capture scene, with suitable capture scene entries to tell Alice that she should either subscribe to the two static captures, or the single composed capture. Bob also has no simultaneity constraints, so includes all three captures in one simultaneous set. Bob also includes a single encoding group with two encoding IDs: "foo" and "bar"." Roni ------=_NextPart_000_00F5_01CE8E18.7DA074B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In the = following paragraph the text says that Bob has no simultaneous = constrains and list all three captures but the advertisement have only = to individual encodes so it look like he can send only two = captures?

=

“Bob also sends his CLUE Advertisement = (ADVERTISEMENT 2).  He

   advertises two static captures = representing his cameras.  He also

   includes a single composed capture for = single-screen systems, in

   which he will composite the two camera = views into a single video

   stream.  All three captures are in a = single capture scene, with

   suitable capture scene entries to tell = Alice that she should either

   subscribe to the two static captures, or = the single composed capture.

   Bob also has no simultaneity constraints, = so includes all three

   captures in one simultaneous set.  = Bob also includes a single

   encoding group with two encoding IDs: = "foo" and "bar".”

 

Roni

 

------=_NextPart_000_00F5_01CE8E18.7DA074B0-- From rohanse2@cisco.com Wed Jul 31 13:36:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992C911E8113 for ; Wed, 31 Jul 2013 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94o-5jACbiUI for ; Wed, 31 Jul 2013 13:35:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1211E8111 for ; Wed, 31 Jul 2013 13:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9877; q=dns/txt; s=iport; t=1375302951; x=1376512551; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qiF5BQsxg9Uhpo5FwCexyLdu0xd4ZLefpAbNbDGGf7M=; b=ORFkSRVmncEPsaHwvWLfbS1QSxzFgZFc2vkC3bwvWD68xP/K+Ge08HVp UzniFx3tPEgoSwelyVoYC4WslTfHSXeJvdUqEJ+xBveJ4JxL00qN9IAE2 aj0eiO9wzccrEz89KZeN5zIWagWaRp2AmoC8DYs2pWEhPeACzu0kLQNhS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFANNz+VGtJV2d/2dsb2JhbABbgkJENVC+KoEZFnSCJAEBAQQtXAIBCA4DBAEBCwIbBzIUCQgBAQQBEgiICLkKj1Y3AYMYcwOpLIMUgio X-IronPort-AV: E=Sophos;i="4.89,789,1367971200"; d="scan'208,217";a="241932630" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 20:35:50 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VKZoaN024337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 20:35:50 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.125]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 15:35:49 -0500 From: "Robert Hansen (rohanse2)" To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 Thread-Index: Ac6N/wr9ecuL2r5FTGWcBcW3HfT8egALcIaw Date: Wed, 31 Jul 2013 20:35:35 +0000 Message-ID: References: <00f401ce8dff$58527960$08f76c20$@gmail.com> In-Reply-To: <00f401ce8dff$58527960$08f76c20$@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.73.163] Content-Type: multipart/alternative; boundary="_000_C6252EA94E00E44EADC3A2FEB59D4402D4FD98xmbalnx07ciscocom_" MIME-Version: 1.0 Subject: Re: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 20:36:02 -0000 --_000_C6252EA94E00E44EADC3A2FEB59D4402D4FD98xmbalnx07ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Er, yes, my understanding was that this is correct behaviour. Bob is a two-= camera system and the implementation allows a maximum of two encodings to b= e sent. However, he has three captures he can send (the two static camera s= ources and the composed source). There are no simultaneity constraints with= any of these captures - sending any one doesn't prevent him sending anothe= r one, so all of them go in one simultaneous set. That seems correct by my understanding, as I though the primary point of si= multaneous sets was to prevent cases that are physically impossible (eg, Ev= e has the option for a capture that is a zoomed-in camera view, and other o= ption for a capture than is a zoomed-out view from the same camera - there'= s no way for her to do both simultaneously, which she will express by not i= ncluding them in the same simultaneous set). Rob From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 31 July 2013 17:05 To: clue@ietf.org Subject: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 Hi, In the following paragraph the text says that Bob has no simultaneous const= rains and list all three captures but the advertisement have only to indivi= dual encodes so it look like he can send only two captures? "Bob also sends his CLUE Advertisement (ADVERTISEMENT 2). He advertises two static captures representing his cameras. He also includes a single composed capture for single-screen systems, in which he will composite the two camera views into a single video stream. All three captures are in a single capture scene, with suitable capture scene entries to tell Alice that she should either subscribe to the two static captures, or the single composed capture. Bob also has no simultaneity constraints, so includes all three captures in one simultaneous set. Bob also includes a single encoding group with two encoding IDs: "foo" and "bar"." Roni --_000_C6252EA94E00E44EADC3A2FEB59D4402D4FD98xmbalnx07ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Er, yes, my understand= ing was that this is correct behaviour. Bob is a two-camera system and the = implementation allows a maximum of two encodings to be sent. However, he ha= s three captures he can send (the two static camera sources and the composed source). There are no simultaneity = constraints with any of these captures – sending any one doesn’= t prevent him sending another one, so all of them go in one simultaneous se= t.

 

That seems correct by = my understanding, as I though the primary point of simultaneous sets was to= prevent cases that are physically impossible (eg, Eve has the option for a= capture that is a zoomed-in camera view, and other option for a capture than is a zoomed-out view from the sa= me camera – there’s no way for her to do both simultaneously, w= hich she will express by not including them in the same simultaneous set).<= o:p>

 

Rob<= /p>

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 31 July 2013 17:05
To: clue@ietf.org
Subject: [clue] draft-kyzivat-clue-signaling-04 - section 6 question= 1

 

Hi,

In the following paragraph the = text says that Bob has no simultaneous constrains and list all three captur= es but the advertisement have only to individual encodes so it look like he can send only two captures?

 

“Bob also sends his CLUE = Advertisement (ADVERTISEMENT 2).  He

   advertises two sta= tic captures representing his cameras.  He also

   includes a single = composed capture for single-screen systems, in

   which he will comp= osite the two camera views into a single video

   stream.  All = three captures are in a single capture scene, with

   suitable capture s= cene entries to tell Alice that she should either

   subscribe to the t= wo static captures, or the single composed capture.

   Bob also has no si= multaneity constraints, so includes all three

   captures in one si= multaneous set.  Bob also includes a single

   encoding group wit= h two encoding IDs: "foo" and "bar".”<= /span>

 

Roni

 

--_000_C6252EA94E00E44EADC3A2FEB59D4402D4FD98xmbalnx07ciscocom_--