From gonzalo.camarillo@ericsson.com Fri Mar 1 01:19:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94421F85BF; Fri, 1 Mar 2013 01:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCE+mp0EK1gu; Fri, 1 Mar 2013 01:19:05 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8E21F858E; Fri, 1 Mar 2013 01:19:01 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-88-513072843573 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.C8.19728.58270315; Fri, 1 Mar 2013 10:19:01 +0100 (CET) Received: from [131.160.126.178] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Mar 2013 10:19:01 +0100 Message-ID: <51307284.7090603@ericsson.com> Date: Fri, 1 Mar 2013 11:19:00 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW5rkUGgwdVl/BYPts9ltNjZMoHF YuryxywWSztPsVtMufCIxYHVY8rvjaweLUfesnosWfKTyePL5c9sASxRXDYpqTmZZalF+nYJ XBmLb/kX/OOp+Noi3cB4kKuLkZNDQsBEYkPLexYIW0ziwr31bF2MXBxCAicZJT69OcsGkhAS WMMocX6PI4jNK6At0fS3kQnEZhFQkWhoegHWzCZgIbHl1n0gm4NDVCBK4so+S4hyQYmTM5+A lYgI6Ens75jGCDKfWeA3o8TtmycYQeqFBaIlvi5NhVjlI3H+9nlmEJtTwFeipWUiO8RtkhKL pnWCzWEWMJA4smgOK4QtL9G8dTYzRK+2xPJnLSwTGIVmIVk9C0nLLCQtCxiZVzGy5yZm5qSX G21iBIb1wS2/VXcw3jkncohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG Vf/sPieqxoXv1EhS7d/3Wv3eaX8u4Wf71xufWH03ubUk/trm50YuWVEPOTK3nXmUveZsY8Cx mIC6anGvfwZ7+7hu9Cb67fe5Yzz/pATH8bX3nWTvTLtnb/j+sfpa3fkLORen8tzY0mOVWumx TazFQn9rZ9fS8vkqpiumlf3PSOVZkZKxXmmOEktxRqKhFnNRcSIAwqnyNjkCAAA= Cc: "xrblock@ietf.org" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:19:06 -0000 Authors, could you please fix the title of the draft per Ali's suggestion below? You can submit a new revision of the draft addressing this issue once the IETF LC on it is over. Thanks, Gonzalo On 25/02/2013 11:48 AM, Ali C. Begen (abegen) wrote: > -----Original Message----- > From: "Huangyihong (Rachel)" > Date: Monday, February 25, 2013 3:28 AM > To: "Ali C. Begen" , > "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" > > Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" > > Subject: RE: [MMUSIC] SDP Directorate: Review of > draft-ietf-xrblock-rtcp-xr-decodability-07 > >> Technical Issues: >> ----------------- >> 1) I am puzzled why you named the new block as "non-psi-ts-decodability". >> It does not follow what you have in the title. I also did not get the >> "non" part. >> >> [Rachel]: To get consistent with the title we used, how about we propose >> to change the block name in SDP as "ts-psi-indep-decodability"? > > I see that you already submitted a revision. Your current title says: > > RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Program > Specific Information (PSI) Independent Transport Stream (TS) > Decodability Statistics Metric reporting > > > This still does not make sense to me. "Transport Stream" should be before > "Program Specific Information". My other comment on the title was it > should be "Š Metrics Reporting" not "Metric reporting". > > -acbegen > > From rachel.huang@huawei.com Fri Mar 1 01:24:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20D021F8717; Fri, 1 Mar 2013 01:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pn-Ws4mMnx3; Fri, 1 Mar 2013 01:24:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8705421F8698; Fri, 1 Mar 2013 01:24:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOY17428; Fri, 01 Mar 2013 09:24:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 09:24:33 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 09:24:45 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 1 Mar 2013 17:24:40 +0800 From: "Huangyihong (Rachel)" To: Gonzalo Camarillo , "Ali C. Begen (abegen)" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 Thread-Index: AQHOEtmU4++bSb9NUky+3cwP5OU1O5iKPXwQgACdmICABTS6AIAAhzOQ Date: Fri, 1 Mar 2013 09:24:39 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4571D058@nkgeml501-mbs.china.huawei.com> References: <51307284.7090603@ericsson.com> In-Reply-To: <51307284.7090603@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mmusic@ietf.org" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" , "xrblock@ietf.org" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:24:52 -0000 Hi Gonzalo, Already fixed. The 09 version has addressed this issue. http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xrblock-rtcp-xr-decodability-= 09 Best Regards! Rachel -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Friday, March 01, 2013 5:19 PM To: Ali C. Begen (abegen) Cc: Huangyihong (Rachel); draft-ietf-xrblock-rtcp-xr-decodability@tools.iet= f.org; mmusic@ietf.org; xrblock@ietf.org Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr= -decodability-07 Authors, could you please fix the title of the draft per Ali's suggestion below? You can submit a new revision of the draft addressing this issue once the IETF LC on it is over. Thanks, Gonzalo On 25/02/2013 11:48 AM, Ali C. Begen (abegen) wrote: > -----Original Message----- > From: "Huangyihong (Rachel)" > Date: Monday, February 25, 2013 3:28 AM > To: "Ali C. Begen" , > "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" > > Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" > > Subject: RE: [MMUSIC] SDP Directorate: Review of > draft-ietf-xrblock-rtcp-xr-decodability-07 >=20 >> Technical Issues: >> ----------------- >> 1) I am puzzled why you named the new block as "non-psi-ts-decodability"= . >> It does not follow what you have in the title. I also did not get the >> "non" part. >> >> [Rachel]: To get consistent with the title we used, how about we propose >> to change the block name in SDP as "ts-psi-indep-decodability"? >=20 > I see that you already submitted a revision. Your current title says: >=20 > RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Program > Specific Information (PSI) Independent Transport Stream (TS) > Decodability Statistics Metric reporting >=20 >=20 > This still does not make sense to me. "Transport Stream" should be before > "Program Specific Information". My other comment on the title was it > should be "=A9 Metrics Reporting" not "Metric reporting". >=20 > -acbegen >=20 >=20 From gonzalo.camarillo@ericsson.com Fri Mar 1 01:26:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5571521F84D9; Fri, 1 Mar 2013 01:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkZd0qIOFGVu; Fri, 1 Mar 2013 01:26:39 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6421F84CC; Fri, 1 Mar 2013 01:26:38 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-04-5130744d20a7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7F.FD.32353.D4470315; Fri, 1 Mar 2013 10:26:37 +0100 (CET) Received: from [131.160.126.178] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Mar 2013 10:26:37 +0100 Message-ID: <5130744D.60505@ericsson.com> Date: Fri, 1 Mar 2013 11:26:37 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Huangyihong (Rachel)" References: <51307284.7090603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB4571D058@nkgeml501-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4571D058@nkgeml501-mbs.china.huawei.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvja5viUGgwfHT5hYPts9ltNjZMoHF YuryxywWSztPsVtMufCIxYHVY8rvjaweLUfesnosWfKTyePL5c9sASxRXDYpqTmZZalF+nYJ XBkrGxewFbwSqpi+LaGBcQd/FyMHh4SAicTcpeJdjJxAppjEhXvr2boYuTiEBE4yStx4dJIZ wlnDKLH/yQV2kCpeAU2Jy4dug9ksAioS76afBLPZBCwktty6zwIyVFQgSuLKPkuIckGJkzOf sIDYIkC7rj7sYwSZySzwlVHi6u+zTCD1wgLREl+XpkLs2sYo8bp1BxtIA6dAmMT3D1sZIa6T lFg0rRNsELOAnkRL10lGCFteonnrbGYQW0hAW2L5sxaWCYxCs5DsnoWkZRaSlgWMzKsY2XMT M3PSy803MQJD++CW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY648b81cZ+HfXHscZ6QHynhxpV5yvjL7HI/62um/NoVaGu2b9U9WLjD2RMrdVw7ek2Vf hhdtu7rmp7e0xpsrMbNk8gt5Ha4pbtjw7UCAcXvrobnrPwT5/WrhOdzPuHH9TZ7ePRHa0hUX vrKU9f2IjYxY9HTe7/L4WzIuqm3TH5es2iKQulZjhxJLcUaioRZzUXEiAD8/i+Y7AgAA Cc: "mmusic@ietf.org" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" , "xrblock@ietf.org" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:26:40 -0000 Hi Rachel, thanks. I had missed that. Cheers, Gonzalo On 01/03/2013 11:24 AM, Huangyihong (Rachel) wrote: > Hi Gonzalo, > > Already fixed. The 09 version has addressed this issue. > http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-decodability-09 > > Best Regards! > Rachel > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Friday, March 01, 2013 5:19 PM > To: Ali C. Begen (abegen) > Cc: Huangyihong (Rachel); draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org; mmusic@ietf.org; xrblock@ietf.org > Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 > > Authors, > > could you please fix the title of the draft per Ali's suggestion below? > You can submit a new revision of the draft addressing this issue once > the IETF LC on it is over. > > Thanks, > > Gonzalo > > On 25/02/2013 11:48 AM, Ali C. Begen (abegen) wrote: >> -----Original Message----- >> From: "Huangyihong (Rachel)" >> Date: Monday, February 25, 2013 3:28 AM >> To: "Ali C. Begen" , >> "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" >> >> Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" >> >> Subject: RE: [MMUSIC] SDP Directorate: Review of >> draft-ietf-xrblock-rtcp-xr-decodability-07 >> >>> Technical Issues: >>> ----------------- >>> 1) I am puzzled why you named the new block as "non-psi-ts-decodability". >>> It does not follow what you have in the title. I also did not get the >>> "non" part. >>> >>> [Rachel]: To get consistent with the title we used, how about we propose >>> to change the block name in SDP as "ts-psi-indep-decodability"? >> >> I see that you already submitted a revision. Your current title says: >> >> RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Program >> Specific Information (PSI) Independent Transport Stream (TS) >> Decodability Statistics Metric reporting >> >> >> This still does not make sense to me. "Transport Stream" should be before >> "Program Specific Information". My other comment on the title was it >> should be "© Metrics Reporting" not "Metric reporting". >> >> -acbegen >> >> > From ted.ietf@gmail.com Fri Mar 1 16:23:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3E21E80F4; Fri, 1 Mar 2013 16:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylhFF8YOi2IF; Fri, 1 Mar 2013 16:23:11 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CD39121E80CA; Fri, 1 Mar 2013 16:23:10 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so3182297iak.1 for ; Fri, 01 Mar 2013 16:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=f5vy852zqwP6/1fPqMbzces/WjdZ6gBs40zIZt84N5w=; b=MMbqfQa0bI3E48oa9thmXYkIAThmxfdWdW3FOxno5NpQK9aScc9zKXVvhxIyMQOwOQ 2NGLBzT8IO6qSM2PRfEiOM9Fs+77Fe6YqyR5RrWaNdxtsZBS0n3nGfidGcc01OWS/CRC XGAjAAL4n9Ma3WT4XvaI/mWg3oEh3u1W+lDDl/An1rmMwOT9hDPeK/tYKT/ZR0juzJa8 I0d7HTeS0rSqfAfZtTKc0OY2Gl2sexta3sIMQXgFHLzprpIKod0rsv/dDN6Q7p0eCu3G OfGsyv8XwMMZODI5fIGuuEYaiuy0ysjkMEfHNnR5Byv+Ok9ZJzcM4bWzvG5vXGMTNKJT twsg== MIME-Version: 1.0 X-Received: by 10.43.91.5 with SMTP id bk5mr8893940icc.20.1362183790391; Fri, 01 Mar 2013 16:23:10 -0800 (PST) Received: by 10.43.135.202 with HTTP; Fri, 1 Mar 2013 16:23:10 -0800 (PST) Date: Fri, 1 Mar 2013 16:23:10 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: multipart/mixed; boundary=bcaec518692cf1fbab04d6e62095 Subject: [MMUSIC] Extremely drafty minutes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 00:23:13 -0000 --bcaec518692cf1fbab04d6e62095 Content-Type: text/plain; charset=ISO-8859-1 Howdy, I've been working on minutes for the interim meeting last month; I've attached the current draft. It needs *extensive* review, as I had planned to work off recordings for two days, and they turned out to be available for only half of one. Several folks have volunteered their notes, but I have not made nearly enough progress. I've decided that it's better to have something out than nothing, so here they are, in the current state. Please review them and provide input; I will continue to work on them, but if we don't get more input, they will be *terrible*. My apologies for the plan going awry on this, and for the delay. I kept hoping that more time spent with them would make them coherent; in large part, I suspect that helped very little all. Please excuse that and help us correct it, thanks, Ted Hardie --bcaec518692cf1fbab04d6e62095 Content-Type: text/plain; charset=UTF-8; name="RTCWEBMMUSICJointInterimminutes.txt" Content-Disposition: attachment; filename="RTCWEBMMUSICJointInterimminutes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hds104840 77u/RmVicnVhcnkgNS03dGgsIDIwMTMNClJUQ1dFQi9NTVVTSUMgSm9pbnQgSW50ZXJpbSBNaW51 dGVzDQpNTVVTSUMgQ2hhaXJzOiBGbGVtbWluZyBBbmRyZWFzZW4sIEFyaSBLZXLDpG5lbg0KUlRD V0VCIENoYWlyczogVGVkIEhhcmRpZSwgQ3VsbGVuIEplbm5pbmdzLCBNYWdudXMgV2VzdGVybHVu ZCAobm90IHByZXNlbnQpDQpQcm9jZWVlZGluZ3M6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9wcm9jZWVkaW5ncy5odG1sDQpSZWNvcmRp bmdzOiBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/QVQ9cGImU1A9 TUMmcklEPTY1ODU1MzUyJnJLZXk9MTA5OTc4NTRkNGI4NGFmNSxodHRwczovL2Npc2NvLndlYmV4 LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/QVQ9cGImU1A9TUMmcklEPTY1ODg3Njg3JnJLZXk9OGMy MTdjYzEzYzllMGVhNw0KTm90ZSB0YWtlcnM6ICBNYXJ5IEJhcm5lcywgU3BlbmNlciBEYXdraW5z LCBBcmkgS2Vyw6RuZW4sIEFkYW0gUm9hY2gsIFRpbSBUZXJyaWJlcnJ5IA0KDQoNCg0KDQoNCg0K RmVicnVhcnkgNXRoDQoNCg0KVG9waWM6IEdlbmVyYWwgSW50cm9kdWN0aW9uIHRvIFNEUCBpc3N1 ZXMgcmFpc2VkIGJ5IFJUQ1dFQiB3b3JrDQpQcmVzZW50YXRpb246IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9zbGlkZXMvc2xpZGVzLWlu dGVyaW0tMjAxMy1ydGN3ZWItMS0yLnBwdHgNCg0KDQpQYXJ0aWNpcGFudHMgZGlzY3Vzc2VkIGJv dGggdGhlIElFVEYgYW5kIFdlYlJUQyB1c2Ugb2YgdGVybXMgbGlrZSDigJxtZWRpYSBzdHJlYW3i gJ0gYW5kIHRyYWNrLCBhdHRlbXB0aW5nIHRvIHdvcmsgdGhyb3VnaCB0byBhIGNvbW1vbiB2b2Nh YnVsYXJ5IGZyb20gYSBzZXQgdGhhdCBpcyBjdXJyZW50bHkgc29tZXdoYXQgY29uZnVzaW5nLiAg VGhlcmUgd2VyZSBzdWdnZXN0aW9ucyB0aGF0IHRoZSBXZWJSVEMgZ3JvdXAgY29uc2lkZXIgY2hh bmdpbmcgTWVkaWFTdHJlYW0gdG8gTWVkaWFTdHJlYW1UcmFja1NldCwgaW4gb3JkZXIgdG8gaGVs cCBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgdGhhdCB3aGF0IGlzIG5vdyBhIE1lZGlhU3RyZWFtIG1h eSBjb250YWluIG1lZGlhIGluIG11bHRpcGxlIHRyYWNrcywgYnV0IHRoZXNlIGRpZCBub3QgaGF2 ZSBjb25zaXN0ZW50IHN1cHBvcnQuICBJdCB3YXMgYWdyZWVkIHRoYXQgZXh0cmVtZSBjYXJlIGlu IHRoZSB1c2Ugb2YgdGhlIHRlcm1zIHdhcyByZXF1aXJlZC4gIFRoZSByZWxhdGlvbnNoaXAgYW1v bmcgdGhlbSBuZWVkcyB0byBiZSBleHBsaWNpdCBpbiBwYXJ0IGJlY2F1c2UgdGhlIFdlYlJUQyBn cm91cCBuZWVkcyB0byB1bmRlcnN0YW5kIGhvdyB0byBwbHVtYiB0aGUgdHJhY2tzICh3aXRoaW4g TWVkaWFTdHJlYW1zLCB3aGV0aGVyIG9uIFBlZXJDb25uZWN0aW9ucyBvciBsb2NhbCkgdG8gU0RQ LWxldmVsIGNvbnN0cnVjdHMgbGlrZSBTU1JDcy4gIA0KDQpQYXJ0aWNpcGFudHMgdGhlbiBkaXNj dXNzZWQgdGhlIHVwZGF0ZWQgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCBieSBSVENXRUIgYW5kIENM VUUsIGdvaW5nIG9mZiB0aGUgZGlzY3Vzc2lvbiBvbiBwYWdlcyAxNy0zMiBvZiB0aGUgc2FtZSBw cmVzZW50YXRpb24uICBUaGlzIGRpc2N1c3Npb24gd2FzIHdpZGUtcmFuZ2luZywgYW5kIHVuZm9y dHVuYXRlbHksIG5vdCBwZXJmZWN0bHkgY2FwdHVyZWQuICBUaGUgdGhyZWUgbWFpbiB0b3BpY3Mg d2VyZTogIFNpZ25hbGluZyBmb3Igc2Vzc2lvbnMgdGhhdCBoYXZlIG11bHRpcGxlIHNvdXJjZXMg b2YgdGhlIHNhbWUgdHlwZSBzZW50IGZyb20gYSBzaW5nbGUgZW5kcG9pbnQgYW5kIHJlY2VpdmVk IGJlIGEgcGVlciBlbmRwb2ludDsgdHJhbnNwb3J0IGFnZ3JlZ2F0aW9uOyBtdWx0aXBsZSBlbmNv ZGluZ3MgZm9yIGEgc2luZ2xlIG1lZGlhIHNvdXJjZSAoaGVyZSBtZWFuaW5nIGNhbWVyYSwgbWlj cm9waG9uZSwgb3Igc2ltaWxhcikuICBGb3Igc2lnbmFsaW5nLCBhbW9uZyB0aGUgcG9pbnRzIHJh aXNlZDogIENMVUUgYW5kIFJUQ1dFQiBsaWtlbHkgaGF2ZSB0d28gZGlmZmVyZW50IHVzYWdlIHBh dHRlcm5zLiAgRm9yIENMVUUsIG11bHRpcGxlIG1lZGlhIHNvdXJjZXMgd2lsbCBiZSBjb21tb24s IG11bHRpcGxlIGVuY29kaW5ncyBwZXIgbWVkaWEgc291cmNlIHdpbGwgYmUgdGhlIG5vcm0sICBt dWx0aXBsZSBlbmRwb2ludHMgbWF5IGJlIHZpc2libGUgZXZlbiBpbiB1bmljYXN0IHRyYW5zcG9y dCwgYW5kIHRoZXJlIG1heSBiZSBvbmUgb3IgbW9yZSBSVFAgc2Vzc2lvbi4gIEZvciBSVENXRUIs IHRoZSBjdXJyZW50IHRoZW9yeSBpcyB0aGF0IHRoZXJlIGlzIGEgc2luZ2xlIFJUUCBzZXNzaW9u IHBlciBtZWRpYSB0eXBlLCBpZiBub3QgYSBzaW5nbGUgUlRQIHNlc3Npb24gZnVsbCBzdG9wLiAg QWxsIFNTUkNzIHJlbGF0ZWQgdG8gYSBzaW5nbGUgcGVlciBjb25uZWN0aW9uICh3aGljaCBjb3Vs ZCBlbmNvbXBhc3NlcyBtb3JlIHRoYW4gb25lIE1lZGlhU3RyZWFtcyBoYXZpbmcgbW9yZSB0aGFu IG9uZSB0cmFjaykgd291bGQgY29tZSBmcm9tIGEgc2luZ2xlIFNTUkMgc3BhY2UuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClRoZSBncm91cCBhbHNvIGRpc2N1c3NlZCBob3cg dG8gaGFuZGxlIGltcGxpY2l0IFNTUkNzOyB0aGlzIGdhdmUgcmlzZSB0byBhIGxhcmdlciBtZXRh LWRpc2N1c3Npb24gb24gd2hldGhlciB0aGUgYWltIG9mIHRoZSBNTVVTSUMgd29yayB3YXMgdG8g Y3JlYXRlIHNvbWV0aGluZyB0aGF0IG1ldCBqdXN0IFJUQ1dFQuKAmXMgbmVlZHMgb3IgaGFkIGEg bGFyZ2VyIHNjb3BlLiAgQW1vbmcgdGhlIGNvbW1lbnRzOiAgSm9uYXRoYW4gTGVubm94IHBvaW50 ZWQgb3V0IHRoYXQgaXQgd2FzIE1NVVNJQ+KAmXMgam9iIHRvIHByb3ZpZGUgdG9vbHMsIHdpdGgg UlRDV0VCIGJlaW5nIGFtb25nIHRob3NlIHJlcXVlc3RpbmcgdG9vbHMuICBGbGVtbWluZyBzYWlk IHRoYXQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGNvbnN0cmFpbiB0aGUgcHJvYmxlbSBzZXQgaW4g b3JkZXIgdG8gbWFrZSBwcm9ncmVzcy4gIEhhZHJpZWwgc2FpZCB0aGF0IGluIHBhc3QgbWVldGlu Z3Mgd2XigJl2ZSBsb29rZWQgZm9yIGEgY29tbW9uIHNvbHV0aW9uLg0KDQpEZWNpc2lvbnM6IA0K DQoqIERlY2lzaW9uIC0gd2Ugd29uJ3QgdXNlIHRoZSB3b3JkcyAibWVkaWEgc3RyZWFtIiB3aXRo b3V0IGFuIGlkZW50aWZpZXIgZm9yIGNvbnRleHQNCg0KKiBBY3Rpb24gaXRlbSB0byBkZXZlbG9w IG5ldyB0ZXJtcz8gSm9uYXRoYW4gd2lsbCBwcm92aWRlIHRoZSBsaXN0IG9mIGxhZ2dhcmRzIHdo byB2b2x1bnRlZXJlZCB0byBoZWxwIGhpbSBkbyB0aGF0LCBhbmQgdGhlIGNoYWlycyB3aWxsIG5h ZyB0aGVtDQoNCiogYWN0aW9uIC0gVGVkIHdpbGwgY2FwdHVyZSBKb25hdGhhbidzIGNvbW1lbnRz IGF0IHRoZSBtaWtlIGZvciBpbmNsdXNpb24gaW4gUlRDV2ViIGRvY3VtZW50cy4gRGFsZSBXb3Js ZXkgYXNrZWQgdGhhdCAiUlRQIHNlc3Npb24iIGJlIGluY2x1ZGVkIGluIHRoZSBydW5lIHJlYWRp bmcNCg0KKiBBY3Rpb24gLSBmb3IgUmljaGFyZCBFanphayB0byB0aGluayBhYm91dCBkb2luZyBh IHVzZSBjYXNlLWJ5LXVzZSBjYXNlIGFuYWx5c2lzIG9mIHRoZSB2YXJpb3VzIGFwcHJvYWNoZXMN Cg0KU2NvcGUgb2Ygd29yayBvcHRpb25zOg0KDQpPcHRpb24gMSAtIGRyaXZlbiBieSBicm9hZGVy IFJUQ1dlYiB1c2UgY2FzZXMNCg0KMTQgaGFuZHMNCg0KT3B0aW9uIDIgLSBhZGQgQ0xVRSB1c2Ug Y2FzZXMNCg0KOSBoYW5kcw0KDQpPcHRpb24gMyAtIGFkZCBhbnkgb2ZmZXIvYW5zd2VyIHVzZSBj YXNlcw0KDQo0IGhhbmRzDQoNCg0KRmVicnVhcnkgNnRoDQpCVU5ETEUsIE9ORS1SVFAsIE1NVDpo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxMy8wMi8wNS9ydGN3ZWIv c2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTMtcnRjd2ViLTEtMC5wcHQNCg0KKiBOb3RlIC0gSWYg d2UgcHJvY2VlZCB3aXRoIE1NVCwgd2Ugc2hvdWxkIHVzZSBtPWFwcGxpY2F0aW9uIGluc3RlYWQg b2YgbT1hbnltZWRpYQ0KDQoNCiogUXVlc3Rpb24gLSBBcmUgZm9sa3MgZ2VuZXJhbGx5IG9rYXkg d2l0aCBhbnkgb2YgdGhlIGFwcHJvYWNoZXMgdGhhdCByZWR1Y2UgdGhlIG51bWJlciBvZiBsb25n LWxpdmVkIGZsb3dzIHRvIHRoaXMgbGV2ZWwgT1IgaXMgdGhlcmUgc29tZSBvdGhlciBmZWF0dXJl IGluIG9uZSBvZiB0aGUgcHJvcG9zYWxzIHlvdSBtdXN0IGhhdmUgYmVmb3JlIHRoaXMgbWVldHMg eW91ciBuZWVkcz8NCg0KDQo2IGZvciB0aGUgZm9ybWVyLCAxNyBmb3IgdGhlIGxhdHRlcg0KDQoN Cg0KDQpDdWxsZW4ncyBwbGFuIHRvIGRpZyB1cyBvdXQgb2YgdGhpcyBob2xlOmh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9zbGlkZXMvc2xp ZGVzLWludGVyaW0tMjAxMy1ydGN3ZWItMS0xMC5wZGYNCg0KDQoqIFByb3Bvc2VkIFN1cGVyc2V0 IG9mIFJlcXVpcmVtZW50IDIgLSBTaG91bGQgYmUgYWJsZSB0byBpbnRlcm9wIHdpdGggbGVnYWN5 IHdpdGhvdXQgdGhlIEpTIGRvaW5nIGFueXRoaW5nIHNwZWNpYWwuDQoNCg0KKiBQcm9wb3NlZCBS ZWxheGF0aW9uIG9mIFJlcXVpcmVtZW50IDIgLSBTaG91bGQgYmUgYWJsZSB0byBpbnRlcm9wIHdp dGggbGVnYWN5LCBidXQgbm90IG5lY2Vzc2FyaWx5IGluIG9uZSBPL0EgZXhjaGFuZ2Ugd2l0aGlu IGEgc2luZ2xlIGRpYWxvZyAod2l0aG91dCByZWx5aW5nIG9uIGZhaWx1cmUgY2FzZXMpLg0KDQoN CiogUmVxdWlyZW1lbnQgMyAtIENoYW5nZSB2aWRlbyBmbG93cyB0byBtZWRpYSBmbG93cw0KDQoN CiogUHJvcG9zZWQgUmVxdWlyZW1lbnQgLSBXaGVuIHdlIGhhdmUgYSBsYXJnZSBjb25mZXJlbmNl IHdpdGggMTAwMCdzIG9mIHBlb3BsZSwgd2UgZG9uJ3QgaGF2ZSB0byBzZW5kIG5ldyBzaWduYWxp bmcgdG8gZXZlcnkgcGFydGljaXBhbnQgb2YgdGhlIGNvbmZlcmVuY2UuDQoNCg0KKiBQcm9wb3Nl ZCBSZXF1aXJlbWVudCAtIE11c3QgYmUgYWJsZSB0byBjb25maWd1cmUgYSBzZXQgb2Ygc2ltaWxh ciBmbG93cyBzdWNoIHRoYXQgb25jZSBlc3RhYmxpc2hlZCwgdGhlIGVuZHBvaW50cyBjYW4gYWRk IG9yIHJlbW92ZSBmbG93cyB3aXRob3V0IGhhdmluZyB0byBkbyBhbiBPL0EgY3ljbGUgKGkuZS4s IHdpdGhvdXQgaGF2aW5nIHRvIGV4Y2hhbmdlIFNEUCkuDQoNCg0KKiBQcm9wb3NlZCBSZXF1aXJl bWVudCAtIEhhdmUgdGhpcyBwcm9jZXNzIHRlcm1pbmF0ZSBpbiBzb21lIGZpbml0ZSBwZXJpb2Qg b2YgdGltZS4NCg0KDQoqIFBvaW50IG9mIERpc2N1c3Npb24gLSBQbGFuIEE6IHNhbWUgcG9ydCBv biBlYWNoIG0tbGluZSBvciBkaWZmZXJlbnQgY2FuZGlkYXRlIHNldHM/DQoNCg0KKiBBY3Rpb24g LSBQbGFuIEI6IFdyaXRlIHRoZSBkcmFmdHMgdG8gZXh0ZW5kIFNEUCB0byBleHBsaWNpdGx5IGRl c2NyaWJlIG11bHRpcGxlIGNhbWVyYXMgd2l0aCBtdWx0aXBsZSBzdHJlYW1zIGZyb20gZWFjaCBj YW1lcmEgdW5kZXIgYSBzaW5nbGUgbS1saW5lLg0KDQoNCiogRGVjaXNpb24gLSBTaG91bGQgd2Ug Y29tZSB1cCB3aXRoIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBhbmQgcHJvY2VlZCB3aXRoIFBsYW4g QSBhbmQgUGxhbiBCIHdpdGggdGhlIHRpbWVsaW5lcyBvdXRsaW5lZCBoZXJlPw0KDQoNCjI0IGZv ciwgNSBhZ2FpbnN0DQoNCg0KDQoNCkRhdGFDaGFubmVsIFNEUA0KDQoNCiogQWN0aW9uIC0gSnVz dGluIHRvIGRyYWZ0IEFQSSBmb3IgU0RQLW9ubHkgY2hhbm5lbCBvcGVuDQoNCg0KKiBEZWNpc2lv biAocnRjd2ViIGhhdHMpIC0NCiAgMmEpIEluLWJhbmQgb25seSAtIDYNCiAgMmIpIFNEUCAmIGlu LWJhbmQgLSAxMA0KICAyYykgU0RQLW9ubHkgLSAxNQ0KICBXb3JrIG9uIGJvdGggd2lsbCBjb250 aW51ZSB1bnRpbCBhIGRlY2lzaW9uIGlzIHJlYWNoZWQuDQoNCg0KKiBBY3Rpb24gLSBNYXJ0aW4g YmVsaWV2ZXMgaGUgY2FuIHNlbmQgYSBwcm9wb3NhbCB0byB0aGUgbGlzdCB3aGljaCB3aWxsIGNo YW5nZSBzb21lIG1pbmRzLg0KDQoNCkZlYnJ1YXJ5IDd0aA0KDQoNCk1TSUQNCkhhcmFsZCBBbHZl c3RyYW5kDQoxLiBNZWNoYW5pc20gZm9yIGRlY2xhcmluZyBhc3NvY2lhdGlvbnMgYmV0d2VlbiBT U1JDcw0KMi4gTWlnaHQgYmUgYmV0d2VlbiBzZXNzaW9ucyAob3Igd2l0aGluIHNlc3Npb25zKQ0K RmxlbWluZzogRG9lcyB0aGlzIGluY2x1ZGUgRGF0YSBDaGFubmVscz8gSFRBOiBEYXRhY2hhbm5l bHMgZG9uJ3QgbmVlZCB0aGlzLiBNYXJ0aW46IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0aGUgYXNz b2NpYXRpb24gdG8gTWVkaWFTdHJlYW1zLiBIVEE6IFRoaXMgaXMgbWVhbnQgZm9yIG9uZSBlbmQg dG8gaWRlbnRpZnkgb25lIGVuZCBvZiBhIHRoaW5nIHVzaW5nIHRoZSBzYW1lIGlkZW50aWZpZXIg YXMgdGhlIG90aGVyIGVuZC4NCjEuIE1TSUQgc2VtYW50aWNzIGFyZSBkZWNsYXJlZCBieSBhbiBt c2lkLXNlbWFudGljIGxpbmUNCjIuIEN1cnJlbnRseSwgb25seSAiV01TIiBkZWZpbmVkIChXZWJS VEMgTWVkaWEgU3RyZWFtKQ0KMy4gTWVhbnMgIkRlbGl2ZXIgdGhlc2Ugc291cmNlcyB0byB0aGVz ZSBtZWRpYSBzdHJlYW0gdHJhY2tzIG9uIHRoZSBvdGhlciBzaWRlLiINCmRyYWZ0LWFsdmVzdHJh bmQtbW11c2ljLW1zaWQtMDIgaXMgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24uIEFwcHJvdmVkIGZv ciBhZG9wdGlvbiwganVzdCB3YWl0aW5nIG9uIGNoYXJ0ZXIgbm93Lg0KQmVybmFyZDogSSdtIGNv bmZ1c2VkIGJ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgYmVpbmcgY29tbXVuaWNhdGVk IGF0IGEgc2Vzc2lvbiBsZXZlbCBhbmQgaW5kZW50aWZ5aW5nIHN0cmVhbXMgaW4gZGlmZmVyZW50 IFJUUCBzZXNpb25zLiAoU29tZSBjbGFyaWZpY2FpdG9uIGFib3V0IHRoZSBpbnRlbmRlZCBzY29w ZSBvZiBiaW5kaW5nIGZvbGxvd3MpDQpFS1I6IElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIGV2 ZXJ5IG09IGxpbmUgaW4gdGhlIHNhbWUgTWVkaWFTdHJlYW0gaGFzIHRoZSBzYW1lIE1TSUQgaWRl bnRpZmllciBmaXJzdCBoYWxmLCBidXQgYSBkaWZmZXJlbnQgc2Vjb25kIGhhbGYuIEhUQTogVGhh dCdzIGNvcnJlY3QuDQpGbGVtaW5nOiBUaGUgY2hhaXJzIGFyZSB1bmRlciB0aGUgaW1wcmVzc2lv biB0aGF0IHRoZXkgYXJlIHdhaXRpbmcgZm9yIHRoZSBhdXRob3IsIG5vdCB0aGUgb3RoZXIgd2F5 IGFyb3VuZC4gSFRBOiBJJ20gd2FpdGluZyBmb3IgdGhlIGNoYXJ0ZXIgdG8gYmUgYW1lbmRlZC4N CkFDVElPTiBJVEVNOiBDaGFpcnMgdG8gYW1lbmQgY2hhcnRlciB0byBpbmNsdWRlIGEgbWlsZXN0 b25lIGZvciB0aGlzIHdvcmsuDQooSW50ZXJjaGFuZ2UgYmV0d2VlbiBNYXJ0aW4gYW5kIEhUQSBy ZWdhcmRpbmcgdGhlIGlkZW50aWZpY2F0aW9uIG9mIHNpbXVsY2FzdCBzdHJlYW1zLCBpbmRpY2F0 aW5nIHRoYXQgdGhleSdyZSB0cmVhdGVkIGFzIGRpZmZlcmVudCB0cmFja3MpDQpQYXVsIEs6IFRo ZSBvdGhlciBkYXksIHdlIGhhZCBhIGRpc2N1c3Npb24gb2YgYWxsIHRoZSBtZWFuaW5ncyBvZiAi U3RyZWFtIiAoZS5nLiBvbmUgU1NSQywgb25lICJmbG93IiwgZXRjKS4gVGhpcyBqdXN0IG1hcHMg dG8gdGhlIFNTUkMgZGVmaW5pdGlvbi4gSXMgdGhlcmUgYW55IHdheSB0byBnZXQgYXQgdGhlIG90 aGVyIG5vdGlvbiB3aXRoIHRoaXMgbWVjaGFuaXNtLg0KSFRBOiBXaGljaCBvdGhlciBub3Rpb24/ DQpQYXVsIEs6IFRoZSBvbmUgd2hlcmUgd2UgaGF2ZSBzZXZlcmFsIFNTUkNzLCBidXQgb25seSBv bmUgYXQgYSB0aW1lLCBhbmQgdGhvc2UgU1NSQ3MgYXJlIHN0aXRjaGVkIHRvZ2V0aGVyIHRvIG1h a2UgYSBzaW5nbGUgbG9naWNhbCBjb25zdHJ1Y3QuDQpKb25hdGhhbiBMOiBUaGVyZSBpcyBhbiBh c3N1bXB0b2luIGluIGN1cnJlbnQgU0lQIGVuZHBvaW50cyB0aGF0IHRoZSBkZXZpY2Ugc2hvdWxk IG9ubHkgbmVlZCB0byBkZWNvZGUgb25lIHRoaW5nIGF0IGEgdGltZS4gVGhhdCBkb2Vzbid0IG5l Y2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGV5J3JlIHNlbWFudGljYWxseSB0aGUgc2FtZSB0aGluZy4g Rm9yIGV4YW1wbGUsIHlvdSBjYW4gZ2V0IHJpbmdiYWNrIGZvbGxvd2VkIGJ5IGFuIGFubm91bmNt ZW50IHRoYXQgeW91ciBjYWxsIGlzIGJlaW5nIGZvcndhcmRlZCwgdGhlbiB0aGUgcGVyc29uIHlv dSdyZSBjYWxsaW5nLiBUaG9zZSBwcm9iYWJseSBhcmVuJ3QgdGhlIHNhbWUgdGhpbmcsIGZyb20g YW4gTVNJRCBwZXJzcGVjdGl2ZS4NCkhUQTogQWxsIHdlIHNheSBpcyB0aGF0IHRoaXMgbWVkaWEg c3RyZWFtIGJlbG9uZ3MgdG8gdGhpcyBNU0lELiBJdCdzIGEgVzNDIGlzc3VlIHRvIGRlZmluZSB3 aGF0ICJiZWxvbmcgdG8iIG1lYW5zLiBJZiB5b3UgaGF2ZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu ICJwbGF5IHRoZXNlIGFsbCBhdCB0aGUgc2FtZSB0aW1lIiBvciAicGxheSBvbmx5IG9uZSwiIHRo YXQncyBjb21tdW5pY2F0ZWQgdXNpbmcgYSBkaWZmZXJlbnQgbWVjaGFuaXNtLg0KSm9uYXRoYW4g TDogSWYgd2Ugd2FudCB0byB1c2UgdGhpcyBhcyBvcHBvc2VkIHRvIGE9Z3JvdXAgZm9yIHRoaW5n cyBsaWtlIHNpbXVsY2FzdCBncm91cHMsIHdlIG5lZWQgdG8gYmUgdmVyeSBjbGVhciBhYm91dCB3 aGljaCBvbmUgYXBwbGllcy4NCkhUQTogRG8gd2Ugd2FudCB0byBleHByZXNzIHRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiBTU1JDcyBpbiB0aGUgc2FtZSBSVFAgc2Vzc2lvbiwgb3IgZGlmZmVyZW50 IFJUUCBzZXNzaW9ucz8NCkpvbmF0aGFuOiBSVFAgc2Vzc2lvbnMgb3IgbSBsaW5lcz8NCkhUQTog SSB0aGluayB3ZSB3YW50IHRvIHNheSBtIGxpbmVzLiBJJ2xsIGNoZWNrIHRoZSBkb2N1bWVudCBh bmQgbWFrZSBzdXJlIHRoaXMgbWFrZXMgc2Vuc2UuDQpQYXVsOiBJcyBpdCB2YWxpZCB0byBtYXAg bW9yZSB0aGFuIG9uZSBtLWxpbmUgdG8gdGhlIHNhbWUgbXNpZD8NCkhUQTogWWVzDQpQYXVsOiBX aHk/DQpIVEE6IExheWVycyBpbiBhIGxheWVyZWQgY29kZWMsIGZvciBleGFtcGxlLiBDaGFubmVs cyBpbiBhIHNpbXVsY2FzdCwgZm9yIGFub3RoZXIuIERpZmZlcmVudCB0eXBlcyBvZiBzZXF1ZW50 aWFsIG1lZGlhLCBhcyBhIHRoaXJkLg0KTWFydGluOiBUaGVyZSdzIGEgZm91cnRoIG9uZSBhbHNv DQpIVEE6IE9oLCB0aGVyZSdzIG1hbnkgbW9yZS4NCkhUQTogUmVxdWVzdCB0byBtYWtlIHN1cmUg d2UgdXNlIHRoZSBzYW1lIHRlcm1zIGFzIG90aGVyIGRvY3VtZW50cy4NCl9fX19fX19fX19fX19f X18NCg0KDQpNZWRpYSBTb3VyY2UgSUQ6IFNvbWV0aGluZyB3ZSBuZWVkPw0KU3RlZmFuIEjDpWth bnNvbg0KKFNlZSBzbGlkZXMgZm9yIGRpYWdyYW0gb2YgbW90aXZhdGluZyB1c2UgY2FzZSBzY2Vu YXJpb3MpDQpFS1IgKFJlZ2FyZGluZyAidG8gYSBwZWVyIiB1c2UgY2FzZSk6IFRoZSBhbHRlcm5h dGUgYXBwcm9hY2ggaXMgdG8gaGF2ZSBhIHNpbmdsZSBzdHJlYW0gd2l0aCBhbGwgdGhyZWUgdHJh Y2tzIGluIGl0LCBhbmQgaGF2ZSB0aGUgZmFyIGVuZCBzd2l0Y2hpbmcgdGhlIHZpZGVvIGJ1dCBu b3QgdGhlIGF1ZGlvLiBJJ20gc2Vuc2l0aXZlIHRvIG1ha2luZyB0aGlzIG1vcmUgY29tcGxpY2F0 ZWQgdGhhbiBuZWNlc3NhcnkuDQpDaHJpc3RlcjogV2UnbGwgYmUgc2VuZGluZyB0aGUgYXVkaW8g aW4gdHdvIGRpZmZlcmVudCB0cmFja3MsIHJpZ2h0PyBJc24ndCB0aGF0IGEgd2FzdGUgb2YgYml0 cz8NClN0ZWZhbjogRm9yIHRoZXNlIHRyYWNrcywgeW91IGNhbiBpbmRpdmlkdWFsbHkgcGF1c2Uv cmVzdW1lIHRvIHByZXZlbnQgdGhhdCBwcm9ibGVtLg0KRG9taW5pcXVlOiBJZiB0aGUgb25seSBw cm9ibGVtIGhlcmUgaXMgdGVsbGluZyBqYXZhc2NyaXB0IGRldmVsb3BlcnMgImRvbid0IGRvIHRo YXQgdGhlbiwiIEkgdGhpbmsgd2UganVzdCBuZWVkIHRvIGRvY3VtZW50IHRoaXMgc29tZXdoZXJl LiBUaGUgY29tcGxpY2F0aW9uIG9mIGFkZGl0aW9uYWwgc3luYyBpc24ndCB3b3J0aCBpdC4NCkVL UjogTGV0J3Mgc2F5IEkgY3JlYXRlIHR3byBQQ3MgYW5kIGF0dGFjaCB0aGVtIHRvIHRoZSBkaWZm ZXJlbnQgYXVkaW8gc3RyZWFtcy4gU2hvdWxkIHRoZXkgYmUgc3luY2hlZD8NClN0ZWZhbjogWWVz Lg0KRUtSOiBJJ20gbm90IHN1cmUgSSBhZ3JlZS4NCkN1bGxlbjogQXMgZmFyIGFzIEkgY2FuIHRl bGwsIG1lZGlhIHN0cmVhbSBpcyBvbmx5IGEgc3luY2hyb25pemF0aW9uIGNvbnN0cnVjdC4NClN0 ZWZhbjogSSB0aGluayB3ZSB3YW50IHRvIHN5bmMgYmV0d2VlbiBtZWRpYSBzdHJlYW1zLg0KQ3Vs bGVuOiBPa2F5LCBzbyBob3cgZG8geW91IHNpZ25hbCBzdHJlYW1zIHRoYXQgZG9uJ3QgbmVlZCB0 byBiZSBzeW5jaGVkPw0KU3RlZmFuOiBXaGF0J3MgdGhlIHVzZSBjYXNlPw0KQ3VsbGVuOiBXaGl0 ZWJvYXJkcywgZm9yIGV4YW1wbGUuDQpBZGFtOiBPbmUgc2NlbmFyaW8gaGVyZSBpcyB1c2luZyBt dWx0aXBsZSBQQ3MgdG8gZG8gc2ltdWxjYXN0Lg0KU3RlZmFuOiBJIGNvdmVyIHRoYXQgb24gdGhl IG5leHQgc2xpZGUuDQpKdXN0aW46IFdoeSBhcmUgd2Ugc2VuZGluZyBib3RoIHN0cmVhbXMgQSBh bmQgQyAoYXVkaW8gc3RyZWFtcyk/DQpTdGVmYW46IFdlIGRvbid0IGhhdmUgYW55IHRvb2xzIHRv IHRlbGwgZGV2ZWxvcGVycyBub3QgdG8gZG8gdGhpcy4NCkp1c3RpbjogV2UgY2FuJ3Qgc3RvcCBw ZW9wbGUgZnJvbSB3cml0aW5nIGJhZCBwcm9ncmFtcy4gV2UgbWlnaHQgbmVlZCB0byBkbyBtb3Jl IGV4YW1wbGVzLCBidXQgZXhwZWN0aW5nIHRoYXQgd2UnbGwgZ2V0IHBlcmZlY3QgYmVoYXZpb3Ig Zm9yIGltcGVyZmVjdCBzY3JpcHRzLi4uIHdlJ3JlIGdvaW5nIHRvIGhhdmUgdG8gZG8gYSBsb3Qg b2Ygd29yay4NCkhUQTogV2UgaGF2ZSB0aGUgdG9vbCBmb3IgdGhpcy4gSXQncyBjYWxsZWQgIkVu Z2xpc2gsIiBhbmQgd2UgcHV0IGl0IGluIHRoZSBzcGVjLiBSaWdodCBub3csIHdlIHNheSBzdHJl YW1zIGFyZSBzeW5jaGVkIGluIGEgc3RyZWFtLCBhbmQgdGhhdCB0aGV5J3JlIG5vdCBzeW5jaGVk IGJldHdlZW4gc3RyZWFtcy4gSWYgd2UgZG9jdW1lbnQgdGhpcyBwcm9wZXJ0eSBhbmQgZGV2ZWxv cGVycyBtZXNzIGl0IHVwLCBpdCdzIHRoZWlyIGZhdWx0Lg0KVGVkOiBJcyB0aGVyZSBhIGRyaXZp bmcgdXNlIGNhc2Ugb3RoZXIgdGhhbiAic29tZW9uZSBkaWRuJ3QgcmVhZCB0aGUgc3BlYyI/IElm IHlvdSBoYWQgc3VjaCBhIHVzZSBjYXNlLCBJIGNvdWxkIHVuZGVyc3RhbmQgdGhpcyBiZXR0ZXIu DQpTdGVmYW46IFNpbXVsY2FzdCB3aXRoIHR3byBQQ3MsIGZvciBleGFtcGxlLg0KRG9taW5pcXVl OiBUaGVyZSB3aWxsIGJlIGJhZCBwcm9ncmFtbWVycy4gVGhlaXIgcHJvZ3JhbXMgd2lsbCBmYWls LiBXZSBkb24ndCBuZWVkIHRvIHByb3RlY3QgYWdhaW5zdCBhbGwgYmFkIHByb2dyYW1taW5nLiBB cyBsb25nIGFzIHdlIGhhdmUgdGhlIHRvb2xzIHRvIGRvIHRoaW5ncyByaWdodCwgYW5kIGhhdmUg ZG9jdW1lbnRlZCB0aGVtLCB0aGVuIG91ciBqb2IgaXMgZG9uZS4NCkpvbmF0aGFuOiBJIHVuZGVy c3RhbmQgdGhhdCBBVlRDT1JFIGlzbid0IGhlcmUsIGJ1dCBJJ20gd29ycmllZCB0aGF0IFJUUCBk ZWZpbmVzIHN5bmMgYnkgQ05BTS4gSG93IGRvIGJyb3dzZXJzIGtub3cgdG8gdXNlIHN5bmNocm9u aXphdGlvbiB2aWEgc29tZXRoaW5nIG90aGVyIHRoYW4gQ05BTT8NCkN1bGxlbjogTXkgdW5kZXJz dGFuZGlnIChhcyBSVENXRUIgY2hhaXIpIHdhcyB0aGF0IGJyb3dzZXJzIGZ1bGx5IGludGVuZCB0 byBzZW5kIENOQU1zIGFjY29yZGluZyB0byB0aGlzIHNjaGVtZS4NCkpvbmF0aGFuOiBIb3cgYWJv dXQgcmVjZWlwdD8NCkN1bGxlbjogVEhleSBzaG91bGQgbWF0Y2ggdXAuDQpFS1I6IFRoYXQncyBu b3QgZ29pbmcgdG8gd29yay4gTWVkaWEgc3RyZWFtcyBhcmUgZ2VuZXJhdGVkIHByaW9yIHRvIHJl Y2VpdmluZyBhbnkgUlRQLiBHaXZlbiB0aGF0LCB3ZSBtdXN0IGJlIGFibGUgdG8gZGVyaXZlIHRo YXQgdHdvIHRoaW5ncyBhcmUgc3luY2hlZCB2aWEgU0RQIGFic2VudCBhbnkgUlRQIG1lY2hhbmlz bS4gSWYgdGhlcmUncyBhIGNvbmZsaWN0IGJldHdlZW4gU0RQIGFuZCBSVFAsIHdlIG5lZWQgdG8g aGFybW9uaXplIHRoZW0uDQpKb25hdGhhbjogKG1pc3NlZCB0aGlzIHN0YXRlbWVudCkNCkVLUjog TXkgYXNzdW1wdGlvbiBpcyB0aGF0IGJyb3dzZXJzIHdpbGwgdHJlYXQgdGhpbmdzIGluIHNlcGFy YXRlIE1TSURzIChvciB3aXRoIG5vIE1TSURzKSBhcyBpZiB0aGV5IGFyZSBzZXBlYXJ0ZSBzdHJl YW1zIChvciBtZXJnZSB0aGVtIGludG8gdGhlIHNhbWUgc3RyZWFtKS4NCkpvbmF0aGFuOiBJZiB5 b3UgaGF2ZSBvbmUgYXVkaW8gYW5kIG9uZSB2aWRlbywgdGhleSdyZSBwcm9iYWJseSBzdXBwb3Nl ZCB0byBiZSBzeW5jaHJvbml6ZWQuDQpFS1I6IChtaXNzZWQgdGhpcyBzdGF0ZW1lbnQpDQpDdWxs ZW46IElzIHRoZXJlIGEgZHJhZnQgZm9yIHB1dHRpbmcgQ05BTXMgaW4gU0RQPw0KSm9uYXRoYW46 IChSRkMgNTU3NiksIGJ1dCBubyBvbmUgaXMgZ29pbmcgdG8gd2FudCB0byB1c2UgaXQuDQoNCg0K SmVzdXA6IEkgdGhpbmsgd2hlbiB5b3UgaGF2ZSBsZWdhY3kgaW5jb21pbmcgU0RQLCB0aGUgYnJv d3NlciBpcyBnb2luZyB0byBuZWVkIHRvIHN0dWZmIHRoZW0gYWxsIGluIHRoZSBzYW1lIG1lZGlh IHN0cmVhbSBhbmQgc3luYyB0aGVtLiBZb3UgY2FuIHdhaXQgZm9yIHRoZSBDTkFNcyBpZiB5b3Ug d2FudCB0bywgYnV0IHJlYWxpc3RpY2FsbHkgeW91J2xsIGJlIGNvdmVyZWQganVzdCBmaW5lIGlm IHlvdSBkb24ndC4NCkpvbmF0aGFuOiBJJ20gbm90IHN1cmUgdGhlcmUncyBhbnkgZ3VhcmFudGVl IHRoYXQgc3luY2hyb25pemluZyBpbmZvcm1hdGlvbiBoYXMgYW55IHJlbGF0aW9uc2hpcCB0byBl YWNoIG90aGVyIGlmIHRoZSBzdHJlYW1zIGhhdmUgZGlmZmVyZW50IENOQU1zLiBDb25zaWRlciBk ZWNvbXBvc2VkIHNvdXJjZXMgd2l0aCBjbG9jayBza2V3Lg0KTWFydGluIFRob21wc29uOiBDb25z aWRlciB0aGF0IHN5bmMgaXMgZ29pbmcgdG8gYWN0IHRyYW5zaXRpdmUuIElmIHlvdSBzeW5jIEEg d2l0aCBCLCBhbmQgQyB3aXRoIEQsIHRoZW4gc3luY2hpbmcgQiB3aXRoIEQgd2lsbCBhdXRvbWF0 aWNhbGx5IHN5bmNoIEEgd2l0aCBCLiBBbHNvLCBJIHRoaW5rIGlmIHlvdSBzdGFydCB0byBzeW5j IHRoaW5ncyB0aGF0IHNob3VsZG4ndCBiZSBzeW5jaGVkLCB5b3UncmUgZ29pbmcgdG8gZW5kIHVw IHdpdGggc29tZSBzdXJwcmlzaW5nIGZhaWx1cmVzLg0KSGFkcmllbDogQXJlIHlvdSBzYXlpbmcg dGhlIG1lZGlhIHN0cmVhbSBjYW4gb3ZlcnJpZGUgdGhlIENOQU1zPw0KRmx1ZmZ5OiBJIGRvbid0 IHRoaW5rIHdlIGhhdmUgY29uc2Vuc3VzLiBJJ2QgY29uc2lkZXIgdGhhdCB1bnJlc29sdmVkLg0K SGFkcmllbDogV2hlbiB0aGVzZSBjb21lIGluIGZyb20gZ2F0ZXdheXMsIHRoZXkncmUgbm90IGdv aW5nIHRvIGJlIG9yZ2FuemllZCBieSBDTkFNcy4NCkFjdGlvbiBJdGVtIGZvciBjaGFpcnM6IERl dGVybWluZSBIb3cgd2UgaGFuZGxlIENOQU0sIE1lZGlhU3RyZWFtcywgTVNJRHMsIENOQU0gY2hh bmdlcywgY29uZmVyZW5jZSBtaXhpbmcgd2l0aCBubyBDU1JDcywgYW5kIHRoZSByZWxhdGVkIG1v cmFzcw0KU3RlZmFuOiBJIHRoaW5rIHdlJ2xsIGNhbGwgdGhhdCB0aGUgZW5kIG9mIHRoaXMgdGlt ZXNsb3QuDQpFS1I6IE1TSUQgaXMgdGhlIG9ubHkgdGhpbmcgd2UgY2FuIHVzZSB0byBhc3NlbWJs ZSBtZWRpYSBzdHJlYW1zLiBMYWNraW5nIHRoYXQsIHdlJ2xsIG5lZWQgdG8gdHJlYXQgdGhlbSBh cyBhbGwgc2VwYXJhdGUgb3IgYWxsIHRvZ2V0aGVyLg0KSGFkcmllbDogQ2FuIHdlIHBpY2sgb25l IGFuZCBzdGFuZGFyaXplIGl0Pw0KRUtSOiBTdXJlLg0KRUtSOiBXZSdsbCBoYXZlIHRvIGFzc3Vt ZSB0aGF0IGV2ZXJ5dGhpbmcgd2l0aCB0aGUgc2FtZSBNU0lEIGlzIGluIHRoZSBzYW1lIG1lZGlh IHN0cmVhbS4gKFNvbWUgcHJvcG9zYWwgYWJvdXQgaG93IHRvIGhhbmRsZSBDTkFNL01TSUQgbWlz bWF0Y2hlcywgYnV0IGl0IHdhcyB0b28gZmFzdCB0byBmb2xsb3cpLg0KSFRBOiAuLi4NCkhUQTog QW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHNob3VsZCBjb25kaXRpb24gdGhlc2Ugb24g Q05BTXMsIHdoZW4gd2UgY2FuIGdldCBSVFAgcGFja2V0cyB3aXRob3V0IENOQU1zIGFyZSBhbGwu DQpUZWQ6IFdlIG5lZWQgdG8gY29uc2lkZXIgd2hldGhlciB3ZSBuZWVkIHRvIHJlYWxseSBuYWls IGRvd24gYmVoYXZpb3IgZnJvbSB0aGUgY29ybmVyIGNhc2Ugd2hlcmUgYSBicm93c2VyIGdldHMg U0RQIGZyb20gYSBub24tYnJvd3NlciwgZ2l2ZW4gdGhhdCBpdCdzIHJlYWxseSBhIGNvcm5lciBj YXNlLiBJdCdzIGVhc2llciB0byBzYXkgImlmIHRoZXJlJ3Mgbm8gTVNJRCwgYXNzdW1lIHRoZXkn bGwgYmUgdHJlYXRlZCBzZXBhcmF0ZS4iDQpKb25hdGhhbjogVGhlIGFiaWxpdHkgdG8gc3luYyBk ZXBlbmRzIG9uIHJlY2VpcHQgb2YgYSBmaXJzdCBDTkFNIGFueXdheS4NCkhhZHJpZWwgKHJlc3Bv bmRpbmcgdG8gVGVkKTogV2FpdCwgd2hlbiB3ZSdyZSBnYXRld2F5aW5nLCB3ZSBkb24ndCBrbm93 IGhvdyB0byBwdXQgTVNJRHMgaW4uIFRoaXMgaXNuJ3QgZ29pbmcgdG8gYmUgYXMgbXVjaCBvZiBh IGNvcm5lciBjYXNlLg0KKGNvbnZlcnNhdGlvbiBlbnN1ZXMgYWJvdXQgbm9uLXN5bmMgYmVoYXZp b3IgYmVpbmcgImNsb3NlIGVub3VnaCwiIHdoZXRoZXIgTVNJRHMgbmVlZCB0byBiZSBtYW5kYXRv cnksIHNvbWUgY29uc2lzdGVuY3kgYWJvdXQgd2hhdCBoYXBwZW5zIGlmIHRoZXkncmUgbWlzc2lu ZywgZXRjKS4NCk1hcnRpbjogSSB0aGluayB3ZSBjYW4gaGFuZGxlIHRoZW0gYmVpbmcgc2VwYXJh dGUgaW4gdGhlIGFic2VuY2Ugb2YgTVNJRC4NCkhhZHJpZWw6IFNvIHlvdSdyZSBzYXlpbmcgdGhh dCB5b3UncmUgb2theSBpZiB0aGV5J3JlIHNlcGFyYXRlPw0KTWFydGluOiBZZXMuDQpIYWRyaWVs OiBNZSB0b28uIEkgZG9uJ3QgYWN0dWFsbHkgY2FyZSwgSSBqdXN0IHdhbnQgb25lIG9yIHRoZSBv dGhlciB0byBiZSBzcGVjaWZpZWQuDQpCZXJuYXJkOiBJIGFyZ3VlIHRoYXQgUlRQIHN0cmVhbXMg d2l0aCB0aGUgc2FtZSBDTkFNIHNob3VsZCBzeW5jIGV2ZW4gaWYgd2Ugc3BlY2lmeSB0aGVtIGFz IGRpZmZlcmVudCBzdHJlYW1zLg0KVGltOiBZb3UgY2FuJ3QgYXNzdW1lIHRoYXQgdGhpbmdzIHRo YXQgYXJlIG5vdCBpbiB0aGUgc2FtZSBtZWRpYSBzdHJlYW0gYXJlIG5vdCBzeW5jaGVkLg0KQ3Vs bGVuOiBJbiB0aGUgY2FzZSBvZiBhIHNpbmdsZS1zdHJlYW0gdm9pY2UvdmlkZW8gcGhvbmUgdXNp bmcgU0lQLCBkbyB3ZSB0aGluayB0aGUgYnJvd3NlciBwbGF5b3V0IHNob3VsZCBiZSBzeW5jaHJv bml6ZWQ/DQpNYXJ0aW46IFdoYXQgVGVkIHNhaWQgaXMgdGhhdCB3ZSBuZWVkIHRvIE1lZGlhU3Ry ZWFtcywgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgc3luY2hlZC4gSWYgdGhleSB0dXJuIG91dCB0 byBiZSBzeW5jaGVkIChmb3Igd2hhdGV2ZXIgcmVhc29uKSwgY29vbC4gQnV0IHdlIGRvbid0IG1h a2UgYW55IHByb21pc2VzLg0KQ3VsbGVuOiBCdXQgaXMgdGhlcmUgYSByZXF1aXJlbWVudCBmb3Ig dGhlIGJyb3dzZXIgdG8gdGVsbCB0aGUgYXBwIHRoYXQgdGhlc2UgdGhpbmdzIGFyZSBpbiBzeW5j Pw0KTWFydGluOiBObywgSSB0aGluayB0aGUgYnJvd3NlciBjYW4ganVzdCBkbyB0aGF0DQpIYWRy aWVsOiBCdXQgYXJlIHdlIGdvaW5nIHRvIHJlcXVpcmUgdGhhdCB0aGV5IGFyZSBzeW5jaGVkIGlm IHRoZXkgaGF2ZSB0aGUgc2FtZSBDTkFNPw0KTWFydGluL1RlZDogTm8uDQpUZWQ6IFRoZXkgbWln aHQgYmUgc3luY2hlZCwgYnV0IHRoZXkgYXJlIG5vdCBndWFyYW50ZWVkIHRvIGJlLiBJdCdzIGFu ICJ1bmRlcnByb21pc2UgYW5kIChwb3RlbnRpYWxseSkgb3ZlcmRlbGl2ZXIiIHNpdHVhdGlvbi4N CkN1bGxlbjogVGhhdCdzIG5vdCB3aGF0IEhhZHJpZWwgc2FpZC4NCkpvbmF0aGFuOiBJIHRoaW5r IHdlJ3JlIG92ZXJwcm9taXNpbmcgYW5kIHVuZGVyZGVsaXZlcmluZyBpZiB3ZSBoYXZlIHR3byBz dHJlYW1zIGluIHRoZSBzYW1lIHN0cmVhbSBidXQgZGlmZmVyZW50IENOQU1zLiBJZiB0aGV5J3Jl IG5vdCB0aGUgc2FtZSBDTkFNLCB5b3UgY2FuIGVuZCB1cCB3aXRoICJ0aGVzZSBzdHJlYW1zIGFy ZSA0MCB5ZWFycyBvdXQgb2Ygc3luYywiIHNpbmNlIHRoZXkgY2FuIGJlIHVzaW5nIGRpZmZlcmVu dCBjbG9ja3MuIFRoYXQncyBwcm9iYWJseSBiYWQuDQpFS1I6IEkgd291bGQgYXNzdW1lIHRoYXQg eW91IHN0b3AgdHJ5aW5nIHRvIHN5bmMgdGhlbS4gVGhlcmUncyBubyBvdGhlciB3YXkgdG8gaW1h Z2luZSBob3cgeW91IGRvIHRoYXQuDQpKb25hdGhhbjogV2hhdCdzIHRoZSB0aHJlc2hvbGQgZm9y IHRoYXQ/DQpNYXJ0aW46IGltcGxlbWVudGFpb24gZGVjaXNpb24uDQpEYW46IFdoYXQgZG8geW91 IGV4cGVjdCB0byBoYXBwZW4gaWYgeW91IGhhdmUgdHdvIG1lZGlhIGZsb3dzIGZyb20gd2hlcmV2 ZXIgLS0gZGlmZmVyZW50IGRldmljZXMsIGRpZmZlcmVudCBQQ3MgLS0gYW5kIHRoZW4geW91IHNh eSAic3luY2ggdGhlc2UuIiBXaGF0IGRvIHlvdSBleHBlY3QgdG8gaGFwcGVuPyBTdGFydGluZyBm cm9tIHRoZSBwb2ludCBhdCB3aGljaCBJIHB1dCB0aGVtIHRvZ2V0aGVyLCBJIHdvdWxkIGV4cGVj dCB0aGVtIHRvIGFkdmFuY2UgYXQgdGhlIHNhbWUgcmF0ZS4NCkpvbmF0aGFuOiBZZXMsIHRoYXQn cyB3aGF0IGhhcHBlbnMuIFRoZSBvbmx5IHRpbWUgdGhhdCB3b24ndCBoYXBwZW4gaXMgaWYgeW91 J3JlIHRyeWluZyB0byBkZWFsIHdpdGggc3luYyBza2V3Lg0KKE1pc3NlZCBzb21lIG9mIHRoZSBk aXNjdXNzaW9uIGhlcmUpDQpIYWRyaWVsOiBJIGNvdWxkIGJlIHZlcnkgd3JvbmcsIGJ1dCBpdCBz ZWVtcyB0aGF0IHRoZSBicm93c2VyIGd1eXMgc2hvdWxkbid0IHdhbnQgdG8gbGVhdmUgdGhpcyB1 cCB0byBpbXBsZW1lbnRhdGlvbi4gVGhpcyB3b3VsZCBsZWFkIHRvIGludGVyb3AgZmFpbHVyZXMs IHJpZ2h0PyBZb3UnZCBoYXZlIHNjcmlwdHMgdGhhdCBkbyBkaWZmZXJlbnQgdGhpbmdzLCByaWdo dD8gSSB0aGluayBpZiB3ZSBoYXZlIHR3byB0cmFja3Mgd2l0aCB0aGUgc2FtZSBDTkFNLCB3ZSBz aG91bGQgZ3VhcmFudGVlIHRoYXQgdGhleSdsbCBiZSBzeW5jaGVkLg0KQmVybmFyZDogSSB0aGlu ayB0aGUgUlRQIHVzYWdlIGRvY3VtZW50IGFscmVhZHkgc2F5cyB0aGF0LCByaWdodD8NClRpbTog VGFsa2luZyBhYm91dCBhZHZhbmNpbmcgY2xvY2tzIGF0IHRoZSBzYW1lIHJhdGUsIHRoYXQgd2Fz IHdoYXQgd2UgZmlyc3Qgc2FpZCBhYm91dCBwdXR0aW5nIHR3byB0aGluZ3MgaW4gdGhlIHNhbWUg bWVkaWEgc3RyZWFtLCByaWdodD8NCkRhbjogUmlnaHQsIHdoYXQgSSBzYWlkIHdhcyB0aGF0IGEg bmHDr3ZlIGNvZGVyIHdvdWxkIGV4cGVjdCB0aGF0IHB1dHRpbmcgdHdvIHRoaW5ncyB0b2dldGhl ciBpbiB0aGUgc2FtZSBtZWRpYSBzdHJlYW0gc2hvdWxkIGJlIGd1YXJhbnRlZWQgdG8gcHJvY2Vl ZCBhdCB0aGUgc2FtZSByYXRlIGFzIGVhY2ggb3RoZXIuDQpIVEE6IFdoZW4gSSBzZXR1cCBhIHN0 cmVhbSwgSSBoYXZlIGEgaml0dGVyIGJ1ZmZlciBhbmQgYSBwbGF5b3V0IGNsb2NrLiBJZiB3ZSBj b21iaW5lIHRyYWNrcyBmcm9tIGRpZmZlcmVudCByZW1vdGUgc291cmNlcyAoYW5kIGl0J3MgbmF0 dXJhbCB0byB0aGluayB3ZSBzaG91bGQgYmUgYWJsZSB0byksIHNvbWUgb2YgdGhlc2UgY2xvY2tz IHdvbid0IHJ1biBhdCB0aGUgc2FtZSByYXRlLCB3aGljaCBtZWFucyBzb21lb25lIHNvbWV3aGVy ZSBuZWVkIHRvIGhhcm1vbml6ZSB0aGVtICh3aGljaCBpbnRyb2R1Y2VzIGFydGlmYWN0cykuIFlv dSBoYXZlIHRvIGRlY2lkZSB3aGVyZSB0aGUgaml0dGVyIGJ1ZmZlciBsaXZlcywgeW91IGhhdmUg dG8gZGV0ZXJtaW5lIGhvdyB5b3UgaGFuZGxlIHNrZXcuDQpLZWl0aDogTW9zdCBvZiB0aGlzIGNv bnZlcnNhdGlvbiBpcyBpbiB0aGUgcGVydmlldyBvZiBBVlRDT1JFLCBub3QgdGhpcyBjb252ZXJz YXRpb24gYW5kIG5vdCB0aGVzZSB3b3JraW5nIGdyb3Vwcy4gV2UgbmVlZCB0byBjb21tdW5pY2F0 ZSBhbnkgbmV3IHJlcXVpcmVtZW50cyB0byBBVlRDT1JFLg0KQ3VsbGVuOiBJIGRvbid0IHRoaW5r IHdlIGhhdmUgYW55IGNvbmNsdXNpb25zIGluIG5lZWQgb2YgYmVpbmcgY29tbXVuaWNhdGVkLg0K X19fX19fX19fX19fX19fXw0KDQoNClRyaWNrbGUgSUNFDQoxLiBUaGUgcG9pbnQgb2YgdHJpY2ts ZSBJQ0UgaXMgdG8gb3B0aW1pemUgYSBjaGFyYWN0ZXJpc2l0aWMgb2YgSUNFOyByaWdodCBub3cs IGRpc2NvdmVyeSBpcyBoYW5kbGVkIHNlcmlhbGx5LiBUaGUgaWRlYSBpcyB0aGF0IHdlIGNhbiBo YW5kbGUgdGhlc2Ugc3RlcHMgaW4gcGFyYWxsZWwuDQoyLiBGaXJzdCB0aW1lIGFyb3VuZCwgd2Ug dHJpZWQgZG9pbmcgaXQgaW4gYSB2ZXJ5IGdlbmVyaWMgZmFzaGlvbiwgaW4gcGFyaXRjdWxhciBh Z25vc3RpYyB0byBvZmZlcnMgYW5kIGFuc3dlcnMuDQozLiBXZSB3ZXJlIHRvbGQgdGhhdCB3ZSBh bHNvIG5lZWQgdG8gc3BlY2lmeSBob3cgdG8gZG8gdGhpcyBpbiBTSVAuDQo0LiBXZSB3ZXJlIHRv bGQgdG8gZXhwYW5kIG9uIGhhbGYtdHJpY2tsZQ0KNS4gV2Ugd2VyZSB0b2xkIHRvIGV4cGxhaW4g aW50ZXJvcCB3aXRoIElDRSBMaXRlIGltcGxlbWVudGF0aW9uczAuDQpDaGFuZ2VzDQoxLiBOb3cg YWR2ZXJ0aXNlIHN1cHBvcnQgaW4gYSBuZXcgYXR0cmlidXRlDQoyLiBOZXcgc3ludGF4IGZvciBv ZmZlci9hbnN3ZXIgd2l0aCBubyBhZGRyZXNzZXMgKDAuMC4wLjAsIHBvcnQgPSAxKQ0KMy4gU3lu dGF4IGZvciBhbm5vdW5jaW5nIGVuZCBvZiBjYW5kaWRhdGVzIChhPWVuZC1vZi1jYW5kaWRhdGVz KQ0KRUtSOiBBUEkgaXMgYWxyZWFkeSBkZWZpbmVkIHNvIHdlJ3JlIGp1c3QgZGlzY3Vzc2luZyB3 aXJlIHN5bnRheA0KQWRhbTogTWFrZSBzdXJlIHlvdXIgc3ludGF4IHRhbGtzIGFib3V0IElQdjYN CkVtaWw6IFlvdSdsbCBzdGlsbCBwdXQgSVB2NCwgYW5kIHRoZW4gaW5jbHVkZSB2NiBjYW5kaWF0 ZXMuDQpGbGVtaW5nOiAoc29tZXRoaW5nIGFib3V0IFNEUCBzeW50YXgpLg0KSGFkcmllbDogRW5k IG9mIGNhbmRpZGF0ZXMgcmVhbGx5IG1lYW5zICJ0aGlzIGlzIG15IGZpbmFsIFNEUCBjaGFuZ2Uu Ig0KRW1pbDogSXQgcmVhbGx5IG1lYW5zIHRoYXQgd2UncmUgZG9uZSBzZW5kaW5nIGNhbmRpZGF0 ZXMuDQpIYWRyaWVsOiBJdCdzIHJlYWxseSBzYXlpbmcgd2UncmUgZ29pbmcgdG8gc3RvcCBjaGFu Z2luZyBTRFAuDQpFbWlsOiBJdCBjb3VsZCBiZSBqdXN0IGEgZGlmZmVyZW50IG1lc3NhZ2UgdG8g dGhlIG90aGVyIFVBLg0KSm9uYXRoYW46IEkgdGhpbmsgdGhlIGFkdmFudGFnZSB0byAiYT1lbmQt b2YtY2FuZGlkYXRlcyIsIGlzIHRoYXQgeW91IGNhbiBzdGFydCBkb2luZyB0aGUgSUNFIGNvbmNs dXNpb24gYW5kL29yIGRlY2xhcmUgZmFpbHVyZSAob3Igc3VjY2VzcyBvbiBhIG5vbi1wcmVmZXJy ZWQgdHJhbnNwb3J0LCBsaWtlIFRVUk4pLg0KSm9uYXRoYW46IFVzZSBwb3J0IDkgcmF0aGVyIHRo YW4gMS4NCihEaXNjdXNzaW9uIGFib3V0IHRoZSB1c2Ugb2YgMC4wLjAuMCB3aGljaCB1c2VkIHRv IGhhdmUgZGlmZmVyZW50IHNlbWFudGljcykNCkFkYW06IEl0IHdvdWxkIGJlIG5pY2UgaWYgd2Ug dXNlIHNvbWV0aGluZyBkaWZmZXJlbnQsIGxpa2UgIklQNiA6OiIgcmF0aGVyIHRoYW4gIklQNCAw LjAuMC4wIiAtLSBvdGhlcndpc2UsIHlvdSBoYXZlIHRvIGFkZCBzcGVjaWFsIHB1cnBvc2UgY29k ZSB0byBleGlzdGluZyBTRFAgbGlicmFyaWVzLg0KKFNvbWUgZGlzY3Vzc2lvbiBhYm91dCBob3cg dG8gaGFuZGxlIHdpdGggU0lQLCBhbmQgdGhhdCB3ZSBuZWVkIHRvIGluY2x1ZGUgYSByZWZlcmVu Y2UgdG8gdGhlIFNJUCBkb2N1bWVudCkNCkpvbmF0aGFuOiBJdCdzIHBvc3NpYmxlIHRoYXQgeW91 IG1pZ2h0IG5lZWQgYSBuZXcgb2ZmZXIvYW5zd2VyIGJlZm9yZSB0cmlja2xlIGNvbmNsdWRlcy4g WW91J2xsIHdhbnQgdG8gaW5jbHVkZSB0aGUgcHJldmlvdXNseSBjb21tdW5pY2F0ZWQgY2FuZGlk YXRlcyBpbiB0aGUgbmV3IG1lc3NhZ2VzLCB3aGljaCB3b3VsZCBpbmNsdWRlIHRoZSAiYT1lbmQt b2YtY2FuZGlkYXRlcyIgaWYgbmVjZXNzYXJ5Lg0KKFNvbWUgZGlzdWNzc2lvbiBhcm91bmQgaG93 IGxvbmcgeW91IHJ1biB0cmlja2xlIHZlcnN1cyB3aGVuIHlvdSBkbyBJQ0UgcmVzdGFydHMpDQox LiBVc2VkIHRvIHNheSB0aGF0IHlvdSBvbmx5IGRvIHRyaWNrbGUgaWYgeW91IGtub3cgdGhlIHJl bW90ZSBwYXJ0eSBkb2VzIHRyaWNrbGUuIE5vdyBzYXkgdGhhdCB5b3UgY2FuIGRvIGhhbGYtdHJp Y2tsZSBpZiB5b3UgZG9uJ3Qga25vdyB0aGUgcmVtb3RlIGVuZCBzdXBwb3J0cyBpdC4NCihTb21l IHZlcnkgY29uZnVzaW5nIGRpc2N1c3Npb24gYWJvdXQgM1BDQykNCkRhbGU6IElmIHlvdSBzZW5k IGFuIG9mZmVyLCBhbmQgZ2V0IGFuIGFuc3dlciwgYW5kIHRoZW4gc2VuZCBhIHN1YnNlcXVlbnQg b2ZmZXIgaW4gdGhlIHNhbWUgZGlhbG9nLCB5b3UncmUgbm90IGd1YXJhbnRlZWQgdGhhdCB0aGUg c3Vic2VxdWVudCBvZmZlciBnb2VzIHRvIHRoZSBzYW1lIGltcGxlbWVudGF0aW9uLiBTbyB5b3Ug Y2FuJ3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgdGhp bmcgcmVjZWl2aW5nIHRoZSBuZXcgb2ZmZXIuDQpGbGVtaW5nOiBUaGF0IHNlZW1zIHRvIGJlIHZl cnkgcHJvYmxlbWF0aWMuDQpEYWxlOiBZZXMsIGJ1dCB0aGVyZSBhcmUgc29sdXRpb25zLCBhbmQg bXkgZHJhZnQgZGlzY3Vzc2VzIHRoZXNlLg0KKFNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYWJv dXQgdGhhdCBtZWNoYW5pc20pDQpGbGVtaW5nOiBOZWVkIGNsZWFuIHNlcGFyYXRpb24gZm9yIGlu ZGljYXRpb24gb2Ygc3VwcG9ydCBhbmQgaW5kaWNhdGlvbiBvZiAiSSdtIGdvaW5nIHRvIHVzZSB0 aGlzIHJpZ2h0IG5vdyIgKGUuZy4sICJhPXRyaWNrbGUtaWNlOm9uIikuDQpFbWlsOiBTbyB3aGF0 IGFyZSB0aGUgc2VtYW50aWNzIG9mIHNheWluZyAiSSBjYW4gZG8gdHJpY2tsZSwgYnV0IEknbSBu b3QgZG9pbmcgaXQgcmlnaHQgbm93PyINCkpvbmF0aGFuOiBJdCBsZXRzIHlvdSBpbmRpY2F0ZSB0 byB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgeW91IGNhbiByZWNlaXZlIHRyaWNrbGUuDQpFS1I6IFlv dSBjYW4gZGV0ZWN0IHdoZXRoZXIgaXQncyBiZWluZyB1c2VkIGJ5IHRoZSBwcmVzZW5jZSBvZiBj YW5kaWRhdGVzLg0KSm9uYXRoYW46IEkgdGhpbmsgd2hhdCBJIHdhcyBzYXlpbmcgYmVmb3JlIGFi b3V0IDNQQ0MgLS0gaWYgeW91J3JlIHVzaW5nIElDRSwgaXQgd29uJ3Qgd29yayBhbnl3YXkgd2l0 aG91dCBJQ0UgcmVzdGFydCAtLSBzbyBJIHRoaW5rIHlvdSdyZSBva2F5Lg0KMS4gSGFsZiBUcmlj a2xlDQpNb3N0bHkgbWVhbnQgZm9yIFNJUC4gSW52b2x2ZXMgb2ZmZXJlciBzZW5kaW5nIGFsbCBh dHRyaWJ1dGVzIGluIHRoZSBvZmZlciwgYnV0IGdldHRpbmcgY2FuZGlkYXRlcyB0cmlja2xlZCBi YWNrIGJ5IHRoZSBhbnN3ZXJlci4gKEZyb20gdGhhdCBwb2ludCwgd2UgY2FuIHVzZSBmdWxsIHRy aWNrbGUgaW4gYm90aCBkaXJlY3Rpb25zKS4NCk9QRU4gSVNTVUVTDQoxLiBEbyB3ZSByZWFsbHkg bmVlZCB0aGUgc3RyZWFtIGluZGV4Pw0KRUtSOiBBbGwgd2UgbmVlZCBpcyBzb21lIHdheSBpbiB0 aGUgQVBJIHRvIGluZGljYXRlIHdoZXJlIHRoZXkgZ28uDQpFbWlsOiBTbyB0aGlzIHNob3VsZCBi ZSB0YWtlbiBjYXJlIG9mIGJ5IHRoZSBwcm90b2NvbCB0aGF0IHVzZXMgVHJpY2tsZSBJQ0UuDQpF bWlsOiBDdXJyZW50bHksIHdlIHNheSB0byB1c2UgZWl0aGVyIGluZGV4IG9yIG1pZC4gV2hlbiB3 b3VsZCB3ZSBldmVyIHVzZSBqdXN0IGluZGV4Pw0KKEkgbXVzdCBoYXZlIG1pc3NlZCBzb21ldGhp bmcgYmVjYXVzZSB0aGlzIHNlZW1zIGNvbXBsZXRlbHkgbm9uLXNlcXVpdHVyKQ0KRmxlbWluZzog V2UgbmVlZCB0byBkZWZpbmUgYSB3YXkgdG8gdXNlIHRoaXMgaW4gb2ZmZXIvYW5zd2VyLg0KQ3Vs bGVuOiBEbyB3ZSBoYXZlIGEgd2F5IHRvIGhhbmRsZSB0aGlzIGlmIHRoZXJlIGFyZSBubyBtaWQn cyBhdCBhbGw/DQooTXVybXVycyBmcm9tIHRoZSByb29tIHNlZW0gdG8gdGhpbmsgc28pLg0KU29t ZSBkaXNjdXNzaW9uIGFib3V0IG9yZGVyaW5nIG9mIGF0dHJpYnV0ZXMsIGFuZCB3aGV0aGVyICJl bmQtb2YtY2FuZGlkYXRlcyIgbmVlZHMgYW4gZXhwbGljaXQgaW5kZXguDQpKdXN0aW46IFdlIGNv dWxkIHB1dCBib3RoIG1pZCBhbmQgbS1saW5lIGluZGV4LCBidXQgd2UncmUgcHJvcG9zaW5nIGp1 c3QgbWlkIGZvciBzaW1wbGljaXR5LiBEb2VzIHRoYXQgd29yaz8NCkVLUjogUmlnaHQgbm93LCBJ IHJlYWQgaXQgYXMgc2F5aW5nIHlvdSBNVVNUIGhhdmUgYW4gbS1saW5lIGluZGV4LCBhbmQgU0hP VUxEIGhhdmUgYSBNSUQuDQpKdXN0aW46IElzIHRoZXJlIGFueSByZWFzb24gdG8gZG8gdHJpY2ts ZSB3aXRoIHNvbWV0aGluZyB0aGF0IGRvZXNuJ3QgZG8gbWlkPw0KQ3VsbGVuOiBXZSBjYW4gbWFu ZGF0ZSB0aGF0IGFsbCB0cmlja2xlIHVzZXJzIGluY2x1ZGUgYSBtaWQuDQooUGVvcGxlIHNlZW1l ZCB0byBsaWtlIHRoaXMpDQpFbWlsOiBXZSBkZWZpbmUgdGhlc2UgYXMgbS1saW5lIGF0dHJpYnV0 ZXMuIFNob3VsZCB0aGV5IGFsc28gYmUgc2Vzc2lvbi1sZXZlbD8NCkhUQTogSXMgdGhlcmUgYSBy ZWFzb24gd2h5IHdlIGhhdmUgImVuZC1vZi1jYW5kaWRhdGVzIiByYXRoZXIgdGhhbiAibW9yZS1j YW5kaWRhdGVzLXBlbmRpbmciPyBJdCB3b3VsZCBzZWVtIHRvIGJlIGxlc3MgZGlzcnVwdGl2ZSBp ZiB0aGUgZmluYWwgU0RQIGxvb2tzICJub3JtYWwuIg0KSnVzdGluOiBXZSBtaWdodCBoYXZlIGEg ZmFpbHVyZSBjYXNlIHRoYXQgY2F1c2VzICJlbmQtb2YtY2FuZGlkYXRlcyIgdG8gYmUgc2VudCBi dXQgd2UgZGlkbid0IGtub3cgd2Ugd2VyZSBkb25lIHByaW9yIHRvIHRoZSBmYWlsdXJlLg0KRmxl bWluZzogSXMgdGhpcyBTRFAgb3Igbm90Pw0KRW1pbDogVGhpcyBpc24ndCBTRFAuIEl0J3Mgd2hh dCB3ZSBzZW5kLg0KRUtSOiBXaHkgaXNuJ3QgdGhpcyByZWFsIFNEUD8NCkVtaWw6IE9rYXksIHNv IHlvdSBjYW4gY29uc2lkZXIgdGhpcyBTRFAuIENhbmRpZGF0ZXMgY2FuIGdvIG91dC1vZi1iYW5k IGFsc28uDQpGbGVtaW5nOiBTbyB3ZSdyZSBkZWZpbmluZyAiZW5kLW9mLWNhbmRpYXRlcyIgaW4g U0RQPw0KRW1pbDogWWVzLg0KRmxlbWluZzogU2Vzc2lvbiBMZXZlbCBhdHRyaWJ1dGVzIGFyZSB0 aGUgc291cmNlIG9mIGFsbCBldmlsIGluIFNEUC4gRG9uJ3QgZG8gaXQuIEtlZXAgaXQgYSB0aGUg bWVkaWEgbGV2ZWwuDQpKb25hdGhhbjogVGhlIElDRSBhbGdvcml0aG1zIGRvIGhhdmUgY3Jvc3Mt bS1saW5lIGZ1bmN0aW9uYWxpdHkuIFdlIG1pZ2h0IG5vdCB3YW50IHRvIHRyZWF0IG0tbGluZXMg aW5kZXBlbmRlbnRseSwgc2luY2UgdGhlcmUgYXJlIHdob2xlLVNEUC1zZXNzaW9uIHNlbWFudGlj cyBhdCBwbGF5Lg0KKFNpZGV0cmFjayBhcmd1bWVudCBpbnZvbHZpbmcgZXh0cmVtZSBlc290ZXJp Y2EgcmVnYXJkaW5nIElDRSBwYWNpbmcgaGVyZSkuDQpKb25hdGhhbjogSSB2b3RlIGZvciBwdXR0 aW5nIG09ZW5kLW9mLWNhbmRpZGF0ZXMgYXQgdGhlIHNlc3Npb24gbGV2ZWwgbWVhbmluZyBhbGwg bWVkaWEgc2VjdGlvbnMgYXJlIGRvbmUuDQpFbWlsOiBJdCdzIGRpZmZpY3VsdCB0byBwdXQgaXQg aW4gdGhlcmUgZm9yIFJUQ1dFQi4NClRlZDogU3VyZSwgYnV0IHdlIHNob3VsZCBzYXkgUlRDV0VC IGFsd2F5cyBzZW5kcyBpdCBmb3IgZWFjaCBtZWRpYSBzZWN0aW9uLg0KRUtSOiBSaWdodCBub3cs IGtlZXAgaW4gbWluZCB0aGF0IHdlIGRvbid0IGhhdmUgZXZlbnRzIGZvciBpbmRpdmlkdWFsIG1l ZGlhIHN0cmVhbXMsIG9ubHkgZm9yIHRoZSB3aG9sZSBzZXNzaW9uLg0KVGVkOiBXZSBjYW4gZml4 IHRoYXQsIHJpZ2h0Pw0KRUtSOiBSaWdodC4NCkVLUjogT2gsIGNyYXAuIFRoaXMgd29uJ3Qgd29y ay4gKEkgZGlkbid0IHVuZGVyc3RhbmQgd2h5LCBidXQgSSBhc3N1bWUgRUtSIHdpbGwgcHJvcG9z ZSBhIHNvbHV0aW9uIHRvIHRoZSBsaXN0KQ0KMS4gSUNFIGxpdGUgYW5kIENhbmRpZGF0ZSBTaWdu YWxpbmcNCkpvbmF0aGFuOiBXZSB0aGluayB0aGlzIGp1c3Qgd29ya3MuDQpKdXN0aW46IFdlIHNo b3VsZCBpbmNsdWRlIHNvbWUgZXhhbXBsZXMgdG8gc2hvdyBob3cgdGhpcyB3b3Jrcy4NCjEuIE5l dyBDYW5kaWRhdGVzIGFmdGVyIElDRSBjb21wbGV0aW9uOiBEbyB3ZSBkbyB0aGlzIHdpdGggSUNF IHJlc3RhcnQ/IG9yIHNob3VsZCB3ZSBjb250aW51ZSB0byB0cmlja2xlPw0KSm9uYXRoYW46IEl0 IG5lZWRzIHRvIGJlIElDRSByZXN0YXJ0LiBJIG1pZ2h0IGhhdmUgYWxyZWFkeSByZWFsZWFzZWQg bXkgVFVSTiBzZXJ2ZXIuDQoxLiBTSVAgVXNhZ2UgZm9yIFRyaWNrbGUgSUNFDQpTSVAgYXBwbGlj YXRpb25zIHdpbGwgYWx3YXN5IGRvIGhhbGYtdHJpY2tsZSB1bmxlc3Mgb3RoZXJ3aXNlIGNvbmZp Z3VyZWQuDQpUcmlja2xlIGNhbmRpZGF0ZSB3aWxsIGJlIGRvbmUgd2l0aCBJTkZPIHBhY2thZ2Uu DQpKb25hdGhhbi9BZGFtOiBUaGlzIHNob3VsZCBiZSBhcHBsaWNhdGlvbi9zZHBmcmFnIG5vdCBh cHBsaWNhdGlvbi9zZHANCkZsZW1pbmc6IFdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBoZXJlOyB3ZSdy ZSBkZWZpbmluZyB0d28gZGlmZmVyZW50IG1lYW5zIHRvIGNvbW11bmljYXRlIFNEUCBpbmZvcm1h dGlvbi4gVGhpcyBjYW4gZ28gd3JvbmcgcXVpY2tseS4NCkN1bGxlbjogQWx3YXlzIHRoaW5rIG9m IHRoaXMgYXMgYSBkaWZmLCBub3QgYW4gYWx0ZXJuYXRpdmUgbWVjaGFuaXNtLiBUaGF0IHNhdmVz IHlvdSBmcm9tIEZsZW1pbmcncyB0YXIgcGl0LiBBbHNvLCB3ZSBjb3VsZCBkZWZpbmUgdGhpcyBp biB0ZXJtcyBvZiBhIHBhdGNoIHN5bnRheC4NCkhhZHJpZWw6IEFyZSB5b3UgZ29pbmcgdG8gdGFs ayBhYm91dCB3aGVuIHRoaXMgY2FuIGhhcHBlbj8NCkVtaWw6IFllcyEgUmlnaHQgbm93ISAoY2hl Y2sgc2xpZGVzIGZvciBkaWFncmFtKQ0KQ2hyaXN0ZXI6IFdlJ3JlIGNoYW5naW5nIHRoZSBTRFAg Ym9keS4gRG8gd2UgY2hhbmdlIHRoZSBTRFAgdmVyc2lvbiBudW1iZXIgb3Igbm8/DQpDaHJpc3Rl cjogQWxzbywgd2UgbmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgMTgwIGlzIHNlbnQgcmVsaWFibHku IE1ha2Ugc3VyZSB0aGUgSU5GTyBpcyBzZW50IG9ubHkgd2hlbiBpdCBjYW4gYmUgc2VudC4NClBh dWw6IFRoZXJlJ3MgYWxzbyB0aGUgaXNzdWUgb2Ygd2hlbiBJTkZPIGNhbiBiZSBzZW50Lg0KKEN1 bGxlbiBleHBsb3JlcyBmb3JraW5nLCB3aXRoIGF0IGxlYXN0IG9uZSBwcm9wb3NhbCB0byBpbmNs dWRlIHVmcmFnL3Bhc3N3ZCBpbiB0cmlja2xlIElDRSBmcmFnbWVudHMpDQpFbWlsOiBDdXJyZW50 bHksIHdlIHNheSB0aGF0IHRoZSBJQ0UgcmUtaW52aXRlIG9ubHkgZG9lcyB0aGUgZmlyc3QgY2hl Y2tsaXN0LCBhbmQgYWN0aXZhdGVzIHRoZSBvdGhlciBvbmVzIG9ubHkgYWZ0ZXIgaXQgY29tcGxl dGVzLiBJIHRoaW5rIHdlIGNhbiBpZ25vcmUgdGhhdC4NCkVLUjogTm8sIHlvdSdsbCBlbmQgdXAg d2l0aCBhIHN0b3JtIG9mIElDRSBjaGVja3MsIHdoaWNoIGlzbid0IHJlYWxseSB3aGF0IHdlIHdh bnQuIFdoYXQgeW91IHNob3VsZCBkbyBpczogaWYgeW91IGdldCBhIGNhbmRpYXRlLCBjaGVjayB0 byBzZWUgaWYgYW55dGhpbmcgaXMgcnVubmluZy4gSWYgbm90LCBzdGFydCB0aGUgZmlyc3QgY2hl Y2tsaXN0IHRvIHdoaWNoIHRoZSBjYW5kaWRhdGUgYmVsb25ncy4gSWYgeW91IGRvIHRoYXQsIHlv dSBiZWhhdmUgbXVjaCBtb3JlIGxpa2UgSUNFLCBhbmQgdGhpbmdzIGxpa2Ugc3VpY2lkZSBwYWNr ZXRzIGFyZSBtdWNoIG1vcmUgbGlrZWx5IHRvIHN1Y2NlZWQuDQpNYXJ0aW46IFRoYXQncyBvbmUg d2F5IHRvIGRvIGl0LiBPciB5b3UgY291bGQgY2hlY2sganVzdCBvbmUgcGFpciAob2YgdGhlIHNh bWUgZm91bmRhdGlvbikgZm9yIGVhY2ggY2hlY2tsaXN0Lg0KRUtSOiBUaGF0J3MgYSBiaWcgY2hh bmdlIGluIGJlaGF2aW9yLg0KTWFydGluOiBidXQgaXQgd291bGQgd29yayBiZXR0ZXIuDQpFS1I6 IEdpdmVuIHdoYXQgSSBleHBlY3QgdG8gc2VlIC0tIGFsbCBjYW5kaWRhdGVzIGFycml2aW5nIGlu IGEgZ3JvdXAgLS0geW91J3JlIGdvaW5nIHRvIHNlcmlhbGl6ZSBhbGwgdGhlIGNoZWNrcy4gVGhh dCdzIGhvdyBJQ0UgaXMgbWVhbnQgdG8gYmVoYXZlLg0KRW1pbDogRG9lc24ndCBpdCBhY3RpdmF0 ZSBhbGwgb2YgdGhlIGNoZWNrbGlzdHMgYWZ0ZXIgdGhlIGZpcnN0IG9uZSBjb21wbGV0ZXM/DQpF S1I6IE5vLg0KKEZ1cnRoZXIgY29udmVyc2F0aW9uIGFyb3VuZCBob3cgdGhpcyBpcyBhbGwgc3Vw cG9zZWQgdG8gYmVoYXZlLikNCkpvbmF0aGFuOiBUaGUgcHJpbmNpcGxlIHNob3VsZCBiZSB0aGF0 IHdoZW4gYSBjYW5kaWF0ZSBjb21lcyBpbiwgaWYgaXQgd291bGQgaGF2ZSBiZWVuIHVuZnJvemVu LCB0aGVuIHVuZnJlZXplIGl0LiBPdGhlcndpc2UsIGl0IHNob3VsZCBiZSBmcm96ZW4uDQpFS1I6 IFdlIHJlYWxseSBuZWVkIHRvIHNpdCBkb3duLCB3b3JrIHRocm91Z2ggdGhpcywgYW5kIHdyaXRl IGl0IGRvd24uDQpBY3Rpb24gaXRlbTogRUtSIGFuZCBNYXJ0aW4gdG8gcHJvcG9zZSB0ZXh0DQpK b25hdGhhbjogV2hhdCBoYXBwZW5zIGlmIHRoZSBvdGhlciBzaWRlIG5ldmVyIHNlbmRzIGVuZC1v Zi1jYW5kaWRhdGVzPw0KRW1pbDogVGhpcyBpc24ndCBhbnkgd29yc2UgdGhhbiBub3JtYWwgSUNF Lg0KQ3VsbGVuIChDaGFpcik6IFBsZWFzZSBzZW5kIHNvbWV0aGluZyB0byB0aGUgbGlzdCBkZXNj cmliaW5nIHRoZSBwcm9ibGVtIGFuZCBwcm9wb3NlZCBzb2x1dGlvbnMuDQpGbGVtaW5nOiBUaGVy ZSBhcmUgdHdvIHRoaW5ncyBoZXJlLiBPbmUgc2hvdWxkIHByb2JhYmx5IGdvIHRvIERJU1BBVENI Lg0K --bcaec518692cf1fbab04d6e62095-- From worley@shell01.TheWorld.com Mon Mar 4 12:23:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2521F8FB3 for ; Mon, 4 Mar 2013 12:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, 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 u66CRntOnLii for ; Mon, 4 Mar 2013 12:23:09 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 533AA21F8FAC for ; Mon, 4 Mar 2013 12:23:09 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r24KMDw0030337; Mon, 4 Mar 2013 15:22:16 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r24KMDlj3074902; Mon, 4 Mar 2013 15:22:13 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r24KMDkk3066535; Mon, 4 Mar 2013 15:22:13 -0500 (EST) Date: Mon, 4 Mar 2013 15:22:13 -0500 (EST) Message-Id: <201303042022.r24KMDkk3066535@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B10AE32@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> <201302252244.r1PMiujk2613075@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> <201302262018.r1QKIpUW2695618@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B10AE32@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:23:10 -0000 > From: Christer Holmberg > > >>But, as far as I remember, there were never much discussion about it. > >>It was an open issue on one of my slides, and people simply indicated > >>support for adding explicit information, rather the referencing. > As far as I remember, there were no real technical reasons - it was > mostly "cosmetic". If it's *purely* cosmetic, that is, only for human consumption, a endpoint can add "a=comment:..." lines to document the PT configuration of the bundle. (What? You've never heard of the "comment" attribute? It isn't defined -- and so all endpoints ignore it!) > But, one issue is if there is an intermediary (e.g. transcoder) that > modifies the payload type/codec information in the non-BUNDLE m- > lines, but leaves the BUNDLE m- line untouched and passes the > "kumquat" payload transparently. The offerer and answerer would not > have different payload type/codec information. Although if the PTs were listed in the bundle media description, there would be no assurance that the intermediary would modify the PTs in the bundle media description and the constituent media descriptions in a coordinated way. (Assuming the intermediary doesn't understand bundling.) That would cause demultiplexing to fail. And that analysis is true for all of the bundling proposals I've seen that transmit the constituent media descriptions. In any case, since we expect the RTP streams to be encrypted, no transcoding is possible. > >Adding payload types to the bundle media description makes it more > >difficult to ensure that a non-supporting answerer rejects the > >bundle media description. > > It depends on how it's done. You could still only indicate "kumquat" > on the m- line, but then provide the encapsulated payload type > information using SDP attributes. There's a design question "How do you ensure that non-supporting answerers reject the bundle media description?" There are three ways that I know of: 1) an otherwise unused the media type. Current proposals are "anymedia" and "multipart". 2) an otherwise unused "proto" value. No current proposals use this. 3) offering only an otherwise unused codec. If what you mean is to provide a listing of the codecs used by the constituent streams, but in some attribute other than a=rtpmap, or to list them in a=rtpmap attributes but not put the PTs in the "fmt" list of the m= line, it's not clear what benefit would be gained beyond what a=comment would provide. In any case, it's not clear how you would describe the multiplexed SCTP streams in a way analogous to how you would describe the RTP streams. Dale From fandreas@cisco.com Mon Mar 4 13:41:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14FA21F8D41 for ; Mon, 4 Mar 2013 13:41:35 -0800 (PST) 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 JUIXyFdmCbLZ for ; Mon, 4 Mar 2013 13:41:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A668221F8D51 for ; Mon, 4 Mar 2013 13:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=278; q=dns/txt; s=iport; t=1362433294; x=1363642894; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=AIcJiqqLtjAdKbvK0nns9UrkohidNHOhN7A40cAF9OM=; b=PGxwmDMpo6W6wRjkRraTIj0y4749sh8ughEY0ae3nE95Btb+9hxThzYc 7XwHfkGWw7Ff5iZQ6Amem12LMpzWrBE+sfKVK6x0llNnLxRsrvioy9IqL 1B38hjnDTc+Bc4cnPreU3HR7R8UOW23rbuKDbzY7qTPeu31FUzC8yVFEa c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAMYUNVGtJV2c/2dsb2JhbABEhgmIf7RVFnOCXkA9FhgDAgECAUsNCAEBiA8MoFygagSSUwOIbI1akGyDJg X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208";a="183660940" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 04 Mar 2013 21:41:34 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r24LfXCs011672 for ; Mon, 4 Mar 2013 21:41:34 GMT Message-ID: <5135150D.6070709@cisco.com> Date: Mon, 04 Mar 2013 16:41:33 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:41:35 -0000 The final MMUSIC agenda for IETF 86 has been posted at: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ Please note that we have had to shuffle things around quite a bit, however the overall agenda items are still the same. Thanks Ari & Flemming From keith.drage@alcatel-lucent.com Mon Mar 4 17:00:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7821F893D for ; Mon, 4 Mar 2013 17:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ZLt3cyTYVBKF for ; Mon, 4 Mar 2013 17:00:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB9521F8939 for ; Mon, 4 Mar 2013 17:00:36 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2510QCw012794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Mar 2013 02:00:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 5 Mar 2013 02:00:26 +0100 From: "DRAGE, Keith (Keith)" To: Flemming Andreasen , mmusic Date: Tue, 5 Mar 2013 02:00:25 +0100 Thread-Topic: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 Thread-Index: Ac4ZIQ90Y8Nwt0NUSw+TFNjJDWL78gAG26JA Message-ID: References: <5135150D.6070709@cisco.com> In-Reply-To: <5135150D.6070709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:00:37 -0000 Just to note that the final item on the AVTEXT agenda is the taxonomy draft= , and my understanding was that this was intended to be a joint MMUSIC / AV= TEXT discussion, and reported in both groups, just so we can avoid a jurisd= iction discussion at least for the moment. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Flemming Andreasen > Sent: 04 March 2013 21:42 > To: mmusic > Subject: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 >=20 > The final MMUSIC agenda for IETF 86 has been posted at: >=20 > https://datatracker.ietf.org/meeting/86/agenda/mmusic/ >=20 > Please note that we have had to shuffle things around quite a bit, > however the overall agenda items are still the same. >=20 > Thanks >=20 > Ari & Flemming > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From stefan.lk.hakansson@ericsson.com Mon Mar 4 23:04:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D665621F85FE for ; Mon, 4 Mar 2013 23:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 DP+zPoszfXCc for ; Mon, 4 Mar 2013 23:04:27 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E327F21F85D7 for ; Mon, 4 Mar 2013 23:04:26 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-af-513598f9324d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 65.4A.32353.9F895315; Tue, 5 Mar 2013 08:04:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 08:04:25 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "mmusic@ietf.org" Thread-Topic: Comments on draft-jennings-rtcweb-plan-01 Thread-Index: Ac4Zbzxq78YqMHGBQ1WRmgcWR0U0eQ== Date: Tue, 5 Mar 2013 07:04:24 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B0BB96C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_1447FA0C20ED5147A1AA0EF02890A64B0BB96CESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje7PGaaBBkuWWFtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ/eZRQck6i4ums6YwPjY9EuRk4OCQETicaJXYwQtpjEhXvr 2boYuTiEBA4xSmx+tZgdwlnEKHH0Qjs7SBWbQKDE1n0L2EBsEQF1ia97e5hBbGEBI4l3m66x Q8TNJR7P/8MKYetJXJr3AizOIqAisaixAayeV8BbovlcE9gcRqDN30+tYQKxmQXEJW49mc8E cZGAxJI955khbFGJl4//sULYihJXpy+Hqs+XaOlqZIeYKShxcuYTlgmMQrOQjJqFpGwWkjKI uJ7EjalT2CBsbYllC18zQ9i6EjP+HWJBFl/AyL6KkT03MTMnvdx8EyMw7A9u+W2wg3HTfbFD jNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MDJ8XW6y94auh8wd1otaTOfO sK+avTAwa8n/xCfH/TV5Em39xOOyvGceUn/pHFC0Xk5r0g3T56dm/Lw9oybBQXXWsjdx/yQP CT1KWjcrbe5avbv8j35ICny2/vqjt73St3OJvcCChbpzm38LHD98b8qfd9N/mnO1s4Vd3piz PWC/HdeENJUpYa+VWIozEg21mIuKEwFQ+4brSQIAAA== Subject: [MMUSIC] Comments on draft-jennings-rtcweb-plan-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:04:28 -0000 --_000_1447FA0C20ED5147A1AA0EF02890A64B0BB96CESESSMB209ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I just noted that draft-jennings-rtcweb-plan-01 is on the mmusic agenda for= Orlando. I have made some comments to the document on the rtcweb list (http://www.ie= tf.org/mail-archive/web/rtcweb/current/msg06518.html). It was hinted to me = that many of the comments are more mmusic than rtcweb related, so I thought= I should inform mmusic. Stefan --_000_1447FA0C20ED5147A1AA0EF02890A64B0BB96CESESSMB209ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I just noted that draft-jennings-rtcweb-plan-01 is o= n the mmusic agenda for Orlando.

 

I have made some comments to the document on the rtc= web list (http://www.ietf.org/mail-archive/web/rtcweb/current/msg06518.h= tml). It was hinted to me that many of the comments are more mmusic than rtcweb related, so I thought I should= inform mmusic.

 

Stefan

--_000_1447FA0C20ED5147A1AA0EF02890A64B0BB96CESESSMB209ericsso_-- From randy@qti.qualcomm.com Tue Mar 5 03:47:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF82421F89AF; Tue, 5 Mar 2013 03:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 6K-w4TWaB9P1; Tue, 5 Mar 2013 03:47:46 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 997C221F8991; Tue, 5 Mar 2013 03:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1362484066; x=1394020066; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=XZ92palvqe/bVF9D3mb0X0h4C7GOUdxQOaOZshDBSZ4=; b=wxGFfkfA+E9Mi0OCoPrO+NBYR9pdYzfzaDIHXQkpOSXEEOGOU5rsqO68 JehguG5WBIdx5IDIdFQC64xFkoUiHK+KHME+ezs35HuM/c3HGYgnN2YeB ws4lJs8H9Bd9g3RuPmdF0gTOjvr5WU37q3Zcv9/Gdhigp6KTDyyg8jN7a U=; X-IronPort-AV: E=Sophos;i="4.84,787,1355126400"; d="scan'208";a="27984534" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 05 Mar 2013 03:47:46 -0800 X-IronPort-AV: E=Sophos;i="4.84,787,1355126400"; d="scan'208";a="445694383" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2013 03:47:45 -0800 Received: from [172.16.0.111] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 5 Mar 2013 03:47:44 -0800 Message-ID: In-Reply-To: <6E90227CD3894A258EDE91D85B987169@DougEwell> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> X-Mailer: Eudora for Mac OS X Date: Tue, 5 Mar 2013 03:47:38 -0800 To: Flemming Andreasen , Gunnar Hellstrom , Brian Rosen , Peter Saint-Andre , Keith Drage , Peter Saint-Andre , Brian Rosen , "Hannes (NSN - FI/Espoo) Tschofenig" , "Flemming Andreasen" , Ari Keranen 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.39.5] Cc: Randall Gellens , ietf@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org Subject: Re: [MMUSIC] Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 11:47:48 -0000 Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Ignorance is nothing more than indifference to what is before us; we have only to pay attention--and we are paying attention in a way, but to pretty noise, the newer the better. --Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005. From eckelcu@cisco.com Tue Mar 5 09:06:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B121F87D2; Tue, 5 Mar 2013 09:06:37 -0800 (PST) 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 AiFQ9D-0-aDc; Tue, 5 Mar 2013 09:06:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A977821F87BA; Tue, 5 Mar 2013 09:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1884; q=dns/txt; s=iport; t=1362503196; x=1363712796; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ki+WIgbBNft6w05nY3kHrmSZaVCBZPMW6aPCbtdAInQ=; b=L/h4/FC5TAvCFnaAcE1TQM+jaUDDSI8Qb2qNAPluR6qJDPxv46Hh6Ero VHLXo4CL+A/HTjLW3utwLJFvBU8ZogHqIaCBeRnUkFQX61TfpQ+yMVvfn 6sJ2dSvUffsH3FH/ak5EWUdtRuJqfQv/oqetSDDa9q4tgAuVKzDnwhTDk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK8kNlGtJXHB/2dsb2JhbABExG6BaBZzgikBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiICgGsZpA0jlwmEgaCWWEDpziDCIIn X-IronPort-AV: E=Sophos;i="4.84,787,1355097600"; d="scan'208";a="183996195" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2013 17:06:36 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r25H6aIc001909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 17:06:36 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 11:06:36 -0600 From: "Charles Eckel (eckelcu)" To: Ted Hardie , "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Extremely drafty minutes Thread-Index: AQHOFtwkfs1cLJI9OEe4++p7b3Zq05iXWJtA Date: Tue, 5 Mar 2013 17:06:35 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Extremely drafty minutes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:06:37 -0000 Hi Ted, Thanks for the notes. It was a challenging session to summarize, so I reall= y appreciate your efforts here. One question I have is in regard to the following point from the Feb 5 summ= ary. " All SSRCs related to a single peer connection (which could encompasses mo= re than one MediaStreams having more than one track) would come from a sing= le SSRC space. " Is this a restatement of an opinion expressed at the mic, or does it carry = some weight as a working group consensus? I recall discussion in this area,= but I did not think consensus was reached that this is the way to go. If t= hat is the case, I think the notes should mention that more discussion is n= eeded. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ted Hardie > Sent: Friday, March 01, 2013 4:23 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] Extremely drafty minutes >=20 > Howdy, >=20 > I've been working on minutes for the interim meeting last month; I've > attached the current draft. It needs *extensive* review, as I had > planned to work off recordings for two days, and they turned out to be > available for only half of one. Several folks have volunteered their > notes, but I have not made nearly enough progress. I've decided that > it's better to have something out than nothing, so here they are, in > the current state. >=20 > Please review them and provide input; I will continue to work on them, > but if we don't get more input, they will be *terrible*. >=20 > My apologies for the plan going awry on this, and for the delay. I > kept hoping that more time spent with them would make them coherent; > in large part, I suspect that helped very little all. Please excuse > that and help us correct it, >=20 > thanks, >=20 > Ted Hardie From ted.ietf@gmail.com Tue Mar 5 13:26:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0421F881D; Tue, 5 Mar 2013 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 FpU-Yt34AG4C; Tue, 5 Mar 2013 13:26:26 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9A21F87FF; Tue, 5 Mar 2013 13:26:25 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so6775091iaf.0 for ; Tue, 05 Mar 2013 13:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BB7LyMd/ANd7ImshFunJznsj57UMxQPNpd3XUKjfXoU=; b=dZWJxmqkj3PbfBFbUQpKjBxSg8cf+QAtx04077xx8cNgk9RRRVR9q6SMd6vnva1jdJ VFRyheg6G3G2A0CYgIclc4soESFz1V8c7M/pEQ0ViQnf0TozgqfQyfyYMLah3F7kEqcH 0k/W04bzCPZuGeRwXDgN4exLmrGByR7ZPXN9tbjF6JL4Te+eXLSbr6ma+DRfTYIBJr10 D/e97oFpzfW2zJErAx+OdWBvdtUvcYy43+U8FUfrol4m1o+j/IJBCYZ6yz+zEbj9/BBh ytSyk3mtJzSAARZ6a4rm6Z55aGc7EUHbe6INhka6iceBtxIMPQ4yVkqK1P+ew1WUFpln +8nA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr7814974igj.96.1362518784931; Tue, 05 Mar 2013 13:26:24 -0800 (PST) Received: by 10.43.135.202 with HTTP; Tue, 5 Mar 2013 13:26:24 -0800 (PST) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> Date: Tue, 5 Mar 2013 13:26:24 -0800 Message-ID: From: Ted Hardie To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= , "rtcweb@ietf.org" , "mmusic@ietf.org" , Harald Tveit Alvestrand Subject: Re: [MMUSIC] Extremely drafty minutes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:26:26 -0000 On Tue, Mar 5, 2013 at 9:06 AM, Charles Eckel (eckelcu) wrote: > One question I have is in regard to the following point from the Feb 5 su= mmary. > > " All SSRCs related to a single peer connection (which could encompasses = more than one MediaStreams having more than one track) would come from a si= ngle SSRC space. " > > Is this a restatement of an opinion expressed at the mic, or does it carr= y some weight as a working group consensus? I recall discussion in this are= a, but I did not think consensus was reached that this is the way to go. If= that is the case, I think the notes should mention that more discussion is= needed. > My understanding of this is that it was expressed as a requirement by WebRTC on the work of RTCWEB, needed as part of the mechanics of how to plumb connections via the API. The base requirement is "a consistent identifer space for all the media that will be plumbed"; the SSRCs are the identifiers available. I may be mis-stating this, though, so it might be helpful if Stefan or Harald commented, as I think it was one of them that actually expressed it. As context for those who might be able to add their own understanding here, this is the relevant part of the draft minutes: For signaling, among the points raised: CLUE and RTCWEB likely have two different usage patterns. For CLUE, multiple media sources will be common, multiple encodings per media source will be the norm, multiple endpoints may be visible even in unicast transport, and there may be one or more RTP session. For RTCWEB, the current theory is that there is a single RTP session per media type, if not a single RTP session full stop. All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. regards, Ted From abegen@cisco.com Wed Mar 6 18:49:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E83411E80C5 for ; Wed, 6 Mar 2013 18:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 QY5duglZBkgd for ; Wed, 6 Mar 2013 18:49:56 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9B11E80D3 for ; Wed, 6 Mar 2013 18:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1362624596; x=1363834196; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3ml54Mqkl7zozRxWUEx3lWN15wXYKx1/Hr9C7sGgTgc=; b=b0nBrBwjB7GB+bqgk2NyLz7SLvpI3Tf3y2VqpSejvOwD3oVgbDsrOUC1 lDny6ao5YhFg2S04y2BN5OULyZNlLV2BGWADDLcpERreFtG8QubZSDzp7 0hSCCIn7U+KZpVij/sV7DUUowpDcUmVVSTP0KXKqo6gBsN1cYyEmsL6N4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPP+N1GtJXG9/2dsb2JhbABDhEDABYFkFnOCLQEEOj8SASoUQicEDg0BiAoBC7MDiEOOWzECgmRhA6c7gwmCJw X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="184655242" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 07 Mar 2013 02:49:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r272ntt2020651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 02:49:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 20:49:55 -0600 From: "Ali C. Begen (abegen)" To: "draft-ietf-xrblock-rtcp-xr-synchronization@tools.ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-synchronization-02 Thread-Index: AQHOGt5yH0u0GUQmikyhyoredI+8/w== Date: Thu, 7 Mar 2013 02:49:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.185] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-synchronization-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:49:59 -0000 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - The RTCP XR extension syntax has some issues, see below - There are a few editorial issues Issues: 1) Section 1.4, parag. 1 is confusing. I understand what you mean but there= are some plural/singular issues that need to be fixed. 2) Section 5.1. As I understand the two blocks can be used separately or to= gether (Correct me if I am wrong). So, the ABNF should be as follows: xr-format =3D/ xr-rfisd-block / xr-rfso-block xr-rfisd-block =3D "init-syn-delay" xr-rfso-block =3D "syn-offset" 3) I actually prefer "sync" instead of "syn" in the registrations since syn= is something related to TCP and might be confusing here. 4) Section 6. Write the full name of the registry (RTP Control Protocol Ext= ended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Regis= try). Also, the parameters you are registering should be "init-syn-delay" a= nd "syn-offset" according to Section 5.1. 5) Section 5.2. It is not specified whether this parameter is unilateral or= not. 6) Section 6. Write the full name of the registry (RTP Control Protocol Ext= ended Reports (RTCP XR) Block Type Registry). 7) Section 6. Put a note for the RFC editor asking to replace the a= nd with the actual values upon publications.=20 From abegen@cisco.com Wed Mar 6 20:11:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398A21F8734 for ; Wed, 6 Mar 2013 20:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 nH8JKS5mRjq1 for ; Wed, 6 Mar 2013 20:11:27 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF021F8712 for ; Wed, 6 Mar 2013 20:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=600; q=dns/txt; s=iport; t=1362629480; x=1363839080; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Oc3fhkAjcANjeneO9Ocq6MCdiqxR2SeDn0JVhXNvwxo=; b=W+p0bT2AADSsqtPLywFbVRpFF0gKEbzFZb2sxyCI4dvcPXsu7QEcA/Je TvO1sADSIkzAdJzgSwMqC+4WPnGQuXjYOIO+yL8FZDzg38URjnCwbCGlO 6fzB3gsXr2ZPSf7bUdkEvTQTZAiHs4mps+x3VVNu9GrJLCu2MYVxquIov I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMASOFGtJV2a/2dsb2JhbABDhEDABoFkFnOCLQEEOlEBKhRCJwQbiAsBmgChU45bgxdhA6c7gwmCJw X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="184651515" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 07 Mar 2013 04:11:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r274BIeH017833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Mar 2013 04:11:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 22:11:18 -0600 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" Thread-Topic: Additional text for 4566bis Thread-Index: AQHOGunQi5gF4UoQWEKYluR2E7YgDQ== Date: Thu, 7 Mar 2013 04:11:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EBB496C340C134BAB60213E9CC8C6E1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Additional text for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:11:29 -0000 Section 3 of RFC 3555 states the following: Note that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=3Dfmtp attribute. Flemming suggested that we also mentioned this rule in 4566bis so people wo= n't need to look for anywhere else. Any objections? I think the best place = to add this is Section 5.14. -acbegen= From rachel.huang@huawei.com Thu Mar 7 01:25:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA66D21F8C9D; Thu, 7 Mar 2013 01:25:04 -0800 (PST) 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 OrPu-KNgxkYJ; Thu, 7 Mar 2013 01:25:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1A4C21F8B08; Thu, 7 Mar 2013 01:25:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APC69904; Thu, 07 Mar 2013 09:25:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 09:24:47 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 09:25:01 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Thu, 7 Mar 2013 17:24:55 +0800 From: "Huangyihong (Rachel)" To: "Ali C. Begen (abegen)" , "draft-ietf-xrblock-rtcp-xr-synchronization@tools.ietf.org" Thread-Topic: [MMUSIC][XRBLOCK] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-synchronization-02 Thread-Index: AQHOGxWgn8HkHKZ3JEu//kKUXrOOSA== Date: Thu, 7 Mar 2013 09:24:54 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4572227F@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mmusic@ietf.org" , "xrblock@ietf.org" Subject: Re: [MMUSIC] [XRBLOCK] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-synchronization-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:25:05 -0000 Hi Ali, Thanks for your review. Please see inline. Best Regards! Rachel -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ali C. Begen (abegen) Sent: Thursday, March 07, 2013 10:50 AM To: draft-ietf-xrblock-rtcp-xr-synchronization@tools.ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-syn= chronization-02 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - The RTCP XR extension syntax has some issues, see below - There are a few editorial issues Issues: 1) Section 1.4, parag. 1 is confusing. I understand what you mean but there= are some plural/singular issues that need to be fixed. [Rachel]: Okay. We'll check and fix them. 2) Section 5.1. As I understand the two blocks can be used separately or to= gether (Correct me if I am wrong). So, the ABNF should be as follows: xr-format =3D/ xr-rfisd-block / xr-rfso-block xr-rfisd-block =3D "init-syn-delay" xr-rfso-block =3D "syn-offset" [Rachel]:Oh, we missed the first "/" in our ABNF definition. Thanks for poi= nting out. =20 3) I actually prefer "sync" instead of "syn" in the registrations since syn= is something related to TCP and might be confusing here. [Rachel]:Will fix this. 4) Section 6. Write the full name of the registry (RTP Control Protocol Ext= ended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Regis= try). Also, the parameters you are registering should be "init-syn-delay" a= nd "syn-offset" according to Section 5.1. [Rachel]:Okay. 5) Section 5.2. It is not specified whether this parameter is unilateral or= not. [Rachel]: Right. We will rewrite it as following "When SDP is used in offer-answer context, the SDP Offer/Answer usage defin= ed in [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. For = detailed usage of Offer/Answer for unilateral parameter, refer to section 5= .2 of [RFC3611]."=20 6) Section 6. Write the full name of the registry (RTP Control Protocol Ext= ended Reports (RTCP XR) Block Type Registry). [Rachel]: Okay. 7) Section 6. Put a note for the RFC editor asking to replace the a= nd with the actual values upon publications.=20 [Rachel]: Will do. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From worley@shell01.TheWorld.com Thu Mar 7 14:37:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40721F8C7C for ; Thu, 7 Mar 2013 14:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 HnbXI+NCJ0-u for ; Thu, 7 Mar 2013 14:37:09 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6721F8A6E for ; Thu, 7 Mar 2013 14:37:09 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r27MaMYN025731 for ; Thu, 7 Mar 2013 17:36:24 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r27MaLA03269656 for ; Thu, 7 Mar 2013 17:36:22 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r27MaLdw3250567; Thu, 7 Mar 2013 17:36:21 -0500 (EST) Date: Thu, 7 Mar 2013 17:36:21 -0500 (EST) Message-Id: <201303072236.r27MaLdw3250567@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] How to offer a constituent media description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 22:37:10 -0000 There are a lot of fussy details about how to offer a constituent media description. I've counted six different methods so far. I've written up an analysis of the pros and cons of the various methods. The least troublesome methods (IMHO) are to offer a real address and unique, non-zero port, with the offerer's choice of whether or not to provide TURN candidates. (Offering TURN candidates requires preallocating TURN relays for the constituents which will not be needed if the answerer supports bundling; not offering TURN candidates requires an SDP update to communicate with a non-supporting answerer.) Following is the text version of the comparison. The HTML version is accessible at https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-sdp-bundle-04a.html#rfc.section.7.10 (You can also use the http: form of that URL, but for some reason, the response won't be tagged as text/html.) Dale 7.10. How the Constituent MDs Are Offered There are a number of alternative ways that the offerer can configure the constituent media descriptions. +------------+------+--------+--------+---------+---------+---------+ | Method | 1 | 2 | 3 | 4 | 5 | 6 | +------------+------+--------+--------+---------+---------+---------+ | Offered | null | null | real | real | real | real | | address | | | | | | | | | | | | | | | | Offered | zero | non- | zero | non- | non- | non- | | port | | zero | | zero, | zero, | zero, | | | | | | unique | unique | shared | | | | | | | | | | TURN candi | no | no | no | no | yes | yes | | dates? | | | | | | | | | | | | | | | | Supporting | yes | yes | yes | yes | yes | yes | | answerer | | | | | | | | accepts? | | | | | | | | | | | | | | | | Update | no | no | possib | yes | yes | no | | needed for | | | ly | | | | | supporting | | | | | | | | answerer? | | | | | | | | | | | | | | | | Non- | no | probab | no | yes | yes | yes | | supporting | | ly | | | | | | answerer | | | | | | | | accepts? | | | | | | | | | | | | | | | | Update | yes | yes | yes | yes | no | no | | needed for | | | | | | | | non- | | | | | | | | supporting | | | | | | | | answerer? | | | | | | | | | | | | | | | | Disadvanta | ACE | CD | ABCE | BC | BG | BFG | | ges | | | | | | | +------------+------+--------+--------+---------+---------+---------+ Offered address This is the address offered for the MD. There are two choices, a null address (0.0.0.0 for IPv4 or "invalid." for IPv6 or mixed IPv4/IPv6) or a real address of the offerer. Offered port This is the port that is offered. It can be either non-zero or zero (which indicates a stream that is not being offered). If the offered port is non-zero and the offered address is real, the port can be either unique, or shared with the other media descriptions in the bundle. TURN candidates? If the offered address is real, are TURN candidates for the address provided (if they are needed)? Supporting answerer accepts? If the answerer supports bundling, does it accept this media description? We assume the answer is Yes, so that acceptance of the constituent media descriptions can be signaled to the offerer. Update needed for supporting answerer? Is an SDP update needed to complete session setup if the answerer supports bundling? If an update is needed, it is needed to inform intermediaries that there will be no media sent based on the connection information in this media description; the update is not needed to establish communications and does not delay the application. Non-supporting answerer accepts? If the answerer does not support bundling, does it accept this media description (without a further update)? Update needed for non-supporting answerer? Is an SDP update needed to complete session setup if the answerer does not support bundling? If an update is needed, in all cases, it is needed to establish communication. Flaws The disadvantages of each alternative: A Media descriptions that are rejected (have zero ports) are not allowed to be members of a group (in the offer).[RFC5888] B An SDP update is needed for a supporting answerer to prevent intermediaries from timing out the multimedia session. C An SDP update is needed for a non-supporting answerer to establish communications. D Although a media description with a non-zero port but a null address is formally offered (although shown as on-hold via the old method), it is possible that the answerer will not consider it to be offered and many not accept it even if it otherwise wood. E If the offered port is zero, the media description is not formally offered and the answerer should not accept it. F SDP offers with multiple media descriptions that use the same port number (for the same real address) may be rejected by intermediaries. G A TURN relay must be allocated for the constituent media description before the offer is sent. In my estimation, the worst disadvantages are A (zero port in offer), E (acceptance of offer with zero port), and F (duplicate port numbers), because they involve violations of [RFC4566] or are known to trigger limitations of large numbers of intermediate devices. Disadvantage D (offering a MD with a null address) is nearly as severe, as we expect it to cause undesired behavior in many non- supporting answerers. Disadvantages C (update needed to communicate with non-supporting answerer) and G (TURN relay must be preallocated) are moderate, and disadvantage B (updated needed to prevent intermediaries from timing out) is the least severe (because it never delays the establishment of communication). Applying these priorities to the possible solutions, methods 4 and 5 (offer real address, non-zero unique port, with/without TURN candidates) are tied for the best choices, with the choice made based on the relative importance of minimizing preallocation of TURN relays compared to quickly establishing communication with non-supporting answerers. From randy@qti.qualcomm.com Sat Mar 9 09:43:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379F221F868F; Sat, 9 Mar 2013 09:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 AvaMqReoCPcw; Sat, 9 Mar 2013 09:43:51 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 175D921F866F; Sat, 9 Mar 2013 09:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1362851030; x=1394387030; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=t73Bh+4R7L6ID5boJV0oZTMqDmUcaKewfVvALAk2BYs=; b=TDKh0l2n1s5eYqae0sfqjGP3vRYBxnF03yqovOi4VWG01s7v7LtG/tgb 5/EuhqMPA67A+F1cyAdIHZO37yTVu+wJzHa5EY9zBLUffI+yCrYOIO4Zg ZtcF7Zq/sTQRvmJficwj+qa5i3S24z8Cqeo0ds/9rZj/r3fhKh6RKEIng M=; X-IronPort-AV: E=Sophos;i="4.84,814,1355126400"; d="scan'208";a="29298577" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Mar 2013 09:43:50 -0800 X-IronPort-AV: E=Sophos;i="4.84,814,1355126400"; d="scan'208";a="440094216" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Mar 2013 09:43:50 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 9 Mar 2013 09:43:49 -0800 Message-ID: In-Reply-To: <513B64DC.7070305@stpeter.im> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> X-Mailer: Eudora for Mac OS X Date: Sat, 9 Mar 2013 09:43:47 -0800 To: Peter Saint-Andre , Randall Gellens , Flemming Andreasen , Gunnar Hellstrom , Brian Rosen , Keith Drage , Peter Saint-Andre , Brian Rosen , "Hannes (NSN - FI/Espoo) Tschofenig" , Ari Keranen , Alexey Melnikov 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.39.5] Cc: ietf@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org Subject: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:43:52 -0000 Hi everyone, It looks like Thursday lunch (11:30-1:00) works well for everyone who has responded so far. Let's plan on that for now. At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: > It looks like Thursday lunch would > work well. > > On 3/5/13 4:47 AM, Randall Gellens wrote: >> Hi all, >> >> I created a Doodle poll to see if we can find a time in Orlando to meet >> face to face. >> >> Doodle poll for time at Orlando to discuss open issues and moving >> forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 >> >> Link to current version (-02) of draft: >> >> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A child of five would understand this. Send somebody to fetch a child of five. --Groucho Marx, "Duck Soup" From pkyzivat@alum.mit.edu Sat Mar 9 10:43:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364D21F8718 for ; Sat, 9 Mar 2013 10:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.160, 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 k0YPnQ7GkP20 for ; Sat, 9 Mar 2013 10:43:26 -0800 (PST) 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 892DF21F8714 for ; Sat, 9 Mar 2013 10:43:26 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id 9UPp1l00417dt5G54WjMTU; Sat, 09 Mar 2013 18:43:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 9WjM1l00f3ZTu2S3ZWjM9S; Sat, 09 Mar 2013 18:43:21 +0000 Message-ID: <513B82C9.7020300@alum.mit.edu> Date: Sun, 10 Mar 2013 02:43:21 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> 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=1362854601; bh=1aRE0xjq8Apv4OzSUkZfhBxviftvB0UuN33zbjjcggU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E4ojdN0u70WIfySs0mhE43KXnnRqACj0e8JVwa+KT3d9QUnpGZa3LGngTnprLvd/L W/3RlFALD58Nw7bB/v/hlSbXHf5fHBwAxvTWrzIT+3Uyzy8h1IkLL90HXYE1vtCMF7 b7VUNlSfkR+7Ge1LldskcxSphvR/D0Xe73DyWYn10uTUKIbTTyrhvNtYMMUcVQiwtf xVSURoWGsumvqNN9Gs6H5DcyWt/PIoemrx6oacVp2DwbNjAxZ00Bc6Ods7QnkjkIUY 1OtvHp5CZ2rSKyMZ2oJToBI4JAwM4fEMKz4tdl8j6JmeEq/L0arxqagu8TOQhRg/O6 pIaoxeAfvoItQ== Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 18:43:27 -0000 On 3/10/13 1:43 AM, Randall Gellens wrote: > Hi everyone, > > It looks like Thursday lunch (11:30-1:00) works well for everyone who > has responded so far. Let's plan on that for now. I just noticed this. This sounds like an application for callerprefs. I'm not sure if I can make it, but keep me on the list as you figure out where to meet. Thanks, Paul > At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: > >> It looks like Thursday lunch would >> work well. >> >> On 3/5/13 4:47 AM, Randall Gellens wrote: >>> Hi all, >>> >>> I created a Doodle poll to see if we can find a time in Orlando to meet >>> face to face. >>> >>> Doodle poll for time at Orlando to discuss open issues and moving >>> forward with Human Language Negotiation: >>> http://doodle.com/uwedikez6etwsf39 >>> >>> Link to current version (-02) of draft: >>> >>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >>> >>> > > From abegen@cisco.com Sun Mar 10 00:43:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16E21F041A for ; Sun, 10 Mar 2013 00:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 WdiGAR8LQVkA for ; Sun, 10 Mar 2013 00:43:46 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63E21F86C9 for ; Sun, 10 Mar 2013 00:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11102; q=dns/txt; s=iport; t=1362905026; x=1364114626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y8/LwgTQ/kTuDoFTkWF1ScmI8+zUJUzzewSYf1d9bow=; b=QZvBI26jYEajYBTZn5oRuRabeik1BvVcRqaTe7yJZnDaIkcZCzgfEV+B 0aPBwqpiOem7a5FOLeQFf8QRW+DCF6mPNbndJ6qpmGUQnQExqjHRBje0/ 3zD0dUeyXyJjVRKjzCJKoLQTCiH9CaxDzQAEooyOJu+qLcsuobqASNLPy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKJGPFGtJXHA/2dsb2JhbABCDoQfwBOBTRZ0giYBAQECAQFoEQULAgEIDgoKJDIlAgQOBQiIBQYBC7stjlsCMQeCX2EDiDyKVJQ6gks/gig X-IronPort-AV: E=Sophos;i="4.84,817,1355097600"; d="scan'208";a="185759594" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 10 Mar 2013 08:43:44 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2A8hhZ1031999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Mar 2013 08:43:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 03:43:43 -0500 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjLtrmzSS0hf0Omfa72mDfZ75g4pQWAgAA0aQCAAAFJAIAAFbaAgGYRvgA= Date: Sun, 10 Mar 2013 08:43:42 +0000 Message-ID: References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> In-Reply-To: <50E64D21.2030609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 08:43:47 -0000 Hi Paul, Reviving this old thread as I am planning to submit another update for 4566= bis. I reviewed your text changes. Comments below. On Jan 3, 2013, at 7:31 PM, Paul Kyzivat wrote: > On 1/3/13 9:14 PM, Ali C. Begen (abegen) wrote: >=20 >> Are you saying we don't change the text or remove it altogether? >=20 > Major change. >=20 > OLD: >=20 > The connection ("c=3D") and attribute ("a=3D") information in the > session-level section applies to all the media of that session unless > overridden by connection information or an attribute of the same name > in the media description. For instance, in the example below, each > media behaves as if it were given a "recvonly" attribute. >=20 > An example SDP description is: >=20 > v=3D0 > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > s=3DSDP Seminar > i=3DA Seminar on the session description protocol > u=3Dhttp://www.example.com/seminars/sdp.pdf > e=3Dj.doe@example.com (Jane Doe) > c=3DIN IP4 233.252.0.1/127 > t=3D2873397496 2873404696 > a=3Drecvonly > m=3Daudio 49170 RTP/AVP 0 > m=3Dvideo 51372 RTP/AVP 99 > a=3Drtpmap:99 h263-1998/90000 >=20 > NEW: >=20 > The connection ("c=3D") information in the > session-level section applies to all the media of that session unless > overridden by connection information > in the media description. For instance, in the example below, each > audio media behaves as if it were given a "c=3DIN IP4 192.0.2.3". >=20 > An example SDP description is: >=20 > v=3D0 > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > s=3DSDP Seminar > i=3DA Seminar on the session description protocol > u=3Dhttp://www.example.com/seminars/sdp.pdf > e=3Dj.doe@example.com (Jane Doe) > c=3DIN IP4 192.0.2.3 > t=3D2873397496 2873404696 > a=3Drecvonly > m=3Daudio 49170 RTP/AVP 0 > m=3Daudio 49180 RTP/AVP 0 > m=3Dvideo 51372 RTP/AVP 99 > c=3DIN IP4 233.252.0.1/127 > a=3Drtpmap:99 h263-1998/90000 >=20 > This drops all discussion of attributes and just describes the behavior f= or c-lines. >=20 Yes, it does. >>> And at the same time we should polish up the definitions of the attribu= tes defined in this document so that they are very clear how session and me= dia level interact. >>=20 >> Could you provide an example of what you have in mind? >=20 > I'll try. (But please review this carefully!) In section 6: >=20 > OLD: >=20 > a=3Drecvonly >=20 > This specifies that the tools should be started in receive-only > mode where applicable. It can be either a session- or media- > level attribute, and it is not dependent on charset. Note that > recvonly applies to the media only, not to any associated > control protocol (e.g., an RTP-based system in recvonly mode > SHOULD still send RTCP packets). >=20 > a=3Dsendrecv >=20 > This specifies that the tools should be started in send and > receive mode. This is necessary for interactive conferences > with tools that default to receive-only mode. It can be either > a session or media-level attribute, and it is not dependent on > charset. >=20 > If none of the attributes "sendonly", "recvonly", "inactive", > and "sendrecv" is present, "sendrecv" SHOULD be assumed as the > default for sessions that are not of the conference type > "broadcast" or "H332" (see below). >=20 > a=3Dsendonly >=20 > This specifies that the tools should be started in send-only > mode. An example may be where a different unicast address is > to be used for a traffic destination than for a traffic source. > In such a case, two media descriptions may be used, one > sendonly and one recvonly. It can be either a session- or > media-level attribute, but would normally only be used as a > media attribute. It is not dependent on charset. Note that > sendonly applies only to the media, and any associated control > protocol (e.g., RTCP) SHOULD still be received and processed as > normal. >=20 > a=3Dinactive >=20 > This specifies that the tools should be started in inactive > mode. This is necessary for interactive conferences where > users can put other users on hold. No media is sent over an > inactive media stream. Note that an RTP-based system SHOULD > still send RTCP, even if started inactive. It can be either a > session or media-level attribute, and it is not dependent on > charset. >=20 > NEW: >=20 > a=3Drecvonly, a=3Dsendrecv, a=3Dsendonly, a=3Dinactive >=20 > At most one of recvonly/sendrecv/sendonly/inactive MAY appear > at session level, and at most one MAY appear in each media > section. >=20 > If any one of these appears in a media section then it > applies for that media section. If none appear in a media > section then the one from session level, if any, applies > to that media section. >=20 > If none of the attributes "sendonly", "recvonly", "inactive", > and "sendrecv" is present at either session level or media > level, "sendrecv" SHOULD be assumed as the > default for sessions that are not of the conference type > "broadcast" or "H332" (see below). >=20 > For instance, in the > example below, each media behaves as if it were given a > "recvonly" attribute. >=20 > An example SDP description is: >=20 > v=3D0 > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > s=3DSDP Seminar > i=3DA Seminar on the session description protocol > u=3Dhttp://www.example.com/seminars/sdp.pdf > e=3Dj.doe@example.com (Jane Doe) > c=3DIN IP4 233.252.0.1/127 > t=3D2873397496 2873404696 > a=3Drecvonly > m=3Daudio 49170 RTP/AVP 0 > m=3Dvideo 51372 RTP/AVP 99 > a=3Drtpmap:99 h263-1998/90000 > a=3Drecvonly >=20 Is not the last/second "recvonly" redundant? > a=3Drecvonly >=20 > This specifies that the tools should be started in receive-only > mode where applicable. It can be either a session- or media- > level attribute, and it is not dependent on charset. Note that > recvonly applies to the media only, not to any associated > control protocol (e.g., an RTP-based system in recvonly mode > SHOULD still send RTCP packets). >=20 > a=3Dsendrecv >=20 > This specifies that the tools should be started in send and > receive mode. This is necessary for interactive conferences > with tools that default to receive-only mode. It can be either > a session or media-level attribute, and it is not dependent on > charset. >=20 > a=3Dsendonly >=20 > This specifies that the tools should be started in send-only > mode. An example may be where a different unicast address is > to be used for a traffic destination than for a traffic source. > In such a case, two media descriptions may be used, one > sendonly and one recvonly. It can be either a session- or > media-level attribute. It is not dependent on charset. > Note that > sendonly applies only to the media, and any associated control > protocol (e.g., RTCP) SHOULD still be received and processed as > normal. >=20 > a=3Dinactive >=20 > This specifies that the tools should be started in inactive > mode. This is necessary for interactive conferences where > users can put other users on hold. No media is sent over an > inactive media stream. Note that an RTP-based system SHOULD > still send RTCP, even if started inactive. It can be either a > session or media-level attribute, and it is not dependent on > charset. >=20 All good.=20 > Also in section 6: >=20 > OLD: >=20 > a=3Dsdplang: >=20 > This can be a session-level attribute or a media-level > attribute. As a session-level attribute, it specifies the > language for the session description. As a media-level > attribute, it specifies the language for any media-level SDP > information field associated with that media. Multiple sdplang > attributes can be provided either at session or media level if > the session description or media use multiple languages. >=20 > NEW: >=20 > a=3Dsdplang: >=20 > This can be a session-level attribute or a media-level > attribute. Multiple sdplang attributes can be provided > either at session or media level if the session description > or media use multiple languages. >=20 > As a session-level attribute, it specifies the > language for the session description. As a media-level > attribute, it specifies the language for any media-level SDP > information field associated with that media, overriding any > sdplang attributes specified at session-level. >=20 > OLD: >=20 > a=3Dlang: >=20 > This can be a session-level attribute or a media-level > attribute. As a session-level attribute, it specifies the > default language for the session being described. As a media- > level attribute, it specifies the language for that media, > overriding any session-level language specified. Multiple lang > attributes can be provided either at session or media level if > the session or media use multiple languages, in which case the > order of the attributes indicates the order of importance of > the various languages in the session or media, from most > important to least important. >=20 > NEW: >=20 > a=3Dlang: >=20 > This can be a session-level attribute or a media-level > attribute. Multiple lang > attributes can be provided either at session or media level if > the session or media use multiple languages, in which case the > order of the attributes indicates the order of importance of > the various languages in the session or media, from most > important to least important. >=20 > As a session-level attribute, it specifies the > default language for the session being described. > As a media-level attribute, it specifies the language for > that media, overriding any session-level languages specified. >=20 This is also good. Thanks. -acbegen > That's all. >=20 > Thanks, > Paul From randy@qti.qualcomm.com Sun Mar 10 06:36:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9421F86BB; Sun, 10 Mar 2013 06:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 0iiaBZoMxqRP; Sun, 10 Mar 2013 06:36:58 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7152521F86B6; Sun, 10 Mar 2013 06:36:58 -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=1362922618; x=1394458618; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=ZCBZalUyMtsF8pdulRDar+ysUwmW/Css+rJabPgjv5k=; b=M43N1k0hAmycpOflFBABu72bL60qbkLRzZbvsmtwbzjp9ulXvFHQr5Oc SfQTYWE0cAsEXR6yES2/yCHBcR0LT3ArmcJ0jAsr2z8p0CpDbC4OBsBLu kM/+MhpSC9qP7yRg+tx+ivk0YfSMZHvY3Do8MRj9nvLZmY9l3CnhuGZsD Y=; X-IronPort-AV: E=Sophos;i="4.84,817,1355126400"; d="scan'208";a="29324290" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 10 Mar 2013 06:36:57 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 06:36:56 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 06:36:55 -0700 Message-ID: In-Reply-To: References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 06:36:54 -0800 To: Eric Burger , Peter Saint-Andre 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.39.5] Cc: Ari Keranen , mmusic@ietf.org, Peter Saint-Andre , Keith Drage , Gunnar Hellstrom , ietf-languages-bounces@alvestrand.no, Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Brian Rosen , Randall Gellens , ietf@ietf.org Subject: Re: [MMUSIC] Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 13:36:59 -0000 Thursday lunch (11:30-1:00) it is. I'll make a reservation at The Tropicale (the cafe in the Caribe Royal hotel attached to the convention center). Everyone: please let me know if you can make it so I can make sure we have the right size table. At 8:45 AM -0400 3/10/13, Eric Burger wrote: > Confirmed? Venue? > > On Mar 9, 2013, at 11:35 AM, Peter Saint-Andre wrote: > >> I replied, sorry about the delay. It looks like Thursday lunch would >> work well. >> >> On 3/5/13 4:47 AM, Randall Gellens wrote: >>> Hi all, >>> >>> I created a Doodle poll to see if we can find a time in Orlando to meet >>> face to face. >>> >>> Doodle poll for time at Orlando to discuss open issues and moving > >> forward with Human Language Negotiation: > http://doodle.com/uwedikez6etwsf39 >>> >>> Link to current version (-02) of draft: >>> >>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >>> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Consultants are mystical people who ask a company for a number and then give it back to them. From eburger@standardstrack.com Sun Mar 10 05:47:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DCC21F8639; Sun, 10 Mar 2013 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 MwHvEMFSTw1C; Sun, 10 Mar 2013 05:47:38 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id A28AA21F8613; Sun, 10 Mar 2013 05:47:38 -0700 (PDT) Received: from dhcp-42e0.meeting.ietf.org ([130.129.66.224]:51471) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UEff3-0006l9-8w; Sun, 10 Mar 2013 05:47:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: <513B64DC.7070305@stpeter.im> Date: Sun, 10 Mar 2013 08:45:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sun, 10 Mar 2013 06:44:46 -0700 Cc: Ari Keranen , mmusic@ietf.org, Peter Saint-Andre , Keith Drage , Gunnar Hellstrom , ietf-languages-bounces@alvestrand.no, Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Brian Rosen , Randall Gellens , ietf@ietf.org Subject: Re: [MMUSIC] Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 12:47:39 -0000 Confirmed? Venue? On Mar 9, 2013, at 11:35 AM, Peter Saint-Andre = wrote: > I replied, sorry about the delay. It looks like Thursday lunch would > work well. >=20 > On 3/5/13 4:47 AM, Randall Gellens wrote: >> Hi all, >>=20 >> I created a Doodle poll to see if we can find a time in Orlando to = meet >> face to face. >>=20 >> Doodle poll for time at Orlando to discuss open issues and moving >> forward with Human Language Negotiation: = http://doodle.com/uwedikez6etwsf39 >>=20 >> Link to current version (-02) of draft: >> = http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-langua= ge-02.txt >>=20 From randy@qti.qualcomm.com Sun Mar 10 06:54:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE32721F8441; Sun, 10 Mar 2013 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 BUwSLmP8n5QQ; Sun, 10 Mar 2013 06:54:26 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D321F8425; Sun, 10 Mar 2013 06:54:19 -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=1362923660; x=1394459660; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=YQG0gr8XlOxq0gV/OEK0W83UhjOKslKcUAG6fPbF0J4=; b=D5OgEXNm5KoFPVnvAKbPYgLvsTmWmPQ9JhwSLWr9wvGyRHMuaqJbcF6G H+0VDQXx1PU2xbwH7QK4gWe8hpqBg2LhnZToezC7UuRaBI3XMYaRmHQhB ERzKqPx99IWdxad2/72/mKu0SLGc0BsT9XSWOBlMUM5TiKFyTkjCFpQr9 I=; X-IronPort-AV: E=Sophos;i="4.84,817,1355126400"; d="scan'208";a="29324875" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 10 Mar 2013 06:54:19 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 06:54:18 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 06:54:17 -0700 Message-ID: In-Reply-To: References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 06:38:51 -0800 To: Randall Gellens , Peter Saint-Andre , Flemming Andreasen , "Gunnar Hellstrom" , Brian Rosen , Keith Drage , Peter Saint-Andre , Brian Rosen , "Hannes (NSN - FI/Espoo) Tschofenig" , Ari Keranen , Alexey Melnikov 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.39.5] Cc: ietf@ietf.org, ietf-languages-bounces@alvestrand.no, mmusic@ietf.org Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 13:54:27 -0000 Hi Everyone, Thursday lunch (11:30-1:00) it is. I'll make a reservation at The Tropicale (the cafe in the Caribe Royal hotel attached to the convention center). Please let me know if you can make it so I can make sure we have a large enough table. Thank you. > Hi everyone, > > It looks like Thursday lunch (11:30-1:00) works well for everyone > who has responded so far. Let's plan on that for now. > > At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: > >> It looks like Thursday lunch would >> work well. >> >> On 3/5/13 4:47 AM, Randall Gellens wrote: >>> Hi all, >>> >>> I created a Doodle poll to see if we can find a time in Orlando to meet >>> face to face. >>> >>> Doodle poll for time at Orlando to discuss open issues and moving >>> forward with Human Language Negotiation: >>> http://doodle.com/uwedikez6etwsf39 >>> >>> Link to current version (-02) of draft: >>> >>> >>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >>> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > A child of five would understand this. Send somebody to > fetch a child of five. --Groucho Marx, "Duck Soup" -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The whole dream of democracy is to raise the proletarian to the level of stupidity attained by the bourgeois. --Gustave Flaubert From brett@broadsoft.com Sun Mar 10 07:25:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882921F86D9 for ; Sun, 10 Mar 2013 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 NGuO-3fkwzWd for ; Sun, 10 Mar 2013 07:25:53 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5121F86D5 for ; Sun, 10 Mar 2013 07:25:53 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 10 Mar 2013 07:27:54 -0700 Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 07:27:54 -0700 From: Brett Tate To: "Ali C. Begen (abegen)" , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjLtrmzSS0hf0Omfa72mDfZ75g4pQWAgAA0aQCAAAFJAIAAFbaAgGYRvgCAAFzE0A== Date: Sun, 10 Mar 2013 14:27:53 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:25:56 -0000 > >>> And at the same time we should polish up the definitions of the > attributes defined in this document so that they are very clear how > session and media level interact. > >> > >> Could you provide an example of what you have in mind? > > > > I'll try. (But please review this carefully!) In section 6: > > > > OLD: > > > > a=3Drecvonly > > > > This specifies that the tools should be started in receive- > only > > mode where applicable. It can be either a session- or media- > > level attribute, and it is not dependent on charset. Note > that > > recvonly applies to the media only, not to any associated > > control protocol (e.g., an RTP-based system in recvonly mode > > SHOULD still send RTCP packets). > > > > a=3Dsendrecv > > > > This specifies that the tools should be started in send and > > receive mode. This is necessary for interactive conferences > > with tools that default to receive-only mode. It can be > either > > a session or media-level attribute, and it is not dependent > on > > charset. > > > > If none of the attributes "sendonly", "recvonly", "inactive", > > and "sendrecv" is present, "sendrecv" SHOULD be assumed as > the > > default for sessions that are not of the conference type > > "broadcast" or "H332" (see below). > > > > a=3Dsendonly > > > > This specifies that the tools should be started in send-only > > mode. An example may be where a different unicast address is > > to be used for a traffic destination than for a traffic > source. > > In such a case, two media descriptions may be used, one > > sendonly and one recvonly. It can be either a session- or > > media-level attribute, but would normally only be used as a > > media attribute. It is not dependent on charset. Note that > > sendonly applies only to the media, and any associated > control > > protocol (e.g., RTCP) SHOULD still be received and processed > as > > normal. > > > > a=3Dinactive > > > > This specifies that the tools should be started in inactive > > mode. This is necessary for interactive conferences where > > users can put other users on hold. No media is sent over an > > inactive media stream. Note that an RTP-based system SHOULD > > still send RTCP, even if started inactive. It can be either > a > > session or media-level attribute, and it is not dependent on > > charset. > > > > NEW: > > > > a=3Drecvonly, a=3Dsendrecv, a=3Dsendonly, a=3Dinactive > > > > At most one of recvonly/sendrecv/sendonly/inactive MAY appear > > at session level, and at most one MAY appear in each media > > section. > > > > If any one of these appears in a media section then it > > applies for that media section. If none appear in a media > > section then the one from session level, if any, applies > > to that media section. > > > > If none of the attributes "sendonly", "recvonly", "inactive", > > and "sendrecv" is present at either session level or media > > level, "sendrecv" SHOULD be assumed as the > > default for sessions that are not of the conference type > > "broadcast" or "H332" (see below). > > > > For instance, in the > > example below, each media behaves as if it were given a > > "recvonly" attribute. > > > > An example SDP description is: > > > > v=3D0 > > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > > s=3DSDP Seminar > > i=3DA Seminar on the session description protocol > > u=3Dhttp://www.example.com/seminars/sdp.pdf > > e=3Dj.doe@example.com (Jane Doe) > > c=3DIN IP4 233.252.0.1/127 > > t=3D2873397496 2873404696 > > a=3Drecvonly > > m=3Daudio 49170 RTP/AVP 0 > > m=3Dvideo 51372 RTP/AVP 99 > > a=3Drtpmap:99 h263-1998/90000 > > a=3Drecvonly > > >=20 > Is not the last/second "recvonly" redundant? Yes; although is simplifies the example. The following example/description= adjustment reflects a potential change to the session level attribute. Within the following SDP example, the "inactive" attribute applies to audio= media and the "recvonly" attribute applies to video media. v=3D0 o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=3DSDP Seminar i=3DA Seminar on the session description protocol u=3Dhttp://www.example.com/seminars/sdp.pdf e=3Dj.doe@example.com (Jane Doe) c=3DIN IP4 233.252.0.1/127 t=3D2873397496 2873404696 a=3Dinactive m=3Daudio 49170 RTP/AVP 0 m=3Dvideo 51372 RTP/AVP 99 a=3Drtpmap:99 h263-1998/90000 a=3Drecvonly From keith.drage@alcatel-lucent.com Sun Mar 10 07:30:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB8F21F874B for ; Sun, 10 Mar 2013 07:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 B8Wgru2sOal3 for ; Sun, 10 Mar 2013 07:30:04 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1208021F8613 for ; Sun, 10 Mar 2013 07:30:03 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2AEU2dX028923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 10 Mar 2013 15:30:03 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 10 Mar 2013 15:30:03 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 15:30:02 +0100 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Topic: Grouping discussion Thread-Index: Ac4dm7/B9rpF4Z7tRMKQLyD77M9ucg== Date: Sun, 10 Mar 2013 14:30:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BEDCB@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [MMUSIC] Grouping discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:30:05 -0000 I have made a small revision to the AVTEXT agenda which can be found here. https://datatracker.ietf.org/meeting/86/agenda/avtext/ The addition is to add draft-burman-rtcweb-mmusic-media-structure-00 as a relevant document to the discussion on grouping, which is joint with M= MUSIC. There is also planned to be an ad-hoc discussion of the grouping material o= n Monday in the slot 15:40 to 17:10. If you are interested in participating= in this discussion please consult with either Bo Burman, or one of the AVT= EXT chairs, and we'll let you know which room, when we find out ourselves. Regards Keith From harald@alvestrand.no Sun Mar 10 08:07:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52CC21F86C9; Sun, 10 Mar 2013 08:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.332 X-Spam-Level: X-Spam-Status: No, score=-110.332 tagged_above=-999 required=5 tests=[AWL=0.268, 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 nQI6aXZiz3Tv; Sun, 10 Mar 2013 08:07:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE921F8640; Sun, 10 Mar 2013 08:07:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7426439E1AD; Sun, 10 Mar 2013 16:07:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJqAVU7za3r5; Sun, 10 Mar 2013 16:07:04 +0100 (CET) Received: from [192.168.255.9] (unknown [216.189.219.66]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2259339E182; Sun, 10 Mar 2013 16:07:00 +0100 (CET) Message-ID: <513CA193.30304@alvestrand.no> Date: Sun, 10 Mar 2013 16:06:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Randall Gellens References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , ietf@ietf.org, Alexey Melnikov , Gunnar Hellstrom , Keith Drage , Peter Saint-Andre , ietf-languages-bounces@alvestrand.no, Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , mmusic@ietf.org Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 15:07:08 -0000 Sorry for barging in late on this thread, but quick questions: - what's the right mailing list to post to on this one? - have everyone read RFC 3282 (the standalone "accept-language" spec)? Seems to me the desired semantic is more accept-language than content-language. On 03/10/2013 03:38 PM, Randall Gellens wrote: > Hi Everyone, > > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The > Tropicale (the cafe in the Caribe Royal hotel attached to the > convention center). Please let me know if you can make it so I can > make sure we have a large enough table. > > Thank you. > > >> Hi everyone, >> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >> who has responded so far. Let's plan on that for now. >> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >> >>> It looks like Thursday lunch would >>> work well. >>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>> Hi all, >>>> >>>> I created a Doodle poll to see if we can find a time in Orlando >>>> to meet >>>> face to face. >>>> >>>> Doodle poll for time at Orlando to discuss open issues and moving >>>> forward with Human Language Negotiation: >>>> http://doodle.com/uwedikez6etwsf39 >>>> >>>> Link to current version (-02) of draft: >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >>>> >>>> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> A child of five would understand this. Send somebody to >> fetch a child of five. --Groucho Marx, "Duck Soup" > > From emil@sip-communicator.org Sun Mar 10 09:55:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36421F8168 for ; Sun, 10 Mar 2013 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5akY10GvC092 for ; Sun, 10 Mar 2013 09:55:05 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5F21F8861 for ; Sun, 10 Mar 2013 09:55:03 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id un15so2899773pbc.10 for ; Sun, 10 Mar 2013 09:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uuoUG/pn6m29YCBGIs8LBOp4G6NmMsjSMCHjJbPiBvU=; b=dETCgWmN91ka8IZIhPw+y0roRjs/C0FgSjJ/w82nkvQUWVjRqC8DSUZkXZyHmfs9Og JGQGMGMSa3LgPRLLYj0nuMd+RV26NVQH8MsBe5Tn9o6yUsXQhIYoes3P01dzbSqqylri cClgHVqLWdv5AidJVyqaUF88EODAHmiGJNe1iGPo6L8QmBXVajk1MwP6icHjilWfjDD+ Netb2ApzShqvHshAXKVW76GEU4l1N5C5STFwx+rdU6m7P4S8dXwgeIuIrD0oPRk7cdPP /n1ltX6Q39mtwkvBqErqpdAUORpMGt8IVXJpNOY8azvOOnrNvcUFJOAowJPb2KWVbHwt boNA== X-Received: by 10.68.197.4 with SMTP id iq4mr21172705pbc.96.1362934503010; Sun, 10 Mar 2013 09:55:03 -0700 (PDT) Received: from camionet.local (dhcp-42f0.meeting.ietf.org. [130.129.66.240]) by mx.google.com with ESMTPS id wm3sm16156312pbc.4.2013.03.10.09.55.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 09:55:02 -0700 (PDT) Message-ID: <513CBAE3.6050208@jitsi.org> Date: Sun, 10 Mar 2013 12:54:59 -0400 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Flemming Andreasen References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> In-Reply-To: <5113C177.3000507@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn73FazVK5sYKiF43Wv5VbqAALbxHdAK2PptbCsL+uGInX+O07z9phzGbt1hxIOv9syPajh Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 16:55:08 -0000 Hey Flemming, We did have an intense discussion about parts of this message and in preparation for Tuesday, I thought it would be good to address the others. Sorry this took so long! Answers inline: On 07.02.13, 10:00, Flemming Andreasen wrote: > Hi > > I took a look the trickle-ice draft and have a couple of questions/comments: > > 1) Section 1 says > > This specification does not define usage of trickle ICE with any > specific signalling protocol, contrary to [RFC5245] which contains a > usage for ICE wht SIP. Such usages would have to be specified in > separate documents. > > however you do define it specifically using SDP and Offer/Answer (I > believe). It would be worthwhile calling that out. Well, the sentence immediately following your quotation does say: Trickle ICE does however reuse and build upon the SDP syntax defined by vanilla ICE. Doesn't this address your concern? > 2) Section 5.1 says > > As mentioned earlier in this section, Offers and Answers can contain > any set of candidates, which means that a trickle ICE session > description MAY contain no candidates at all. In such cases the > agent would still need to place an address in the "c=" line(s). If > the use of a host address there is undesirable (e.g. for privacy > reasons), the agent MAY set the connection address to 0.0.0.0. In > this case it MUST also set the port number to 1. There is no need to > include a fictitious 0.0.0.0 candidate when doing so. > > I had to read this several times before I (think) I understood that when > you say "the agent MAY set the connection address to 0.0.0.0", you are > referring to the connection address in the "a=candidate" attribute, not > the "c=" line. Can you clarify and rephrase accordingly. But we are indeed talking about the c= line. Could you please be a bit more explicit about the part you find confusing? > 3) Section 9.1 > I'm confused about this whole section and it's premise that > "a=candidate" attributes and media descriptions are not clearly linked. > The "a=candidate" attribute is defined as a media-level attribute only > and describes as such in RFC 5245, so I must be missing something here. This is about trickled candidates. We say that when sending them they should be encoded with the usual syntax: a=candidate:2 1 UDP 1658497328 198.51.100.33 5000 typ host Yet, this syntax does not provide a relation to an m-line. The draft says that this relation should happen through an MID (we agreed to ditch reliance on m-lines during the interim) but the exact syntax is left to the usages. > 4) Section 9.2. Rather than talking about sending "end of candidates" > via "the signalling channel" (which is not defined), could we change > this to say and "end of candidates" need to be sent to the peer, and the > only mechanism defined to do so in this document is through an O/A > exchange (new exchange or answer to an offer) ? To me this sounds confusing. As if we were saying: you can only send end-of-candidates in an offer or an answer, which is clearly not the case. In the general case end-of-candidates will be send through some non-O/A mechanism specific to the various signalling protocols. > 5) Section 14 (Example) > The exchange of the "additional candidates" does not use an O/A > exchange. Correct, it does not. > As for comment 4), this assumes some other un-defined > mechanism somewhere Right. Just as the entire transport of the trickled candidates. >- would it be useful to show it as an O/A exchange > as well, but note that other mechanisms may be defined ? Well the only way you could put end-of-candidates in an Offer or an Answer is if you are not planning on trickling any candidates after it. Using this for the example would kind of defeat its purpose. > 6) Section A.1 (MID/Stream Indicates in SDP) > I'm still unclear on this (per comment 3). Hopefully my comment made it clearer. Let me know if not. Cheers, Emil > > > Thanks > > -- Flemming (as Individual) > > > > On 1/30/13 11:38 AM, Emil Ivov wrote: >> Hey all, >> >> Justin, Eric and I have just submitted an update to the trickle ICE >> draft, accommodating comments from Atlanta: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >> >> More details about the changes here: >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B >> >> Diff2: >> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 >> >> During the MMUSIC presentation and the mailing list discussions it was >> also pointed out that it is important for this work to happen in >> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have >> therefore submitted the following document: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >> >> As always, comments are welcome! >> >> Cheers, >> Emil >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt >> Date: Mon, 28 Jan 2013 11:39:21 -0800 >> From: internet-drafts@ietf.org >> To: emcho@jitsi.org >> CC: justin@uberti.name, ekr@rtfm.com >> >> >> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >> has been successfully submitted by Emil Ivov and posted to the >> IETF repository. >> >> Filename: draft-ivov-mmusic-trickle-ice >> Revision: 00 >> Title: Trickle ICE: Incremental Provisioning of Candidates for the >> Interactive Connectivity Establishment (ICE) Protocol >> Creation date: 2013-01-28 >> WG ID: Individual Submission >> Number of pages: 20 >> URL: >> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >> Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >> >> >> Abstract: >> This document describes an extension to the Interactive Connectivity >> Establishment (ICE) protocol that allows ICE agents to send and >> receive candidates incrementally rather than exchanging complete >> lists. With such incremental provisioning, ICE agents can begin >> connectivity checks while they are still gathering candidates and >> considerably shorten the time necessary for ICE processing to >> complete. >> >> The above mechanism is also referred to as "trickle ICE". >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > -- https://jitsi.org From fandreas@cisco.com Sun Mar 10 10:44:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684621F8481 for ; Sun, 10 Mar 2013 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 Mynw6VHcTNqU for ; Sun, 10 Mar 2013 10:44:46 -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 6CE7A21F847B for ; Sun, 10 Mar 2013 10:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1515; q=dns/txt; s=iport; t=1362937486; x=1364147086; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xJY6NRHLs6E1MewX39233YX4souRq8qUeA/2fXOWRb0=; b=OGH1Vek5FwbP0NW08jV0hYyrq+pmiEY3I7u5hRju09Uls4xAbP6ijOGH bMIW/6JG2CJxxxZU/MY8OXbL2vxUQSA0Cb6y66l+zSu5OOcA8PmSoypak c/WImo+tp+P5WvzNC4Z5SK0ZpXTVvlz/x0AO+VwUhmV3g8j3jgDOIs3zX Q=; X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185872088" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 10 Mar 2013 17:44:46 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2AHiirn000386; Sun, 10 Mar 2013 17:44:45 GMT Message-ID: <513CC68C.6020904@cisco.com> Date: Sun, 10 Mar 2013 13:44:44 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Additional text for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 17:44:47 -0000 I gave you the wrong reference since RFC 3555 has been obsoloted by RFC 4855, which slightly updated the text as follows: Note that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case. Media subtype names are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute. I think it would be helpful to add the above to 4566bis (possibly with a clarification that "parameter names" in the above referts to parameters names inside fmtp only. Thanks -- Flemming On 3/6/13 11:11 PM, Ali C. Begen (abegen) wrote: > Section 3 of RFC 3555 states the following: > > Note that the payload format (encoding) names defined in the RTP > Profile are commonly shown in upper case. MIME subtypes are commonly > shown in lower case. These names are case-insensitive in both > places. Similarly, parameter names are case-insensitive both in MIME > types and in the default mapping to the SDP a=fmtp attribute. > > Flemming suggested that we also mentioned this rule in 4566bis so people won't need to look for anywhere else. Any objections? I think the best place to add this is Section 5.14. > > -acbegen > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From keith.drage@alcatel-lucent.com Sun Mar 10 11:17:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16821F86BB; Sun, 10 Mar 2013 11:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FxQJeF8m8kyw; Sun, 10 Mar 2013 11:17:06 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B06AC21F86A8; Sun, 10 Mar 2013 11:17:05 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2AIGo9N012105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 10 Mar 2013 19:16:50 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 10 Mar 2013 19:16:50 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 19:16:50 +0100 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , Randall Gellens Thread-Topic: [MMUSIC] Update on Orlando time for human language draft discussion Thread-Index: AQHOHaDpqzWJtGBhfEmBnpO9KnrKZ5ifOtHg Date: Sun, 10 Mar 2013 18:16:49 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> In-Reply-To: <513CA193.30304@alvestrand.no> 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.69 on 155.132.188.13 Cc: Ari Keranen , "ietf@ietf.org" , Peter Saint-Andre , Gunnar Hellstrom , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , "mmusic@ietf.org" Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 18:17:06 -0000 My understanding was that the idea was to label a particular media stream, = rather than (for example) a SIP body. Different media streams could have different labels. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 10 March 2013 15:07 > To: Randall Gellens > Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; DRAGE, > Keith (Keith); Peter Saint-Andre; ietf-languages-bounces@alvestrand.no; > Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter Saint-Andre= ; > Brian Rosen; mmusic@ietf.org > Subject: Re: [MMUSIC] Update on Orlando time for human language draft > discussion >=20 > Sorry for barging in late on this thread, but quick questions: >=20 > - what's the right mailing list to post to on this one? > - have everyone read RFC 3282 (the standalone "accept-language" spec)? >=20 > Seems to me the desired semantic is more accept-language than > content-language. >=20 >=20 > On 03/10/2013 03:38 PM, Randall Gellens wrote: > > Hi Everyone, > > > > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The > > Tropicale (the cafe in the Caribe Royal hotel attached to the > > convention center). Please let me know if you can make it so I can > > make sure we have a large enough table. > > > > Thank you. > > > > > >> Hi everyone, > >> > >> It looks like Thursday lunch (11:30-1:00) works well for everyone > >> who has responded so far. Let's plan on that for now. > >> > >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: > >> > >>> It looks like Thursday lunch would > >>> work well. > >>> > >>> On 3/5/13 4:47 AM, Randall Gellens wrote: > >>>> Hi all, > >>>> > >>>> I created a Doodle poll to see if we can find a time in Orlando > >>>> to meet > >>>> face to face. > >>>> > >>>> Doodle poll for time at Orlando to discuss open issues and moving > >>>> forward with Human Language Negotiation: > >>>> http://doodle.com/uwedikez6etwsf39 > >>>> > >>>> Link to current version (-02) of draft: > >>>> > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- > language-02.txt > >>>> > >>>> > >> > >> > >> -- > >> Randall Gellens > >> Opinions are personal; facts are suspect; I speak for myself > only > >> -------------- Randomly selected tag: --------------- > >> A child of five would understand this. Send somebody to > >> fetch a child of five. --Groucho Marx, "Duck Soup" > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Sun Mar 10 12:02:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76F21F8816 for ; Sun, 10 Mar 2013 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.142 X-Spam-Level: X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs2sC-BPlVcE for ; Sun, 10 Mar 2013 12:02:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6135621F8808 for ; Sun, 10 Mar 2013 12:02:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-6c-513cd8d72e0a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2E.F3.32353.7D8DC315; Sun, 10 Mar 2013 20:02:48 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 20:02:47 +0100 Message-ID: <513CD8D3.2060807@ericsson.com> Date: Sun, 10 Mar 2013 15:02:43 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3RvfGDZtAg6ZuHounjWcZLaYuf8zi wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKuPZjMWPCTreJv6xf2BsbLrF2MnBwSAiYS C/beZoewxSQu3FvP1sXIxSEkcJJR4v3mB0wQznJGifvbf7KAVPEKaEs8v7IarINFQFXizK63 bCA2m4CFxM0fjUA2B4eoQLDEzcVyEOWCEidnPgFrFRGwlnj1eAtYCbOAusTVxUEgprCApsSZ GZwgFUICERJb9y4AG8gpECkx++h3FojTJCW2vGgHW8osoCcx5WoLI4QtL9G8dTYzRK+2RENT B+sERqFZSBbPQtIyC0nLAkbmVYzsuYmZOenl5psYgWF6cMtvgx2Mm+6LHWKU5mBREucNd70Q ICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRxlu5l6uhapfVaRP+203id899E7zryvSXn5mn Qf/T/mPv8u98dpvGdu2TV/Hbf8rJd2f2PRFJPLu66Nu9+0de7Tr1eP/Gkwql0pG7LBr2sjm6 XJX6sUT6yMvqX0cZXqQ/Dj+39PUUrx8KTpyGT7kmdHOpTHhzj/VJ9uvlWstO8Tt0XNT0WvQq S4mlOCPRUIu5qDgRAETi8jUhAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Grouping discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 19:02:51 -0000 On 2013-03-10 10:30, DRAGE, Keith (Keith) wrote: > There is also planned to be an ad-hoc discussion of the grouping > material on Monday in the slot 15:40 to 17:10. If you are interested > in participating in this discussion please consult with either Bo > Burman, or one of the AVTEXT chairs, and we'll let you know which > room, when we find out ourselves. > This discussion will happen in Boca 8. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randy@qti.qualcomm.com Sun Mar 10 12:13:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0697121F86A8; Sun, 10 Mar 2013 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 zJyUaqpiX6ZH; Sun, 10 Mar 2013 12:13:00 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1663121F8629; Sun, 10 Mar 2013 12:13:00 -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=1362942780; x=1394478780; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=Av1TtmjHetppCdWTy77cMT45YrtZfSzA8LiTBnaCqKA=; b=cxCVm3CemY+WY4B8AsHzFArLODW6glYFg+bDI5vx78WlPwXKGQV1BgMl FI1A2pj5Lcvxf2VpHQ9C7QjMF20R+Ra+36IeDgl2ZPNwixROod+G1LS+q Ah/Ul4e6OsxVsgC6omP+NehcWcPxfzCOCSuRfft5vYL0gPwkDqQXEjTTI Q=; X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="29355640" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Mar 2013 12:12:59 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 12:12:58 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 12:12:58 -0700 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 12:08:14 -0800 To: "DRAGE, Keith (Keith)" , Harald Alvestrand , Randall Gellens 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.39.5] Cc: Ari Keranen , "ietf@ietf.org" , Peter Saint-Andre , Gunnar Hellstrom , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , "mmusic@ietf.org" Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 19:13:01 -0000 At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote: > My understanding was that the idea was to label a particular media > stream, rather than (for example) a SIP body. > > Different media streams could have different labels. Keith is right. As an example, SIP might be used to setup a call with an audio stream using English and a video stream using American Sign Language. SDP also allows other protocols besides SIP to be used to establish the session. > > -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Harald Alvestrand >> Sent: 10 March 2013 15:07 >> To: Randall Gellens >> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; DRAGE, >> Keith (Keith); Peter Saint-Andre; ietf-languages-bounces@alvestrand.no; >> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter Saint-Andre; >> Brian Rosen; mmusic@ietf.org >> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >> discussion >> >> Sorry for barging in late on this thread, but quick questions: >> >> - what's the right mailing list to post to on this one? >> - have everyone read RFC 3282 (the standalone "accept-language" spec)? >> >> Seems to me the desired semantic is more accept-language than >> content-language. >> >> >> On 03/10/2013 03:38 PM, Randall Gellens wrote: >> > Hi Everyone, >> > >> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >> > Tropicale (the cafe in the Caribe Royal hotel attached to the >> > convention center). Please let me know if you can make it so I can >> > make sure we have a large enough table. >> > >> > Thank you. >> > >> > >> >> Hi everyone, >> >> >> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >> >> who has responded so far. Let's plan on that for now. >> >> >> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >> >> >> >>> It looks like Thursday lunch would >> >>> work well. >> >>> >> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >> >>>> Hi all, >> >>>> >> >>>> I created a Doodle poll to see if we can find a time in Orlando >> >>>> to meet >> >>>> face to face. >> >>>> >> >>>> Doodle poll for time at Orlando to discuss open issues and moving >> >>>> forward with Human Language Negotiation: >> >>>> http://doodle.com/uwedikez6etwsf39 >> >>>> >> >>>> Link to current version (-02) of draft: >> >>>> >> >>>> >> >>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >> language-02.txt >> >>>> >> >>>> >> >> >> >> >> >> -- >> >> Randall Gellens >> >> Opinions are personal; facts are suspect; I speak for myself >> only >> >> -------------- Randomly selected tag: --------------- >> >> A child of five would understand this. Send somebody to >> >> fetch a child of five. --Groucho Marx, "Duck Soup" >> > >> > >> >> _______________________________________________ >> 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: --------------- I have opinions of my own -- strong opinions -- but I don't always agree with them. --George W. Bush, US President From harald@alvestrand.no Sun Mar 10 12:29:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475F721F8517; Sun, 10 Mar 2013 12:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.832 X-Spam-Level: X-Spam-Status: No, score=-110.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TXOEiR9FFw6; Sun, 10 Mar 2013 12:29:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 39AAD21F84AB; Sun, 10 Mar 2013 12:29:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F7E939E16F; Sun, 10 Mar 2013 20:29:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6W7MlWmY+n3; Sun, 10 Mar 2013 20:29:31 +0100 (CET) Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EC8A639E04C; Sun, 10 Mar 2013 20:29:27 +0100 (CET) Message-ID: <513CDF15.8070601@alvestrand.no> Date: Sun, 10 Mar 2013 20:29:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Randall Gellens References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "ietf@ietf.org" , Peter Saint-Andre , "DRAGE, Keith \(Keith\)" , Gunnar Hellstrom , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , "mmusic@ietf.org" Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 19:29:39 -0000 On 03/10/2013 09:08 PM, Randall Gellens wrote: > At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote: > >> My understanding was that the idea was to label a particular media >> stream, rather than (for example) a SIP body. >> >> Different media streams could have different labels. > > Keith is right. As an example, SIP might be used to setup a call with > an audio stream using English and a video stream using American Sign > Language. > > SDP also allows other protocols besides SIP to be used to establish > the session. OK, but that's not what I really was thinking about.... RFC 3282 (and its predecessors as part of the HTTP protocol) distinguished between two distinct fields: - "Here's what I'm willing to accept" - where prioritization is important - "Here's what I'm going to use" - where prioritization is not only unimportant, it's meaningless It might be good if whatever comes out of this discussion supports making that distinction. You may also want to think about how language tags interact with direction - if you're talking to an interpreter, where audio going one way is English and what comes back is in Spanish, are you able to mark the RTP session (if that's what you're marking, and not the media stream) as "sending English, receiving Spanish"? But this level of detail doesn't really belong on the IETF list - which list should we use? > > > >> > -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf >>> Of Harald Alvestrand >>> Sent: 10 March 2013 15:07 >>> To: Randall Gellens >>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; >>> DRAGE, >>> Keith (Keith); Peter Saint-Andre; >>> ietf-languages-bounces@alvestrand.no; >>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter >>> Saint-Andre; >>> Brian Rosen; mmusic@ietf.org >>> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >>> discussion >>> >>> Sorry for barging in late on this thread, but quick questions: >>> >>> - what's the right mailing list to post to on this one? >>> - have everyone read RFC 3282 (the standalone "accept-language" spec)? >>> >>> Seems to me the desired semantic is more accept-language than >>> content-language. >>> >>> >>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>> > Hi Everyone, >>> > >>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>> > convention center). Please let me know if you can make it so I can >>> > make sure we have a large enough table. >>> > >>> > Thank you. >>> > >>> > >>> >> Hi everyone, >>> >> >>> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >>> >> who has responded so far. Let's plan on that for now. >>> >> >>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>> >> >>> >>> It looks like Thursday lunch would >>> >>> work well. >>> >>> >>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>> >>>> Hi all, >>> >>>> >>> >>>> I created a Doodle poll to see if we can find a time in Orlando >>> >>>> to meet >>> >>>> face to face. >>> >>>> >>> >>>> Doodle poll for time at Orlando to discuss open issues and >>> moving >>> >>>> forward with Human Language Negotiation: >>> >>>> http://doodle.com/uwedikez6etwsf39 >>> >>>> >>> >>>> Link to current version (-02) of draft: >>> >>>> >>> >>>> >>> >>>> >>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>> language-02.txt >>> >>>> >>> >>>> >>> >> >>> >> >>> >> -- >>> >> Randall Gellens >>> >> Opinions are personal; facts are suspect; I speak for myself >>> only >>> >> -------------- Randomly selected tag: --------------- >>> >> A child of five would understand this. Send somebody to >>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>> > >>> > >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > > From gunnar.hellstrom@omnitor.se Sun Mar 10 13:27:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0716D11E80F9 for ; Sun, 10 Mar 2013 13:27: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=[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 mgIMe5Z1E1NV for ; Sun, 10 Mar 2013 13:27:39 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 37F2A11E80F8 for ; Sun, 10 Mar 2013 13:27:38 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 10 Mar 2013 21:27:28 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 57FCE3A181; Sun, 10 Mar 2013 21:27:28 +0100 (CET) Message-ID: <513CECB0.2010803@omnitor.se> Date: Sun, 10 Mar 2013 21:27:28 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Harald Alvestrand References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> In-Reply-To: <513CDF15.8070601@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Alexey Melnikov , Brian Rosen , Randall Gellens Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 20:27:41 -0000 On 2013-03-10 20:29, Harald Alvestrand wrote: > On 03/10/2013 09:08 PM, Randall Gellens wrote: >> At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote: >> >>> My understanding was that the idea was to label a particular media >>> stream, rather than (for example) a SIP body. >>> >>> Different media streams could have different labels. >> >> Keith is right. As an example, SIP might be used to setup a call >> with an audio stream using English and a video stream using American >> Sign Language. >> >> SDP also allows other protocols besides SIP to be used to establish >> the session. > > OK, but that's not what I really was thinking about.... > > RFC 3282 (and its predecessors as part of the HTTP protocol) > distinguished between two distinct fields: > > - "Here's what I'm willing to accept" - where prioritization is important > - "Here's what I'm going to use" - where prioritization is not only > unimportant, it's meaningless > > It might be good if whatever comes out of this discussion supports > making that distinction. > > You may also want to think about how language tags interact with > direction - if you're talking to an interpreter, where audio going one > way is English and what comes back is in Spanish, are you able to mark > the RTP session (if that's what you're marking, and not the media > stream) as "sending English, receiving Spanish"? > > But this level of detail doesn't really belong on the IETF list - > which list should we use? Yes, it will be a balance between complexity and usefulness. Too little complexity - not sufficient to express the common cases. Too much complexity - No one will bother registering their profile. I see a need to declare and negotiate need, preference and capability to use different languages and modalities, and the declaration need to be directional. Imagined example: I prefer to talk English, and I have some capability to talk French I Prefer to talk, but I am capable of typing I Need to get text in English or French I have some benefit of getting spoken English or French, but I cannot accept that as the only channel for language perception. If I want to have a conversation with someone who only has an audio terminal, and can talk and understand spoken French, an evaluation of our needs would insert a captioned telephony service in French in the call typing a French transcription of the spoken French my callee talks to me. Gunnar > >> >> >> >>> > -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf >>>> Of Harald Alvestrand >>>> Sent: 10 March 2013 15:07 >>>> To: Randall Gellens >>>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; >>>> DRAGE, >>>> Keith (Keith); Peter Saint-Andre; >>>> ietf-languages-bounces@alvestrand.no; >>>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter >>>> Saint-Andre; >>>> Brian Rosen; mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >>>> discussion >>>> >>>> Sorry for barging in late on this thread, but quick questions: >>>> >>>> - what's the right mailing list to post to on this one? >>>> - have everyone read RFC 3282 (the standalone "accept-language" >>>> spec)? >>>> >>>> Seems to me the desired semantic is more accept-language than >>>> content-language. >>>> >>>> >>>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>>> > Hi Everyone, >>>> > >>>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >>>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>>> > convention center). Please let me know if you can make it so I can >>>> > make sure we have a large enough table. >>>> > >>>> > Thank you. >>>> > >>>> > >>>> >> Hi everyone, >>>> >> >>>> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >>>> >> who has responded so far. Let's plan on that for now. >>>> >> >>>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>>> >> >>>> >>> It looks like Thursday lunch would >>>> >>> work well. >>>> >>> >>>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I created a Doodle poll to see if we can find a time in >>>> Orlando >>>> >>>> to meet >>>> >>>> face to face. >>>> >>>> >>>> >>>> Doodle poll for time at Orlando to discuss open issues and >>>> moving >>>> >>>> forward with Human Language Negotiation: >>>> >>>> http://doodle.com/uwedikez6etwsf39 >>>> >>>> >>>> >>>> Link to current version (-02) of draft: >>>> >>>> >>>> >>>> >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>>> language-02.txt >>>> >>>> >>>> >>>> >>>> >> >>>> >> >>>> >> -- >>>> >> Randall Gellens >>>> >> Opinions are personal; facts are suspect; I speak for >>>> myself >>>> only >>>> >> -------------- Randomly selected tag: --------------- >>>> >> A child of five would understand this. Send somebody to >>>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From randy@qti.qualcomm.com Sun Mar 10 14:08:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7C21F8808 for ; Sun, 10 Mar 2013 14:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 GddtX9I3gbxL for ; Sun, 10 Mar 2013 14:08:36 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6521F87BB for ; Sun, 10 Mar 2013 14:08:36 -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=1362949716; x=1394485716; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=kWcybfXkevdnpHk19/idyD3AP1BegF5TpdfqyhvS+c0=; b=jND5SZdPHVQMFx74nc53ogpy53LfVkh6dk+2YCDH+lHn/LM9AyBFRSzJ geCihkQzrmdTiZB7Nrmx6PE3Iy8OMKKP8u/TNO3DN+xMhrcVJwoSFTqVx JltRLuTyGieTU/Rt+afOVvKh/8NC18FUQqB1SvzronGP6K5K78HNxwDZq 4=; X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="29360970" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 10 Mar 2013 14:08:35 -0700 X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="503145822" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 14:08:35 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 14:08:34 -0700 Message-ID: In-Reply-To: <513CECB0.2010803@omnitor.se> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 14:02:54 -0800 To: Gunnar Hellstrom , Harald Alvestrand 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.39.5] Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Alexey Melnikov , Brian Rosen , Randall Gellens Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 21:08:37 -0000 At 9:27 PM +0100 3/10/13, Gunnar Hellstrom wrote: > On 2013-03-10 20:29, Harald Alvestrand wrote: >> On 03/10/2013 09:08 PM, Randall Gellens wrote: >>> At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote: >>> >>>> My understanding was that the idea was to label a particular >>>> media stream, rather than (for example) a SIP body. >>>> >>>> Different media streams could have different labels. >>> >>> Keith is right. As an example, SIP might be used to setup a call >>> with an audio stream using English and a video stream using >>> American Sign Language. >>> >>> SDP also allows other protocols besides SIP to be used to >>> establish the session. >> >> OK, but that's not what I really was thinking about.... >> >> RFC 3282 (and its predecessors as part of the HTTP protocol) >> distinguished between two distinct fields: >> >> - "Here's what I'm willing to accept" - where prioritization is important >> - "Here's what I'm going to use" - where prioritization is not >> only unimportant, it's meaningless >> >> It might be good if whatever comes out of this discussion supports >> making that distinction. >> >> You may also want to think about how language tags interact with >> direction - if you're talking to an interpreter, where audio going >> one way is English and what comes back is in Spanish, are you able >> to mark the RTP session (if that's what you're marking, and not >> the media stream) as "sending English, receiving Spanish"? >> >> But this level of detail doesn't really belong on the IETF list - >> which list should we use? > > Yes, it will be a balance between complexity and usefulness. > Too little complexity - not sufficient to express the common cases. > Too much complexity - No one will bother registering their profile. > > I see a need to declare and negotiate need, preference and > capability to use different languages and modalities, and the > declaration need to be directional. > > Imagined example: > I prefer to talk English, and I have some capability to talk French > I Prefer to talk, but I am capable of typing > I Need to get text in English or French > I have some benefit of getting spoken English or French, but I > cannot accept that as the only channel for language perception. > > If I want to have a conversation with someone who only has an audio > terminal, and can talk and understand spoken French, an evaluation > of our needs would insert a captioned telephony service in French > in the call typing a French transcription of the spoken French my > callee talks to me. If possible, I think it may be better to keep service negotiation distinct from language negotiation. Otherwise things get very complex. >>> >>>> > -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>>>> Of Harald Alvestrand >>>>> Sent: 10 March 2013 15:07 >>>>> To: Randall Gellens >>>>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar >>>>> Hellstrom; DRAGE, >>>>> Keith (Keith); Peter Saint-Andre; ietf-languages-bounces@alvestrand.no; >>>>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter >>>>> Saint-Andre; >>>>> Brian Rosen; mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >>>>> discussion >>>>> >>>>> Sorry for barging in late on this thread, but quick questions: >>>>> >>>>> - what's the right mailing list to post to on this one? >>>>> - have everyone read RFC 3282 (the standalone "accept-language" spec)? >>>>> >>>>> Seems to me the desired semantic is more accept-language than >>>>> content-language. >>>>> >>>>> >>>>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>>>> > Hi Everyone, >>>>> > >>>>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >>>>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>>>> > convention center). Please let me know if you can make it so I can >>>>> > make sure we have a large enough table. >>>>> > >>>>> > Thank you. >>>>> > >>>>> > >>>>> >> Hi everyone, >>>>> >> >>>>> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >>>>> >> who has responded so far. Let's plan on that for now. >>>>> >> >>>>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>>>> >> >>>>> >>> It looks like Thursday lunch would >>>>> >>> work well. >>>>> >>> >>>>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>>> >>>> Hi all, >>>>> >>>> >>>>> >>>> I created a Doodle poll to see if we can find a time in Orlando >>>>> >>>> to meet >>>>> >>>> face to face. >>>>> >>>> >>>>> >>>> Doodle poll for time at Orlando to discuss open issues and moving >>>>> >>>> forward with Human Language Negotiation: >>>>> >>>> http://doodle.com/uwedikez6etwsf39 >>>>> >>>> >>>>> >>>> Link to current version (-02) of draft: >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>>>> language-02.txt >>>>> >>>> >>>>> >>>> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Randall Gellens >>>>> >> Opinions are personal; facts are suspect; I speak for myself >>>>> only >>>>> >> -------------- Randomly selected tag: --------------- >>>>> >> A child of five would understand this. Send somebody to >>>>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>>>> > >>>>> > >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The goal of mechanical engineering is to build better mousetraps. The goal of genetic engineering is to build better mice. From randy@qti.qualcomm.com Sun Mar 10 14:08:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81A21F8846; Sun, 10 Mar 2013 14:08:44 -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 ErDXfjMDkfNa; Sun, 10 Mar 2013 14:08:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6E60421F8855; Sun, 10 Mar 2013 14:08:43 -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=1362949723; x=1394485723; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=U/0dNvYo4u9KjMiHaUsJUpjDaUX/1GKU6a4mmvWYW1s=; b=B+WF3i/dyF0QqnTKmz3gWqTvZD5AGXbqdmxeSBi3s9bA9T1FYr0zAMMG p1GwvAvI4BqqwVG7i/FxQHpg7+czKtqwb5AIhHUg5ZE3SHDy/f4MKgBAk PckjjapRnfisgWXDLRsiNpIpeDh8J0+3ezeKZBawFMsc47Mgp5obyGxS1 Q=; X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="28281317" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2013 14:08:34 -0700 X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="449409985" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 14:08:34 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 14:08:33 -0700 Message-ID: In-Reply-To: <513CDF15.8070601@alvestrand.no> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 14:00:06 -0800 To: Harald Alvestrand 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.39.5] Cc: Ari Keranen , "ietf@ietf.org" , Peter Saint-Andre , "DRAGE, Keith \(Keith\)" , Gunnar Hellstrom , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , Randall Gellens , "mmusic@ietf.org" Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 21:08:44 -0000 At 8:29 PM +0100 3/10/13, Harald Alvestrand wrote: > On 03/10/2013 09:08 PM, Randall Gellens wrote: >> At 6:16 PM +0000 3/10/13, Keith (Keith) DRAGE wrote: >> >>> My understanding was that the idea was to label a particular >>> media stream, rather than (for example) a SIP body. >>> >>> Different media streams could have different labels. >> >> Keith is right. As an example, SIP might be used to setup a call >> with an audio stream using English and a video stream using >> American Sign Language. >> >> SDP also allows other protocols besides SIP to be used to >> establish the session. > > OK, but that's not what I really was thinking about.... > > RFC 3282 (and its predecessors as part of the HTTP protocol) > distinguished between two distinct fields: > > - "Here's what I'm willing to accept" - where prioritization is important > - "Here's what I'm going to use" - where prioritization is not only > unimportant, it's meaningless > > It might be good if whatever comes out of this discussion supports > making that distinction. Do you think that the proposal in the draft now does not do so? It proposes using an SDP media attribute in the offer/answer to negotiate language (i.e., offer includes prioritized languages and answer has the highest priority language supported by the other end). > > You may also want to think about how language tags interact with > direction - if you're talking to an interpreter, where audio going > one way is English and what comes back is in Spanish, are you able > to mark the RTP session (if that's what you're marking, and not the > media stream) as "sending English, receiving Spanish"? The proposal in the draft is that this be media level, not session level (in part because different media may use different languages, e.g., spoken and signed). > > But this level of detail doesn't really belong on the IETF list - > which list should we use? I suppose the mmusic list, since the proposal uses SDP. >> >>> > -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>>> Of Harald Alvestrand >>>> Sent: 10 March 2013 15:07 >>>> To: Randall Gellens >>>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; DRAGE, >>>> Keith (Keith); Peter Saint-Andre; ietf-languages-bounces@alvestrand.no; >>>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter >>>> Saint-Andre; >>>> Brian Rosen; mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >>>> discussion >>>> >>>> Sorry for barging in late on this thread, but quick questions: >>>> >>>> - what's the right mailing list to post to on this one? >>>> - have everyone read RFC 3282 (the standalone "accept-language" spec)? >>>> >>>> Seems to me the desired semantic is more accept-language than >>>> content-language. >>>> >>>> >>>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>>> > Hi Everyone, >>>> > >>>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >>>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>>> > convention center). Please let me know if you can make it so I can >>>> > make sure we have a large enough table. >>>> > >>>> > Thank you. >>>> > >>>> > >>>> >> Hi everyone, >>>> >> >>>> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >>>> >> who has responded so far. Let's plan on that for now. >>>> >> >>>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>>> >> >>>> >>> It looks like Thursday lunch would >>>> >>> work well. >>>> >>> >>>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I created a Doodle poll to see if we can find a time in Orlando >>>> >>>> to meet >>>> >>>> face to face. >>>> >>>> >>>> >>>> Doodle poll for time at Orlando to discuss open issues and moving >>>> >>>> forward with Human Language Negotiation: >>>> >>>> http://doodle.com/uwedikez6etwsf39 >>>> >>>> >>>> >>>> Link to current version (-02) of draft: >>>> >>>> >>>> >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>>> language-02.txt >>>> >>>> >>>> >>>> >>>> >> >>>> >> >>>> >> -- >>>> >> Randall Gellens >>>> >> Opinions are personal; facts are suspect; I speak for myself >>>> only >>>> >> -------------- Randomly selected tag: --------------- >>>> >> A child of five would understand this. Send somebody to >>>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> 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: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline From gunnar.hellstrom@omnitor.se Sun Mar 10 14:32:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009B421F869A for ; Sun, 10 Mar 2013 14:32:00 -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 TpofgbpZBoGv for ; Sun, 10 Mar 2013 14:31:58 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id DED8421F868F for ; Sun, 10 Mar 2013 14:31:57 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 10 Mar 2013 22:31:49 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 2B4283A164; Sun, 10 Mar 2013 22:31:49 +0100 (CET) Message-ID: <513CFBC5.6060209@omnitor.se> Date: Sun, 10 Mar 2013 22:31:49 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Randall Gellens References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 21:32:00 -0000 On 2013-03-10 23:02, Randall Gellens wrote: > At 9:27 PM +0100 3/10/13, Gunnar Hellstrom wrote: >> Yes, it will be a balance between complexity and usefulness. >> Too little complexity - not sufficient to express the common cases. >> Too much complexity - No one will bother registering their profile. >> >> I see a need to declare and negotiate need, preference and >> capability to use different languages and modalities, and the >> declaration need to be directional. >> >> Imagined example: >> I prefer to talk English, and I have some capability to talk French >> I Prefer to talk, but I am capable of typing >> I Need to get text in English or French >> I have some benefit of getting spoken English or French, but I >> cannot accept that as the only channel for language perception. >> >> If I want to have a conversation with someone who only has an audio >> terminal, and can talk and understand spoken French, an evaluation of >> our needs would insert a captioned telephony service in French in the >> call typing a French transcription of the spoken French my callee >> talks to me. > > If possible, I think it may be better to keep service negotiation > distinct from language negotiation. Otherwise things get very complex. > That was just a use case. Do you mean that we should divide it like this: Imagined example in a call from A to B. A prefer to talk English, and A has some capability to talk French A Prefers to talk, but A is capable of typing A Needs to get text in English or French A has some benefit of getting spoken English or French, but A cannot accept that as the only channel for language perception. A wants to have a conversation with B who declares only an ability to talk and understand spoken French. An evaluation of the needs, preferences and capabilities of A and B would result in that the call is not possible because we have common capabilities only in the direction from A to the B. In the return path, from B to A, the only option it to receive spoken French from the B, while A is depending on getting written English or Written French. ----- This information an then be used in a separate service request for getting a service C that adds rapid conversion of spoken French to typed French in the path from A to B, still letting the spoken French also pass over to A. Gunnar > >>>> >>>>> > -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>> On Behalf >>>>>> Of Harald Alvestrand >>>>>> Sent: 10 March 2013 15:07 >>>>>> To: Randall Gellens >>>>>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar >>>>>> Hellstrom; DRAGE, >>>>>> Keith (Keith); Peter Saint-Andre; >>>>>> ietf-languages-bounces@alvestrand.no; >>>>>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter >>>>>> Saint-Andre; >>>>>> Brian Rosen; mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] Update on Orlando time for human language >>>>>> draft >>>>>> discussion >>>>>> >>>>>> Sorry for barging in late on this thread, but quick questions: >>>>>> >>>>>> - what's the right mailing list to post to on this one? >>>>>> - have everyone read RFC 3282 (the standalone "accept-language" >>>>>> spec)? >>>>>> >>>>>> Seems to me the desired semantic is more accept-language than >>>>>> content-language. >>>>>> >>>>>> >>>>>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>>>>> > Hi Everyone, >>>>>> > >>>>>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation >>>>>> at The >>>>>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>>>>> > convention center). Please let me know if you can make it so >>>>>> I can >>>>>> > make sure we have a large enough table. >>>>>> > >>>>>> > Thank you. >>>>>> > >>>>>> > >>>>>> >> Hi everyone, >>>>>> >> >>>>>> >> It looks like Thursday lunch (11:30-1:00) works well for >>>>>> everyone >>>>>> >> who has responded so far. Let's plan on that for now. >>>>>> >> >>>>>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>>>>> >> >>>>>> >>> It looks like Thursday lunch would >>>>>> >>> work well. >>>>>> >>> >>>>>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>>>> >>>> Hi all, >>>>>> >>>> >>>>>> >>>> I created a Doodle poll to see if we can find a time in >>>>>> Orlando >>>>>> >>>> to meet >>>>>> >>>> face to face. >>>>>> >>>> >>>>>> >>>> Doodle poll for time at Orlando to discuss open issues >>>>>> and moving >>>>>> >>>> forward with Human Language Negotiation: >>>>>> >>>> http://doodle.com/uwedikez6etwsf39 >>>>>> >>>> >>>>>> >>>> Link to current version (-02) of draft: >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>>>>> language-02.txt >>>>>> >>>> >>>>>> >>>> >>>>>> >> >>>>>> >> >>>>>> >> -- >>>>>> >> Randall Gellens >>>>>> >> Opinions are personal; facts are suspect; I speak for >>>>>> myself >>>>>> only >>>>>> >> -------------- Randomly selected tag: --------------- >>>>>> >> A child of five would understand this. Send somebody to >>>>>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>>>>> > >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > > From randy@qti.qualcomm.com Sun Mar 10 15:41:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C121F86F7 for ; Sun, 10 Mar 2013 15:41:11 -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 dRew6HQ6dOV0 for ; Sun, 10 Mar 2013 15:41:10 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0614F21F8651 for ; Sun, 10 Mar 2013 15:41:09 -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=1362955270; x=1394491270; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=SEwBogXpWVVA+ZzrOcz49w+Uk+7BJVCxPacgq7IuOw0=; b=qemHwjRTF9qib7g+0pZV6WuaaeZVRBo3LC8gFjQ4nMLrvpO2bSRQ4hiY LGPLOX4nntxe1YoDl5VuaKKgJhxctNSNnd2FfO5smBubWpk7A7wLoX361 Jtogta0d5rcXaUzedd0cNRO1q/2A+jgSswqpiVBCTA1vIhzHBBrB7bDW9 c=; X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="28287729" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2013 15:41:09 -0700 X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="440444862" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2013 15:41:09 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 10 Mar 2013 15:41:07 -0700 Message-ID: In-Reply-To: <513CFBC5.6060209@omnitor.se> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> <513CFBC5.6060209@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 10 Mar 2013 15:30:30 -0800 To: Gunnar Hellstrom 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.39.5] Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , Randall Gellens Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:41:11 -0000 At 10:31 PM +0100 3/10/13, Gunnar Hellstrom wrote: > On 2013-03-10 23:02, Randall Gellens wrote: >> At 9:27 PM +0100 3/10/13, Gunnar Hellstrom wrote: >>> Yes, it will be a balance between complexity and usefulness. >>> Too little complexity - not sufficient to express the common cases. >>> Too much complexity - No one will bother registering their profile. >>> >>> I see a need to declare and negotiate need, preference and >>> capability to use different languages and modalities, and the >>> declaration need to be directional. >>> >>> Imagined example: >>> I prefer to talk English, and I have some capability to talk French >>> I Prefer to talk, but I am capable of typing >>> I Need to get text in English or French >>> I have some benefit of getting spoken English or French, but I >>> cannot accept that as the only channel for language perception. >>> >>> If I want to have a conversation with someone who only has an >>> audio terminal, and can talk and understand spoken French, an >>> evaluation of our needs would insert a captioned telephony >>> service in French in the call typing a French transcription of >>> the spoken French my callee talks to me. >> >> If possible, I think it may be better to keep service negotiation >> distinct from language negotiation. Otherwise things get very >> complex. >> > That was just a use case. > > Do you mean that we should divide it like this: > > Imagined example in a call from A to B. > A prefer to talk English, and A has some capability to talk French > A Prefers to talk, but A is capable of typing > A Needs to get text in English or French > A has some benefit of getting spoken English or French, but A > cannot accept that as the only channel for language perception. > > A wants to have a conversation with B who declares only an ability > to talk and understand spoken French. > > An evaluation of the needs, preferences and capabilities of A and B > would result in that the call is not possible because we have > common capabilities only in the direction from A to the B. > In the return path, from B to A, the only option it to receive > spoken French from the B, while A is depending on getting written > English or Written French. > > ----- > > This information an then be used in a separate service request for > getting a service C that adds rapid conversion of spoken French to > typed French in the path from A to B, still letting the spoken > French also pass over to A. It's very easy to add complexity in order to solve more aspects of the problem. I think we need to work very hard to keep this mechanism, at least initially, very simple. >>>>> >>>>>> > -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org >>>>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>>>>> Of Harald Alvestrand >>>>>>> Sent: 10 March 2013 15:07 >>>>>>> To: Randall Gellens >>>>>>> Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar >>>>>>> Hellstrom; DRAGE, >>>>>>> Keith (Keith); Peter Saint-Andre; >>>>>>> ietf-languages-bounces@alvestrand.no; >>>>>>> Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; >>>>>>> Peter Saint-Andre; >>>>>>> Brian Rosen; mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Update on Orlando time for human language draft >>>>>>> discussion >>>>>>> >>>>>>> Sorry for barging in late on this thread, but quick questions: >>>>>>> >>>>>>> - what's the right mailing list to post to on this one? >>>>>>> - have everyone read RFC 3282 (the standalone >>>>>>> "accept-language" spec)? >>>>>>> >>>>>>> Seems to me the desired semantic is more accept-language than >>>>>>> content-language. >>>>>>> >>>>>>> >>>>>>> On 03/10/2013 03:38 PM, Randall Gellens wrote: >>>>>>> > Hi Everyone, >>>>>>> > >>>>>>> > Thursday lunch (11:30-1:00) it is. I'll make a reservation at The >>>>>>> > Tropicale (the cafe in the Caribe Royal hotel attached to the >>>>>>> > convention center). Please let me know if you can make it so I can >>>>>>> > make sure we have a large enough table. >>>>>>> > >>>>>>> > Thank you. >>>>>>> > >>>>>>> > >>>>>>> >> Hi everyone, >>>>>>> >> >>>>>>> >> It looks like Thursday lunch (11:30-1:00) works well for everyone >>>>>>> >> who has responded so far. Let's plan on that for now. >>>>>>> >> >>>>>>> >> At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: >>>>>>> >> >>>>>>> >>> It looks like Thursday lunch would >>>>>>> >>> work well. >>>>>>> >>> >>>>>>> >>> On 3/5/13 4:47 AM, Randall Gellens wrote: >>>>>>> >>>> Hi all, >>>>>>> >>>> >>>>>>> >>>> I created a Doodle poll to see if we can find a time >>>>>>> in Orlando >>>>>>> >>>> to meet >>>>>>> >>>> face to face. >>>>>>> >>>> >>>>>>> >>>> Doodle poll for time at Orlando to discuss open >>>>>>> issues and moving >>>>>>> >>>> forward with Human Language Negotiation: >>>>>>> >>>> http://doodle.com/uwedikez6etwsf39 >>>>>>> >>>> >>>>>>> >>>> Link to current version (-02) of draft: >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- >>>>>>> language-02.txt >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Randall Gellens >>>>>>> >> Opinions are personal; facts are suspect; I speak >>>>>>> for myself >>>>>>> only >>>>>>> >> -------------- Randomly selected tag: --------------- >>>>>>> >> A child of five would understand this. Send somebody to >>>>>>> >> fetch a child of five. --Groucho Marx, "Duck Soup" >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is always an easy solution to every human problem -- neat, plausible, and wrong. --H.L. Mencken From pkyzivat@alum.mit.edu Sun Mar 10 18:30:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDA021F8763 for ; Sun, 10 Mar 2013 18:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.563 X-Spam-Level: ** X-Spam-Status: No, score=2.563 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 mfYjcPAFlqrU for ; Sun, 10 Mar 2013 18:30:01 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id D068421F85FE for ; Sun, 10 Mar 2013 18:30:01 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 9xgs1l0070x6nqcA11W1y5; Mon, 11 Mar 2013 01:30:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:1d9f:4522:3569:ca14]) by omta12.emeryville.ca.mail.comcast.net with comcast id A1W01l00Q4B9e0B8Y1W0Xk; Mon, 11 Mar 2013 01:30:01 +0000 Message-ID: <513D33A8.5090101@alum.mit.edu> Date: Mon, 11 Mar 2013 09:30:16 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> 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=1362965401; bh=E3qMDm8Y0TqeVcAf6yvtt/p1NFaB/uUIkYQJeuj0IXM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=go9FRF7A6AKzxfthqGZRpXf1yUHyzgz8WvGPnw7mbMy1mFCJ3LpN4uMcxbJj2xO0k ptYu6vvLMJl+FG3zu0MWpYzVFo5/Xl5yl/GfW6jQzIO43m2P29VexAkesVr1pflV0S nWiii3wVGxqFjWgX5MCzUf06U4toWrBJdCtRw8A8e9sj0C4kp9jkpL+fgsFxcnuD+H dcSLDANM1ML5PwkgWizML3A7ivXQ9WzwMV2HV78tkMFihKBQWr6ooLfBUQHtvHuN6Z aWccwT3YFjbbKvM4g9K5WyVhT2kdYXX+XEYkotX9KD7I1Fvd3Fc3ewMBlimRQlJVDl RExzVJQJUEiTA== Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 01:30:02 -0000 On 3/10/13 4:43 PM, Ali C. Begen (abegen) wrote: >> For instance, in the >> example below, each media behaves as if it were given a >> "recvonly" attribute. >> >> An example SDP description is: >> >> v=0 >> o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 >> s=SDP Seminar >> i=A Seminar on the session description protocol >> u=http://www.example.com/seminars/sdp.pdf >> e=j.doe@example.com (Jane Doe) >> c=IN IP4 233.252.0.1/127 >> t=2873397496 2873404696 >> a=recvonly >> m=audio 49170 RTP/AVP 0 >> m=video 51372 RTP/AVP 99 >> a=rtpmap:99 h263-1998/90000 >> a=recvonly >> > > Is not the last/second "recvonly" redundant? Yes it is, though it shows the use of session and media level. It would probably be better to give a slightly more complex example. For instance, make the media level attribute for video be sendonly, and then explain that the result is audio recvonly and video sendonly. Thanks, Paul From worley@shell01.TheWorld.com Sun Mar 10 19:38:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0917411E80EF for ; Sun, 10 Mar 2013 19:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 QBAZYt7Xgfov for ; Sun, 10 Mar 2013 19:38:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id AB8FB11E80EA for ; Sun, 10 Mar 2013 19:38:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2B2btWo023512 for ; Sun, 10 Mar 2013 22:37:58 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2B2bt4r180460 for ; Sun, 10 Mar 2013 21:37:55 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2B2btIS180463; Sun, 10 Mar 2013 22:37:55 -0400 (EDT) Date: Sun, 10 Mar 2013 22:37:55 -0400 (EDT) Message-Id: <201303110237.r2B2btIS180463@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 02:38:04 -0000 I believe that the current SDP grouping framework (RFC 5888) causes a problem for the offer/answer operations of SDP bundling, and we need to reconsider using SDP grouping, or alter the rules for SDP grouping. Most of the bundling proposals have "constituent" media descriptions, that is, m= lines that describe only components of the bundle, not the bundle as a whole. (In some proposals, these MDs are called "subsequent" MDs, because the first MD in the bundle is used to describe the bundle as a whole. In other proposals, there is a separate MD for the bundle as a whole, and all of the components of the bundle are "constituent" MDs.) Generally, a constituent MD is offered like this: c=10.1.1.1 a=group:BUNDLE bundle con1 con2 ... m=audio 10002 RTP/AVP 0 8 a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 The MD is declared to be part of a bundle by a "group" attribute, and the MD provides a transport address and port. For backward compatibility with answerers that do not support bundling, most proposals require that the address and port of the MD are a real transport address of the offerer. If the answerer wishes the reject the constituent MD, it responds like this: c=10.1.1.1 a=group:BUNDLE bundle con2 ... m=audio 0 RTP/AVP 0 8 a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 (If the answerer does not support bundling at all, it removes the group attribute. But if it supports bundling, it may want to accept other parts of the bundle and yet reject this MD, so it will include the group attribute for the bundle.) The port number is zero. Due to RFC 5888 section 9.2, the mid of this MD MUST be removed from the group attribute describing this bundle. That fact isn't interesting here, but it will become more important later in this discussion. If the answerer wishes to accept the constituent MD not as part of the bundle (perhaps because the answerer does not support bundling), it responds like this: c=10.1.1.1 m=audio 20002 RTP/AVP 0 8 a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 The group attribute is omitted (showing that the bundle is not accepted) and a transport address of the answerer is provided. Note that both of these answer patterns are determined by "legacy" SDP processing rules, and we are not free to change them. If the answerer wishes to accept the constituent MD as part of the bundle, how should it respond? The natural method is something like this: c=10.1.1.1 a=group:BUNDLE bundle con1 con2 ... m=audio 0 RTP/AVP 0 8 a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 We want to include the constituent MD in the group attribute, in order to show that it is part of the bundle. However, we want to answer with a zero port number so that intermediate entities will not be expecting media on this transport association. If an intermediate entity believes that a valid transport association has been established, the entity may time out the multimedia session when it does not see media. (It does not suffice for the answerer to provide a null transport address and non-zero port for the MD, or for the answerer to send "a=inactive", as an intermediate entity may see the MD as being accepted and expect the offerer to send RTCP.) But if the m= line has a zero port number, RFC 5888 section 9.2 requires that the MD's mid label not be included in the group attribute. This prevents the answerer from signaling that the MD has been accepted, but that the media is sent within the bundle, not on a separate transport association. Seven of the nine proposals cataloged in draft-worley-sdp-bundle-05 section 7 have this problem. Currently, only way to avoid this problem is the answerer provides a non-zero port with a null transport address, and then the offerer provides an immediate SDP update that provides a non-zero port with a null transport address. After that, intermediate entities will be warned that they might not see media on the transport association (as both endpoints seem to be managing third-party entities). But a better solution is to allow the answerer to accept the constituent MD as part of the bundle, while at the same time giving a zero port, thus rejecting the constituent MD from a "legacy" point of view. Signaling the acceptance within the bundle is easy enough; we can define a new attribute for doing so: c=10.1.1.1 a=group:BUNDLE bundle con1 con2 ... m=audio 0 RTP/AVP 0 8 a=bundle-accept a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 The difficulty is how to indicate that the MD is part of the bundle. There are at least four choices: 1. The membership of the MD in the bundle is not signaled in the answer; it is implied by the signaling in the offer. c=10.1.1.1 m=audio 0 RTP/AVP 0 8 a=bundle-accept a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 2. We define a new grouping attribute for signaling bundling, one which does not have the restriction that MDs with zero port numbers may not appear in the group. c=10.1.1.1 a=relaxed-group:BUNDLE bundle con1 con2 ... m=audio 0 RTP/AVP 0 8 a=bundle-accept a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 3. We define an attribute for signaling bundle membership in some other way. E.g., a pointer from the constituent MD to the bundle MD: c=10.1.1.1 m=audio 0 RTP/AVP 0 8 a=bundle-owner:bundle a=bundle-accept a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 where the bundle MD is: m=audio 15000 RTP/AVP 0 8 a=mid:bundle 4. We normatively relax RFC 5888 section 9.2 to allow MDs with zero port numbers to appear in group attributes. (This would only have meaning for BUNDLE groups, not LS and FID groups.) c=10.1.1.1 a=group:BUNDLE bundle con1 con2 ... m=audio 0 RTP/AVP 0 8 a=bundle-accept a=mid:con1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 At this point, I prefer the fourth choice, updating RFC 5888. Would this likely cause any backward compatibility problems? Dale From abegen@cisco.com Sun Mar 10 20:32:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703E521F89C7 for ; Sun, 10 Mar 2013 20:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.687 X-Spam-Level: X-Spam-Status: No, score=-8.687 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 TvrDEYrIqz+t for ; Sun, 10 Mar 2013 20:32:18 -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 D8C4D21F892A for ; Sun, 10 Mar 2013 20:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1673; q=dns/txt; s=iport; t=1362972738; x=1364182338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NXDv2bmj0c9kXrVXEBZ6RDbqrqXKl6gZpO2k7CoDlUk=; b=IkIa/y2igvff0SKEHCKzur9Ewjg4dIDFx8woUEZKlr0HpXHuvzZVBfgq 7MiSFHfnmqiLo49wcU7oKBg6jcyZXpUz5+zAQChwjKlyR1woYoaWvT+DJ Pc8Agk/pn1EU/cF6/V4DR0fy7uPZBfWhCLHyX38wsc6NWkp4zCJ76JGFb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIdPPVGtJXG//2dsb2JhbABDhDLAGYFPFnSCJAEBAQIBATo/EAIBCCIUEDIlAgQOBQiIBQYBC7wMjlsCMQeCX2EDp0qDCoIo X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185713668" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 11 Mar 2013 03:32:18 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2B3WI2O020603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 03:32:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 22:32:18 -0500 From: "Ali C. Begen (abegen)" To: Brett Tate Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjLtrmzSS0hf0Omfa72mDfZ75g4pQWAgAA0aQCAAAFJAIAAFbaAgGYRvgCAAFzE0IABOmQA Date: Mon, 11 Mar 2013 03:32:17 +0000 Message-ID: References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 03:32:23 -0000 Hi Brett, On Mar 10, 2013, at 10:27 AM, Brett Tate wrote: >>> An example SDP description is: >>>=20 >>> v=3D0 >>> o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 >>> s=3DSDP Seminar >>> i=3DA Seminar on the session description protocol >>> u=3Dhttp://www.example.com/seminars/sdp.pdf >>> e=3Dj.doe@example.com (Jane Doe) >>> c=3DIN IP4 233.252.0.1/127 >>> t=3D2873397496 2873404696 >>> a=3Drecvonly >>> m=3Daudio 49170 RTP/AVP 0 >>> m=3Dvideo 51372 RTP/AVP 99 >>> a=3Drtpmap:99 h263-1998/90000 >>> a=3Drecvonly >>>=20 >>=20 >> Is not the last/second "recvonly" redundant? >=20 >=20 > Yes; although is simplifies the example. The following example/descripti= on adjustment reflects a potential change to the session level attribute. >=20 > Within the following SDP example, the "inactive" attribute applies to aud= io media and the "recvonly" attribute applies to video media. >=20 > v=3D0 > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > s=3DSDP Seminar > i=3DA Seminar on the session description protocol > u=3Dhttp://www.example.com/seminars/sdp.pdf > e=3Dj.doe@example.com (Jane Doe) > c=3DIN IP4 233.252.0.1/127 > t=3D2873397496 2873404696 > a=3Dinactive > m=3Daudio 49170 RTP/AVP 0 > m=3Dvideo 51372 RTP/AVP 99 > a=3Drtpmap:99 h263-1998/90000 > a=3Drecvonly Yes, I like this example better. I will put this instead.=20 Paul, I think this also satisfies the "more complex" example you considered= . -acbegen= From abegen@cisco.com Sun Mar 10 20:32:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7621F89FC for ; Sun, 10 Mar 2013 20:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 dvUipwEMPT9q for ; Sun, 10 Mar 2013 20:32:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 129C221F8484 for ; Sun, 10 Mar 2013 20:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1362972760; x=1364182360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y+mXB5j+OwAiXgRaKprSyoHpfaMBiOg13pVHwBdQy7k=; b=ESujW5dPht0zVE/hEXptMFikGBrDDkuqkL1zneI8pok/xmP2y8r8Srtz 44STAZge+Y32MI6YbDl0+tePmA/FSCOju5vWMevUCIP/CVo2REXvIkRVi c5wTHlpB2enOFytAqYutaBtfhxlHmmZPmPQymziqDtIforWgAkhuXI0hg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALVPPVGtJXHA/2dsb2JhbABDhDLAGYFPFnSCJAEBAQIBATo/EAIBCCIUEDIlAgQOBQiIBQYBC7wNjlsCMQeCX2EDp0qDCoIo X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185923010" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 11 Mar 2013 03:32:31 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2B3WVgu006195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 03:32:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 22:32:31 -0500 From: "Ali C. Begen (abegen)" To: Brett Tate Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjLtrmzSS0hf0Omfa72mDfZ75g4pQWAgAA0aQCAAAFJAIAAFbaAgGYRvgCAAFzE0IABOs8A Date: Mon, 11 Mar 2013 03:32:30 +0000 Message-ID: References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <23F2C549CB51404D8E9BC394AF7C8508@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 03:32:40 -0000 Hi Brett, On Mar 10, 2013, at 10:27 AM, Brett Tate wrote: >>> An example SDP description is: >>>=20 >>> v=3D0 >>> o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 >>> s=3DSDP Seminar >>> i=3DA Seminar on the session description protocol >>> u=3Dhttp://www.example.com/seminars/sdp.pdf >>> e=3Dj.doe@example.com (Jane Doe) >>> c=3DIN IP4 233.252.0.1/127 >>> t=3D2873397496 2873404696 >>> a=3Drecvonly >>> m=3Daudio 49170 RTP/AVP 0 >>> m=3Dvideo 51372 RTP/AVP 99 >>> a=3Drtpmap:99 h263-1998/90000 >>> a=3Drecvonly >>>=20 >>=20 >> Is not the last/second "recvonly" redundant? >=20 >=20 > Yes; although is simplifies the example. The following example/descripti= on adjustment reflects a potential change to the session level attribute. >=20 > Within the following SDP example, the "inactive" attribute applies to aud= io media and the "recvonly" attribute applies to video media. >=20 > v=3D0 > o=3Djdoe 2890844526 2890842807 IN IP4 198.51.100.1 > s=3DSDP Seminar > i=3DA Seminar on the session description protocol > u=3Dhttp://www.example.com/seminars/sdp.pdf > e=3Dj.doe@example.com (Jane Doe) > c=3DIN IP4 233.252.0.1/127 > t=3D2873397496 2873404696 > a=3Dinactive > m=3Daudio 49170 RTP/AVP 0 > m=3Dvideo 51372 RTP/AVP 99 > a=3Drtpmap:99 h263-1998/90000 > a=3Drecvonly Yes, I like this example better. I will put this instead.=20 Paul, I think this also satisfies the "more complex" example you considered= . -acbegen= From ari.keranen@ericsson.com Sun Mar 10 21:32:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406621F891C for ; Sun, 10 Mar 2013 21:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 pEDYpRNsGmof for ; Sun, 10 Mar 2013 21:32:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F321F892F for ; Sun, 10 Mar 2013 21:32:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-09-513d5e6f4334 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8F.E9.10459.F6E5D315; Mon, 11 Mar 2013 05:32:47 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 11 Mar 2013 05:32:47 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1842C237A; Mon, 11 Mar 2013 06:32:47 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9DFDE54503; Mon, 11 Mar 2013 06:32:44 +0200 (EET) Received: from dhcp-44cd.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E1282534A4; Mon, 11 Mar 2013 06:32:43 +0200 (EET) Message-ID: <513D5E6E.5090304@ericsson.com> Date: Mon, 11 Mar 2013 00:32:46 -0400 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic References: <511CEB64.6070306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW5+nG2gwYo11hYdk9kspi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZRy4285e8Eeh4vG6WSwNjHOluhg5OSQETCTW /XvOBmGLSVy4tx7I5uIQEjjJKHH58zImkISQwAZGiWlzeCASuxglpr49wQLhrGWUmHJtBhuc s376UbAWXgFtiR13zgLZHBwsAqoSfz7ogITZBOwlbk64zg5iiwokSzxr2Q1VLihxcuYTFhBb REBGYu+mzcwgNrOAocS7GZ1g5wkLuEi8bvrGBjJSSCBH4tk1dZAwp4CvxLmv35kgym0lLsy5 zgJhy0s0b53NDPGZmsTVc5uYIZ5Rlbj67xXjBEbRWUg2z0LSPgtJ+wJG5lWM7LmJmTnp5Yab GIEhf3DLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMeR1 3pEOgW6+Q1Ul8+fv67bP4pX9IteavfWzhPnyKRPfCL6b+T36zMJPP9aa5y3pOLwrkiePOeNE hO2CxO+Wcjfm6jMWmDs/k132dP/pp6JTTRy1q6Y9WBuicK7BMN5FunXd38Vqt4vFpY4VtMRP uRkZecTO0FMst6jiioGdX8+hE+v2tDAXKrEUZyQaajEXFScCAJFRVbFHAgAA Cc: "Cullen Jennings \(fluffy\)" Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 04:32:50 -0000 Hi, Playing around with the numbers: the connectivity check messages are (depending on usernames) about 100 bytes each and bandwidth requirement for G.711 is about 80 Kbps. For connectivity checks that would translate to roughly one check every 10ms. So, assuming G.711 capable network, one every 20 ms should be somewhat safe also from bandwidth point of view. For total port usage, we have already the 100 candidates max RECOMMENDED value (http://tools.ietf.org/html/rfc5245#section-5.7.3). And NAT timing, I think 20ms is quite "fast enough" (50 candidate pairs started during first seconds) for a lower bound. So, along these lines, I'd propose the following for non-RTP traffic: - MUST NOT set Ta lower than 20ms. - RECOMMENDED 100 ms if no better information is available. (this would be the new conservative guess) - MAY use external information if such is available (e.g., RTP-like formula for bandwidth) to set lower Ta than the recommended. Then, both agents need to agree on the pacing for the checks to go forward in sync. For this purpose, they should indicate in the offer/answer what they are ready to use as the Ta and the highest of the two would be used. Cheers, Ari (as individual) On 2/21/13 10:25 PM, Cullen Jennings (fluffy) wrote: > > This is a hard problem to figure out but glad it is being tackled as > the current draft was fiction created to get it approved more. > > I'd be tempted to think of their being a few different things to > conserve or constraints we need to not exceed > > 1) nat timing > > 2) total ports in usage on the NAT > > 3) bandwidth usage that is not congestion controlled > > For 1) I'm not seeing any reasons to move off the 20 ms lower bound - > but if someone has empirical data that would be nice as the empirical > data we are basing this on is old. > > For 2) some Carrier Grade Nats (CGNs) are restricting a given client > to something like 1000 ports. There may be other limits too. It might > be worth setting up ICE so that a given ICE client never used more > than 100 ports at a time. I think this is a new type of constraint > that is not a big deal today but may be a bigger deal in the future > and we should consider it in an ICE bis. > > For 3) Its very hard to come up with something that is fast enough > that the media guys like it and slow enough the transport folks are > sure it is safe. My strawman proposal would be use more more > bandwidth than G.711 with 20 ms packets as we have been doing that > all over the place - without congestion control - and the internet > has not melted down. > > > > > On Feb 14, 2013, at 6:49 AM, Ari Keränen > wrote: > >> Hi all, >> >> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >> background, see [1] and [2]), as discussed at the Atlanta meeting, >> will be one of the important changes in the new version of ICE. >> >> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >> configurable, SHOULD have a default of 500 ms, and MUST NOT be >> configurable to be less than 500 ms." >> >> This results in very slow pace of starting connectivity checks if >> ICE is used with non-RTP traffic. With RTP, the Ta is calculated >> based on the expected bandwidth used by the RTP stream and can be >> down to 20 ms. Therefore, many current implementations apparently >> ignore the "MUST NOT" above and set Ta to something lower. >> >> The quite conservative value of 500 ms was originally chosen >> because of the fear of congesting the links with the connectivity >> check messages. This is obviously still a valid concern, but would >> suggesting something lower still make sense? How low would it be >> reasonably safe to go? What is currently used in practice? Can we >> come up with a formula similar to RTP (perhaps based on expected >> bandwidth usage)? >> >> >> Cheers, Ari >> >> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 [2] >> http://tools.ietf.org/html/rfc5245#section-16.2 >> _______________________________________________ mmusic mailing >> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > From gunnar.hellstrom@omnitor.se Mon Mar 11 00:19:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8798E21F869E for ; Mon, 11 Mar 2013 00:19:59 -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 HZFnPJWXDjfu for ; Mon, 11 Mar 2013 00:19:59 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C749F21F869C for ; Mon, 11 Mar 2013 00:19:55 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 11 Mar 2013 08:19:45 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id A85BF3A479; Mon, 11 Mar 2013 07:47:01 +0100 (CET) Message-ID: <513D7DE6.5030608@omnitor.se> Date: Mon, 11 Mar 2013 07:47:02 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Randall Gellens References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> <513CFBC5.6060209@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 07:19:59 -0000 On 2013-03-11 00:30, Randall Gellens wrote: > At 10:31 PM +0100 3/10/13, Gunnar Hellstrom wrote: > >> On 2013-03-10 23:02, Randall Gellens wrote: >>> If possible, I think it may be better to keep service negotiation >>> distinct from language negotiation. Otherwise things get very complex. >>> >> That was just a use case. >> >> Do you mean that we should divide it like this: >> >> Imagined example in a call from A to B. >> A prefer to talk English, and A has some capability to talk French >> A Prefers to talk, but A is capable of typing >> A Needs to get text in English or French >> A has some benefit of getting spoken English or French, but A >> cannot accept that as the only channel for language perception. >> >> A wants to have a conversation with B who declares only an ability >> to talk and understand spoken French. >> >> An evaluation of the needs, preferences and capabilities of A and B >> would result in that the call is not possible because we have common >> capabilities only in the direction from A to the B. >> In the return path, from B to A, the only option it to receive >> spoken French from the B, while A is depending on getting written >> English or Written French. >> >> ----- >> >> This information can then be used in a separate service request for >> getting a service C that adds rapid conversion of spoken French to >> typed French in the path from A to B, still letting the spoken French >> also pass over to A. > > > It's very easy to add complexity in order to solve more aspects of the > problem. I think we need to work very hard to keep this mechanism, at > least initially, very simple. > Yes, so I suggest that we now add a number of use cases, both simple and complex and then sort out which cases can be covered without getting lost in complexity. /Gunnar From pkyzivat@alum.mit.edu Mon Mar 11 04:26:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE75821F86E1 for ; Mon, 11 Mar 2013 04:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.438 X-Spam-Level: * X-Spam-Status: No, score=1.438 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 wlaxyzrlxjy0 for ; Mon, 11 Mar 2013 04:26:08 -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 497FA21F86EC for ; Mon, 11 Mar 2013 04:26:08 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id AB321l0041GhbT854BS7wm; Mon, 11 Mar 2013 11:26:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:1d9f:4522:3569:ca14]) by omta07.westchester.pa.mail.comcast.net with comcast id ABS71l00J4B9e0B3TBS7Rl; Mon, 11 Mar 2013 11:26:07 +0000 Message-ID: <513DBF4E.50900@alum.mit.edu> Date: Mon, 11 Mar 2013 19:26:06 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <50E60DDF.6070204@cisco.com> <50E639D6.90105@alum.mit.edu> <50E64D21.2030609@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88196A2A36@MBX07.citservers.local> 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=1363001167; bh=7K+1QVtU4LWzszeB/+I+zyVGXP4A9nMKBKUy0LQEa4E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QNz2xTzVYR9wUQfIsQV7q7yAdAVhGfat+vTpd9NgNOtGAR3OtyPRV1QebCQo7FZAK N39qwEjDpG/QLicg3Sbf1lowlXm0+HKtuSEJujB86Ml4YlT5HUrCNBswN8/V3RMoYH 72OblBnF0nZemOQtH8cH1NMk1L6uaO/L/fU1KWL8M+RBQnxEr/y6BDRVOWTlKmtaOs jN0E9MzlQ/cGcGqw0P5jAOfZ4MfxTol6aH58pcYJQFW1RxUQ5mwhcTU9jR4f82/6LA 7IFrXSJYaUdreJIe0Kps1w1h/bnxLnxjPCs2RB5j96CvMhvhy43SGTywVh35Dp6vTY 7n45yo658xh1g== Cc: "mmusic@ietf.org" , Brett Tate Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 11:26:09 -0000 On 3/11/13 11:32 AM, Ali C. Begen (abegen) wrote: > Hi Brett, > > On Mar 10, 2013, at 10:27 AM, Brett Tate wrote: > >>>> An example SDP description is: >>>> >>>> v=0 >>>> o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 >>>> s=SDP Seminar >>>> i=A Seminar on the session description protocol >>>> u=http://www.example.com/seminars/sdp.pdf >>>> e=j.doe@example.com (Jane Doe) >>>> c=IN IP4 233.252.0.1/127 >>>> t=2873397496 2873404696 >>>> a=recvonly >>>> m=audio 49170 RTP/AVP 0 >>>> m=video 51372 RTP/AVP 99 >>>> a=rtpmap:99 h263-1998/90000 >>>> a=recvonly >>>> >>> >>> Is not the last/second "recvonly" redundant? >> >> >> Yes; although is simplifies the example. The following example/description adjustment reflects a potential change to the session level attribute. >> >> Within the following SDP example, the "inactive" attribute applies to audio media and the "recvonly" attribute applies to video media. >> >> v=0 >> o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 >> s=SDP Seminar >> i=A Seminar on the session description protocol >> u=http://www.example.com/seminars/sdp.pdf >> e=j.doe@example.com (Jane Doe) >> c=IN IP4 233.252.0.1/127 >> t=2873397496 2873404696 >> a=inactive >> m=audio 49170 RTP/AVP 0 >> m=video 51372 RTP/AVP 99 >> a=rtpmap:99 h263-1998/90000 >> a=recvonly > > Yes, I like this example better. I will put this instead. > > Paul, I think this also satisfies the "more complex" example you considered. Yes it does. Thanks, Paul From randy@qti.qualcomm.com Mon Mar 11 05:18:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15B21F8718 for ; Mon, 11 Mar 2013 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 qE+7ypk9HK5J for ; Mon, 11 Mar 2013 05:18:00 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1816921F86FF for ; Mon, 11 Mar 2013 05:17:48 -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=1363004268; x=1394540268; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=hUZ8qUxDGPA7mtV3c5767eVIAAlfLr7L6NenjOHJfX8=; b=EQ55IyiokkmI19yS1yuZgaZSiDD/VZycP3+nW2ee5KMu/W4QDK4UVVTy xyv6nYJ4uABrmYAq7UCBQWWfES6ujYT2I3D/6tRUZE4c3+Y9vPTdLKVU3 25ih4GG+oywG8lstEqO/oWw2ZPnJZXC6foR9lTvejGAhRhlYEm1NCoCgL 0=; X-IronPort-AV: E=Sophos;i="4.84,822,1355126400"; d="scan'208";a="29403720" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 11 Mar 2013 05:17:47 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Mar 2013 05:17:46 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Mar 2013 05:17:46 -0700 Message-ID: In-Reply-To: <513D7DE6.5030608@omnitor.se> References: <512C4B0D.5000701@cisco.com> <6E90227CD3894A258EDE91D85B987169@DougEwell> <513B64DC.7070305@stpeter.im> <513CA193.30304@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8BF2D9@FR712WXCHMBA11.zeu.alcatel-lucen t.com> <513CDF15.8070601@alvestrand.no> <513CECB0.2010803@omnitor.se> <513CFBC5.6060209@omnitor.se> <513D7DE6.5030608@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Mon, 11 Mar 2013 05:16:02 -0700 To: Gunnar Hellstrom 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.39.5] Cc: Ari Keranen , "mmusic@ietf.org" , "DRAGE, Keith \(Keith\)" , Peter Saint-Andre , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , Alexey Melnikov , Randall Gellens Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:18:01 -0000 At 7:47 AM +0100 3/11/13, Gunnar Hellstrom wrote: > On 2013-03-11 00:30, Randall Gellens wrote: >> At 10:31 PM +0100 3/10/13, Gunnar Hellstrom wrote: >> >>> On 2013-03-10 23:02, Randall Gellens wrote: >>>> If possible, I think it may be better to keep service >>>> negotiation distinct from language negotiation. Otherwise >>>> things get very complex. >>>> >>> That was just a use case. >>> >>> Do you mean that we should divide it like this: >>> >>> Imagined example in a call from A to B. >>> A prefer to talk English, and A has some capability to talk French >>> A Prefers to talk, but A is capable of typing >>> A Needs to get text in English or French >>> A has some benefit of getting spoken English or French, but A >>> cannot accept that as the only channel for language perception. >>> >>> A wants to have a conversation with B who declares only an >>> ability to talk and understand spoken French. >>> >>> An evaluation of the needs, preferences and capabilities of A >>> and B would result in that the call is not possible because we >>> have common capabilities only in the direction from A to the B. >>> In the return path, from B to A, the only option it to receive >>> spoken French from the B, while A is depending on getting written >>> English or Written French. >>> >>> ----- >>> >>> This information can then be used in a separate service request >>> for getting a service C that adds rapid conversion of spoken >>> French to typed French in the path from A to B, still letting the >>> spoken French also pass over to A. >> >> >> It's very easy to add complexity in order to solve more aspects of >> the problem. I think we need to work very hard to keep this >> mechanism, at least initially, very simple. >> > Yes, so I suggest that we now add a number of use cases, both > simple and complex and then sort out which cases can be covered > without getting lost in complexity. I agree that the document needs to be more detailed and more clear on the problem it is solving and the use cases it is targeting. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- 1. If reproducibility may be a problem, conduct the test only once. 2. If a straight line fit is required, obtain only two data points. From randy@qti.qualcomm.com Mon Mar 11 08:16:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9B511E80E4; Mon, 11 Mar 2013 08:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-iLSxfZ6txX; Mon, 11 Mar 2013 08:16:47 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE411E80DF; Mon, 11 Mar 2013 08:16:47 -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=1363015007; x=1394551007; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=qHIQkB+lP7lw5AKNDwl4c31o8cXSlIJg/yLvxQs/dA0=; b=lKqJEzX4BezyIVwK+zQ5/9Vt5fbDeBGhcJgUgWen0ZCNHHAcg/QP19oT fN5QVQ87NRtbetEmhXF5b3oWeqX4N97TgZxWk9DpDeJnMUXBnMMhZU50v Fx4oWdNU25tg4B5yPY6mVjA83rAEaPlWwHe3j68aiEGF2ZBnyp8vNxAHd 4=; X-IronPort-AV: E=Sophos;i="4.84,824,1355126400"; d="scan'208";a="29440314" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 11 Mar 2013 08:16:41 -0700 X-IronPort-AV: E=Sophos;i="4.84,824,1355126400"; d="scan'208";a="449729912" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Mar 2013 08:16:40 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Mar 2013 08:16:40 -0700 Message-ID: In-Reply-To: <201302251600.r1PG0YLR2598111@shell01.TheWorld.com> References: <20130222090937.665a7a7059d7ee80bb4d670165c8327d.ad3940b1cb.wbe@email0 3.secureserver.net> <201302251600.r1PG0YLR2598111@shell01.TheWorld.com> X-Mailer: Eudora for Mac OS X Date: Mon, 11 Mar 2013 06:53:45 -0700 To: "Dale R. Worley" 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: Mon, 11 Mar 2013 08:18:36 -0700 Cc: Ari Keranen , "mmusic@ietf.org" , Peter Saint-Andre , "DRAGE, Keith \(Keith\)" , Gunnar Hellstrom , "ietf-languages-bounces@alvestrand.no" , Flemming Andreasen , "Hannes \(NSN - FI/Espoo\) Tschofenig" , Peter Saint-Andre , Brian Rosen , ietf-languages@iana.org, Alexey Melnikov , Randall Gellens , John C Klensin , ietf@ietf.org Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 15:16:48 -0000 Hi Dale, At 11:00 AM -0500 2/25/13, Dale R. Worley wrote: > (It's not clear to me what the proper mailing list is to discuss this > draft. From the headers of the messages, it appears that the primary > list is ietf@ietf.org, but the first message in this thread about that > draft already has a "Re:" in the subject line, so the discussion > started somewhere else.) There has been some discussion among those listed in the CC header of this message. I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft. By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal). Please let me know if you can make it. > (Also, it's not clear why Randall's messages are coming through in > HTML.) My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well. > But onward to questions of substance: > > - Why SDP and not SIP? > > I'd like to see a more thorough exploration of why language > negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, > uses the Content-Language header to specify languages.) In principle, > specifying data that may be used in call-routing should be done in the > SIP layer, but it's well-accepted in the SIP world that call routing > may be affected by the SDP content as well (e.g., media types). I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video. > And some discussion and comparison should be done with the SIP/HTTP > Content-Language header (used to specify the language of the > communications) and the SIP Accept-Language header (used to specify > the language of text components of SIP messages), particularly given > that Accept-Language has different set of language specifiers and a > richer syntax for specifying preferences. In any case, preference > should be given to reusing one of the existing syntaxes for specifying > language preferences. I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL. (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.) As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute. > - Dependency between media descriptions? > > Another example would be a user who is able to speak but is deaf or > hard-of-hearing and requires a voice stream plus a text stream > (known as voice carry over). Making language a media attribute > allows the standard session negotiation mechanism to handle this by > providing the information and mechanism for the endpoints to make > appropriate decisions. > > This scenario suggests that there might be dependency or interaction > between language specifications for different media descriptions. > Whether this is needed should be determined and documented. > > - Specifying preference levels? > > For example, some users may be able to speak several languages, but > have a preference. > > This might argue for describing degrees of preference using "q" > parameters (as in the SIP Accept-Language header). > > - Expressing multiple languages in answers > > (While it is true that a conversation among multilingual people > often involves multiple languages, it does not seem useful enough > as a general facility to warrant complicating the desired semantics > of the SDP attribute to allow negotiation of multiple simultaneous > languages within an interactive media stream.) > > Why shouldn't an answer be able to indicate multiple languages? At > the least, this might provide the offerer with useful information. You raise good questions that I think need more discussion. I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately. > > - Reusing a=lang > > Searching, I can only find these descriptions of the use of > "a=lang:...": > > RFC 4566 > draft-saintandre-sip-xmpp-chat > draft-gellens-negotiating-human-language > > So it looks like "a=lang:..." is entirely unused at the present and is > safe to be redefined. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- An economist is an expert who will know tomorrow why the things he predicted yesterday didn't happen today. --Laurence J. Peter From worley@shell01.TheWorld.com Mon Mar 11 09:01:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9838511E80E4 for ; Mon, 11 Mar 2013 09:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 goy9AqZUKE9z for ; Mon, 11 Mar 2013 09:01:05 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id A9EEA21F8BD5 for ; Mon, 11 Mar 2013 09:01:05 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BG0mfp020085 for ; Mon, 11 Mar 2013 12:00:50 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BG0ln7222750 for ; Mon, 11 Mar 2013 11:00:47 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BG0lKQ222769; Mon, 11 Mar 2013 12:00:47 -0400 (EDT) Date: Mon, 11 Mar 2013 12:00:47 -0400 (EDT) Message-Id: <201303111600.r2BG0lKQ222769@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] How to arrange for the rejection of the bundle media description? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:01:06 -0000 Assuming that there is a separate bundle media description in the offer -- and I think that there are many benefits of having a separate bundle media description -- we must arrange that an answerer that does not implement bundling will always reject that media description. As far as I can tell, there are three possible ways to force the answerer to reject a media description: 1. The media description uses a special media type that is not otherwise implemented. 2. The media description uses a special proto value that is not otherwise implemented. 3. The media description only provides encoding names (codec names) that are not otherwise implemented. (Although this seems to be an obvious application of SDP capability negotiation, I see no way to use capneg to specify alternative port numbers (zero or non-zero) depending on what capabilities the answerer supports. And we probably can't rely on legacy SBCs to handle properly a situation where the offered port number is zero and the answered port number is non-zero.) Solution 1 is the cleanest from a design point of view. (I personally like using "m=multipart".) But Hadriel tells me that a lot of legacy SBCs reject any SDP that contains a media type that is not "audio" or "video". Regarding solution 2, there are now 32 defined proto values (http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-2), so it is more likely that a legacy SBC (that is, one not designed to support bundling) will pass unknown proto values. But we need feedback on that point from people who understand what is now deployed in the Internet. Solution 2 is also reasonably sound from a design point of view, as the proto value is allowed to modify the significance of the fmt values in the m= line. If do not use an encapsulating payload format, then the payloads are a mix of various RTP payload formats and SCTP-over-DTLS packets, and that mixture is not accurately described by any of the defined proto values; defining a new proto value allows the m= line to describe the situation accurately. Solution 3 is the safest from a legacy interoperation point of view. If bundling encapsulates all the constituent media packets, it is also correct from a design point of view, as the encapsulation payload format is the only payload type being sent (at this layer of the stack). But if bundling does not encapsulate RTP packets, then providing only one encoding name is not correct from a design point of view. (Although the feedback I get is that SBCs are not very particular about the encoding names and payload types in media descriptions.) How are we to handle this problem? At this point, I favor defining a new proto value, as it avoids the legacy SBC problems that I know of, but also accurately describes the multiplexed packet stream. Dale From worley@shell01.TheWorld.com Mon Mar 11 09:02:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E511E80F0 for ; Mon, 11 Mar 2013 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 zVfRhlrLEWQc for ; Mon, 11 Mar 2013 09:02:10 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8433711E8134 for ; Mon, 11 Mar 2013 09:02:06 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BG0KXR015127; Mon, 11 Mar 2013 12:00:22 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BG0Kev222739; Mon, 11 Mar 2013 11:00:20 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BG0K16222765; Mon, 11 Mar 2013 12:00:20 -0400 (EDT) Date: Mon, 11 Mar 2013 12:00:20 -0400 (EDT) Message-Id: <201303111600.r2BG0K16222765@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Cc: rtcweb@ietf.org Subject: [MMUSIC] Revision of bundling proposal/analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:02:11 -0000 I've just submitted draft-worley-sdp-bundle-05, which is an SDP bundling proposal along with a bunch of analysis and comparison to other bundling proposals. The biggest change is adding a detailed analysis of alternatives for the address/port combinations to be used when offering constituent media descriptions (m= lines) so as to get all the mechanics to work as we'd like. It is from this analysis I noticed that we don't have a good method to *answer* a constituent media description. (I've sent e-mail about that to MMUSIC.) I've added an example containing two SCTP media descriptions, which will be a common case on WebRTC. A change that I have not yet made is removing the RTP encapsulation payload format ("kumquat" itself). It looks like encapsulation works against some properties we'd like the solution to have. Unfortunately, removing encapsulation causes constraints in other parts of the solution. In particular, different media descriptions will be constrained to have different payload type numbers, and bundling can't support multiple transport addresses or multiple ports within a single media description. Dale A new version of I-D, draft-worley-sdp-bundle-05.txt has been successfully submitted by Dale R. Worley and posted to the IETF repository. Filename: draft-worley-sdp-bundle Revision: 05 Title: Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP) Creation date: 2013-03-11 Group: Individual Submission Number of pages: 42 URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-05.txt Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-05 Abstract: This document defines a generic bundle mechanism for the Session Description Protocol (SDP) by which the media described by a number of media descriptions ("m= lines") are multiplexed and transmitted over a single transport association. The transport association is described by an additional media description, allowing SDP attributes to be applied to the aggregate, independently of attributes applied to the constituents. In offer/answer usage, the bundle mechanism is backward compatible with SDP processors that do not understand the mechanism. The mechanism is designed to be compatible with the limitations of the existing Internet infrastructure. From randy@qti.qualcomm.com Mon Mar 11 09:03:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D790211E8111 for ; Mon, 11 Mar 2013 09:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=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 I7HN2IA3NHYL for ; Mon, 11 Mar 2013 09:03:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0832911E80F0 for ; Mon, 11 Mar 2013 09:03:55 -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=1363017834; x=1394553834; h=message-id:date:to:from:subject:mime-version; bh=b26Z1kxmjYNymqdkYf3Xvu4FGNEhPbYco05LOpDJ0Wg=; b=nZu5prRPZnzsC5cL5SeqpL4weoUFledgUlhJwWxQvY7qHgkxt2uTidIu pX31OoWw9b/Bj+FtWItiegUVkbXifI6vxStiBqoQTIKVnqsWmubq0DR5K wITt59FhCL+5J8XU5KbrsrMwakoQEjd0ADC2Th9Zom54AhRVA/3ohrJzU c=; X-IronPort-AV: E=Sophos;i="4.84,824,1355126400"; d="scan'208";a="28694847" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 11 Mar 2013 09:03:54 -0700 X-IronPort-AV: E=Sophos;i="4.84,824,1355126400"; d="scan'208";a="503450280" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Mar 2013 09:03:54 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Mar 2013 09:03:54 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Mon, 11 Mar 2013 08:57:02 -0700 To: 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] Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:03:56 -0000 [[[ resending without Cc list ]]] Hi Dale, At 11:00 AM -0500 2/25/13, Dale R. Worley wrote: > (It's not clear to me what the proper mailing list is to discuss this > draft. From the headers of the messages, it appears that the primary > list is ietf@ietf.org, but the first message in this thread about that > draft already has a "Re:" in the subject line, so the discussion > started somewhere else.) There has been some discussion among those listed in the CC header of this message. I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft. By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal). Please let me know if you can make it. > (Also, it's not clear why Randall's messages are coming through in > HTML.) My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well. > But onward to questions of substance: > > - Why SDP and not SIP? > > I'd like to see a more thorough exploration of why language > negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, > uses the Content-Language header to specify languages.) In principle, > specifying data that may be used in call-routing should be done in the > SIP layer, but it's well-accepted in the SIP world that call routing > may be affected by the SDP content as well (e.g., media types). I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video. > And some discussion and comparison should be done with the SIP/HTTP > Content-Language header (used to specify the language of the > communications) and the SIP Accept-Language header (used to specify > the language of text components of SIP messages), particularly given > that Accept-Language has different set of language specifiers and a > richer syntax for specifying preferences. In any case, preference > should be given to reusing one of the existing syntaxes for specifying > language preferences. I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL. (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.) As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute. > - Dependency between media descriptions? > > Another example would be a user who is able to speak but is deaf or > hard-of-hearing and requires a voice stream plus a text stream > (known as voice carry over). Making language a media attribute > allows the standard session negotiation mechanism to handle this by > providing the information and mechanism for the endpoints to make > appropriate decisions. > > This scenario suggests that there might be dependency or interaction > between language specifications for different media descriptions. > Whether this is needed should be determined and documented. > > - Specifying preference levels? > > For example, some users may be able to speak several languages, but > have a preference. > > This might argue for describing degrees of preference using "q" > parameters (as in the SIP Accept-Language header). > > - Expressing multiple languages in answers > > (While it is true that a conversation among multilingual people > often involves multiple languages, it does not seem useful enough > as a general facility to warrant complicating the desired semantics > of the SDP attribute to allow negotiation of multiple simultaneous > languages within an interactive media stream.) > > Why shouldn't an answer be able to indicate multiple languages? At > the least, this might provide the offerer with useful information. You raise good questions that I think need more discussion. I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately. > > - Reusing a=lang > > Searching, I can only find these descriptions of the use of > "a=lang:...": > > RFC 4566 > draft-saintandre-sip-xmpp-chat > draft-gellens-negotiating-human-language > > So it looks like "a=lang:..." is entirely unused at the present and is > safe to be redefined. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- An economist is an expert who will know tomorrow why the things he predicted yesterday didn't happen today. --Laurence J. Peter From richard.ejzak@alcatel-lucent.com Mon Mar 11 11:21:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9021F8CD2 for ; Mon, 11 Mar 2013 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 pZZ6qUZfgEaQ for ; Mon, 11 Mar 2013 11:21:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5721F8CCB for ; Mon, 11 Mar 2013 11:21:55 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BILVZu028709 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 19:21:41 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 19:21:39 +0100 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 14:21:37 -0400 From: "Ejzak, Richard P (Richard)" To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling Thread-Index: AQHOHgF3Mop2zAIAB0ia8HPK7HA92Zignn4A Date: Mon, 11 Mar 2013 18:21:36 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> In-Reply-To: <201303110237.r2B2btIS180463@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:21:58 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Dale R. Worley > it does not see media. (It does not suffice for the answerer to > provide a null transport address and non-zero port for the MD, or for > the answerer to send "a=3Dinactive", as an intermediate entity may see > the MD as being accepted and expect the offerer to send RTCP.) >=20 Considering the following text from RFC 3264: "Of course, when used, the port number MUST NOT be zero, which would specif= y that the stream has been disabled. An agent MUST be capable of receiving= SDP with a connection address of 0.0.0.0, in which case it means that neit= her RTP nor RTCP should be sent to the peer." There is no ambiguity here about the meaning of zero port. While this text could be interpreted to not specifically preclude the peer = that indicates an unspecified address from sending RTCP to the peer indicat= ing a valid address, this seems really far-fetched to me. Sending this RTC= P would be pointless and wasteful since by definition it would have nothing= to report on and there is no possibility to receive reports. =20 If would be nice to eliminate this ambiguity by ending the quoted sentence = "...neither RTP nor RTCP should be sent to either peer." The text also says that the peer indicating an unspecified address "...does= n't know the addresses and ports at the time..." Again, it seems like a re= al stretch to assume that the peer can send RTCP if it doesn't have an addr= ess or port available for receipt of RTP. Richard From pkyzivat@alum.mit.edu Mon Mar 11 12:31:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7314711E8218 for ; Mon, 11 Mar 2013 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=0.500, 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 2nsjDxPt84je for ; Mon, 11 Mar 2013 12:31:42 -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 A8AF211E8217 for ; Mon, 11 Mar 2013 12:31:42 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id AEgY1l0031c6gX854KXish; Mon, 11 Mar 2013 19:31:42 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:7520:2a01:6017:c905]) by omta23.westchester.pa.mail.comcast.net with comcast id AKXh1l01P3L1XU23jKXhHq; Mon, 11 Mar 2013 19:31:42 +0000 Message-ID: <513E311E.4080204@alum.mit.edu> Date: Tue, 12 Mar 2013 03:31:42 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.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=1363030302; bh=vRCQEWbieE+svMvAn0BjOuzG3CSxt0SqM1hM+wnCMOI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KLPw1rE72gqyrrNcoSzlPI7L+BT9sLT0175LghBFTwWgwPOWli7aWoONNcCMYZm5c 9mm0UYyT/tBxLnLFAfapv5yIKolpazm7yKJfbZ3Q+P2ipxzvYIREp5BhpjcqA8X8d8 AY+t7oaCYwFRblTTJnih1JyMTM5/yzOPspObOTVSFDrVwX55PCpVOIENkX0ba7CWVT NE49jQb1sCUA/swpfN18YrM4+060I6VjMypRMqhhBN71wDPX06tMaXEDAJBlLYgip+ y0kUvYpr7+yoxZFlwTxIreV1yagTGpKdHgOG19lq9cMCQjcDlYcBHzb78FkWgus9sm AJJzITtMAhnng== Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:31:43 -0000 On 3/12/13 2:21 AM, Ejzak, Richard P (Richard) wrote: > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Dale R. Worley > > >> it does not see media. (It does not suffice for the answerer to >> provide a null transport address and non-zero port for the MD, or for >> the answerer to send "a=inactive", as an intermediate entity may see >> the MD as being accepted and expect the offerer to send RTCP.) >> > > Considering the following text from RFC 3264: > > "Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer." > > There is no ambiguity here about the meaning of zero port. > > While this text could be interpreted to not specifically preclude the peer that indicates an unspecified address from sending RTCP to the peer indicating a valid address, this seems really far-fetched to me. Sending this RTCP would be pointless and wasteful since by definition it would have nothing to report on and there is no possibility to receive reports. > > If would be nice to eliminate this ambiguity by ending the quoted sentence "...neither RTP nor RTCP should be sent to either peer." AFAIK it was never the intent that a zero address on one end would block media flow in the other direction. Thanks, Paul > The text also says that the peer indicating an unspecified address "...doesn't know the addresses and ports at the time..." Again, it seems like a real stretch to assume that the peer can send RTCP if it doesn't have an address or port available for receipt of RTP. > > Richard > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From gunnar.hellstrom@omnitor.se Mon Mar 11 14:45:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1D21F9075 for ; Mon, 11 Mar 2013 14:45:44 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 nIcHn3eTrxAS for ; Mon, 11 Mar 2013 14:45:40 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id A9C5221F8EDA for ; Mon, 11 Mar 2013 14:45:32 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 11 Mar 2013 22:44:49 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 6EF3D3A0F7 for ; Mon, 11 Mar 2013 22:44:48 +0100 (CET) Message-ID: <513E504F.1010209@omnitor.se> Date: Mon, 11 Mar 2013 22:44:47 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040800080507030709090604" Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:45:45 -0000 This is a multi-part message in MIME format. --------------040800080507030709090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Before this discussion got its home in mmusic, we discussed quite similar topics as you, Dale brought up now. It was about what was needed to be expressed by the parameters and if SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could be a suitable mechanism for routing and decisions on the parameters. Here is part of that discussion that we need to capture. I see some complication that might be needed in order to reflect reality. At least they should be discussed. And I am also seeing some different ways to specify it. The complications to discuss are: *1. Level of preference.* There may be a need for specifying levels of preference for languages. I might strongly prefer to talk English, but have some useful capability in French. I want to display that preference and that capability with that difference, so that I get English whenever possible, but get the call connected even if English is not available at all but French is. I would assume that two levels are sufficient, but that can be discussed: Preferred and capable. > > The draft already proposes that languages be listed in order of > preference, which should handle the example you mention: you list > English first and French second. The called party selects English if > it is capable and falls back to French if English is not and French > is. This seems much simpler and is a common way of handling > situations where there is a preference. It would be good to keep the > mechanism as simple as possible. > Yes, I am afraid of complicating this beyond the point when users do > not manage to get their settings right. > Still, I do not think that the order is sufficient as level of > preference indicator. You may want to indicate capability for one > modality but preference for another. ( as my example, capability for > ASL, but preference for talking and reading ) If you have a capability for ASL but preference for talking and reading, you could initially offer two media streams: a voice with English and a text with English. If accepted, you have your preferred communications. If those are rejected you could then offer video with ASL. Would that handle the case? No, video is still very valuable for judging the emergency case. Or seeing a friend. So, if you support it you want to offer it. But the decision on languages and modalities may end up in video being not important for language communication. > > >>>> *2. Directionality* >>>> There is a need for a direction of the language preference. >>>> "Transmit, receive or both". or "Produce, perceive or both". That >>>> is easy to understand for the relay service examples. >>>> A hard-of-hearing user may declare: >>>> >>>> Text, capable, produce, English >>>> Text, prefer, perceive, English >>>> Audio, prefer, produce, English >>>> Audio, capable, perceive, English ( tricky, a typical >>>> hard-of-hearing user may have benefit of receiving audio, while it >>>> is not usable enough for reliable perception. I do not want to see >>>> this eternally complex, but I see a need for refined expressions here) >>>> video, capable, both, ASL >>>> >>>> This should be understood as that the user prefers to speak and get >>>> text back, and has benefit of getting voice in parallel with text. >>>> ASL signing can be an alternative if the other party has >>>> corresponding capability or preference. >>>> >>> >>> The draft does support this (and even mentions some of these >>> specific uses) because it proposes an SDP media attribute, and media >>> can be specified to be send, receive, or both. >> No, that is not the same. You want the media to flow, but by the >> parameter you want to indicate your preference for how to use it. >> You do not want to turn off incoming audio just because you prefer to >> talk but read text. > > Yes, I see, thanks for the clarification. Does this need to be part > of the session setup? If you establish all media streams that you > wish to use, can you then just use them as you prefer? I will consult > with the NENA accessibility committee on this. No, there are specific services providing service with one direction but not the other. The information is needed for decision on what assisting service to invoke. One such service is the captioned telephony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a very strong preference for getting just that service, but could accept with much lower preference to get a direct conversation with the far end in combined text and voice. > > >>>> I think it would be useful to move most of the introduction to a >>>> structured use case chapter and express the different cases >>>> according to a template. Thast can then be used to test if proposed >>>> approaches will work. >>> >>> I'm not sure I fully understand what you mean by "structured" in >>> "structured use case" or "template." Can you be more specific? >> I mean just a simple template for how the use case descriptions are >> written. >> >> E.g. >> A title indicating what case we have. >> Description of the calling user and its capabilities and preferences. >> Description of the answering user and its capabilities and preferences >> Description of a possible assisting service and its capabilities and >> preferences >> Description of the calling user's indications. >> Description of the answering user's indications. >> The resulting decision and outcome >>> >>> >>>> *3. Specify language and modality at SIP Media tag level instead. >>>> *There could be some benfits to declare these parameters at the SIP >>>> media tag level instead of SDP level. >>>> A call center can then register with their capabilities already at >>>> the SIP REGISTER time, and the caller preferences / callee >>>> capabilities mechanism from RFC 3840/ 3841 can be used to select >>>> modalities and languages and route the call to the best capable >>>> person or combination of person and assisting interpreting. >>> >>> Maybe, but one advantage of using SDP is that the ESInet can take >>> language and media needs into account during policy-based routing. >>> For example, in some European countries emergency calls placed by a >>> speaker of language x in country y may be routed to a PSAP in a >>> country where x is the native language. Or, there might be regional >>> or national text relay or sign language interpreter services as >>> opposed to PSAP-level capabilities. >> Is there a complete specification for how policy based routing is >> thought to work? Where? >> Does it not use RFC 3840/3841? >> That procedure is already supported by SIP servers. Using SDP >> requires new SIP server programming. > > NENA has a document under development. I thought it was able to take > SDP into account but I'll look into it, and I'm sure Brian will have > something to say. Yes, I think I have seen that. But it needs to come into IETF to be possible to refer to. > > >>>> But, on the other hand, then we need a separate specification of >>>> what modality the parameters indicate, because the language tags >>>> only distinguish between signed and other languages, and "other" >>>> seems to mean either spoken or written without any difference. >>>> >>> >>> The SDP media already indicates the type (audio, video, text). >> Yes, convenient. But there is no knowledge about the parameters until >> at call time. It could be better to know the callee capabilities in >> advance if available. Then middle boxes can do the routing instead of >> the far end. There may be many terminals competing for the call and >> the comparison about who to get it should be done by a sip server >> instead of an endpoint. > > I think call time is the right time. For emergency calls, it isolates > the decision making about how to process calls requiring text, sign > language, foreign language, etc. to the ESInet and PSAPs, which is I > think the right place. The processing rules in the ESInet can then be > changed without involving any carrier. The capabilities of an entity > may vary based on dynamic factors (time of day, load, etc.) so the > decision as to how to support a need may be best made by the ESInet or > PSAP in the case of an emergency call, or called party for > non-emergency calls. For example, at some times or under some loads, > emergency calls may be routed to a specific PSAP that is not the > geographically indicated one. Likewise, a non-emergency call to a > call center may be routed to a center in a country that has support > for the language or media needed. The decision is of course made at call time. With the RFC 3840/3841 method, the different agents and services available register their availability and capabilities when they go on duty, and unregister when they stop, so that their information is available at call time. > > Further, it is often the case that the cost of relay, interpretation, > or translation services is affected by which entity invokes the service. Yes, that is a complicating policy issue. > > >>>> *4. Problem that 3GPP specifies that it is the UAs only who specify >>>> and act on these parameters. >>>> *I think it is a problem that 3GPP inserted the restriction that >>>> the language and modality negotiation shall only bother the >>>> involved UAs. >>>> It would be more natural that it is a service provider between them >>>> who detect the differences and make the decision to invoke a relay >>>> service for the relay case. >>>> How do you propose to solve that? Let the service provider behave >>>> as a B2BUA, who then can behave as both a UA and a service provider? >>> >>> What do you mean by "service provider?" In the case of a voice >>> service provider such as a cellular carrier or a VoIP provider, I >>> think this should be entirely transparent. The voice service >>> provider knows it is an emergency call and routes to an ESInet. It >>> is then up to the ESInet and the PSAPs to handle the call as they wish. >> It can be a service provider for just the function to make advanced >> call invocation based on language preferences. The same type of >> decisions, call connections and assisting service invocation are >> needed in everyday calls as in emergency calls. But it can also be a >> service provider for emergency services and the user is registered by >> that service provider. They can make decisions on the call. E.g. >> detect that it is an emergency call requiring interpreter, and >> therefore connect to both the PSAP and interpreter at the same time >> to save time. > > I think it's best to make these decisions at the end, not the middle. > In the case of emergency calls, the ESInet can route to a particular > PSAP, the PSAP may bridge in translation or interpretation services, > etc. In the case of non-emergency calls, the call center may support > some capabilities locally at some hours but route to a different call > center at other times. The end is not decided until you have evaluated the alternative possible ends and decided who has the right capability and preference. There is another issue with using sdp for decisions. SIP Message is included in the set of methods to handle in emergency calls in RFC 6443. It can be used within sessions to carry text messages if other media are used as well. It is no favored way to have text communication, but possible. SIP message has no sdp. I know that the 3GPP sections about emergency calling in TS 22.101 points towards using MSRP for text messaging, so it should not be an issue for 3GPP. Can we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media? I do not urge for solving it for SIP Message, I just wanted to point out that result by basing the mechanism on SDP. Will there be a possibility for remote participation on Thursday. I am sorry I am not there, but would like to participate if possible. /Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-03-11 16:57, Randall Gellens wrote: > [[[ resending without Cc list ]]] > > Hi Dale, > > At 11:00 AM -0500 2/25/13, Dale R. Worley wrote: > >> (It's not clear to me what the proper mailing list is to discuss this >> draft. From the headers of the messages, it appears that the primary >> list is ietf@ietf.org, but the first message in this thread about that >> draft already has a "Re:" in the subject line, so the discussion >> started somewhere else.) > > There has been some discussion among those listed in the CC header of > this message. I think the mmusic list is probably the right place to > continue the discussion and was planning on doing so more formally > with the next revision of the draft. > > By the way, the draft was updated and is now at -02: > http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt > > There is a face-to-face discussion Thursday 11:30-1:00 at The > Tropicale (the cafe in the Caribe Royal). Please let me know if you > can make it. > >> (Also, it's not clear why Randall's messages are coming through in >> HTML.) > > My apologies; I have gotten in the habit when replying to messages > that have style to allow Eudora to send my reply styled as well. > > >> But onward to questions of substance: >> >> - Why SDP and not SIP? >> >> I'd like to see a more thorough exploration of why language >> negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, >> uses the Content-Language header to specify languages.) In principle, >> specifying data that may be used in call-routing should be done in the >> SIP layer, but it's well-accepted in the SIP world that call routing >> may be affected by the SDP content as well (e.g., media types). > > I think it fits more naturally in SDP since the language is related to > the media, e.g., English for audio and ASL for video. > > >> And some discussion and comparison should be done with the SIP/HTTP >> Content-Language header (used to specify the language of the >> communications) and the SIP Accept-Language header (used to specify >> the language of text components of SIP messages), particularly given >> that Accept-Language has different set of language specifiers and a >> richer syntax for specifying preferences. In any case, preference >> should be given to reusing one of the existing syntaxes for specifying >> language preferences. > > I think the semantics of Content-Language and Accept-Language are > different from the semantics here, especially when setting up a > session with, as an example, an audio stream using English and a video > stream using ASL. (But I can see clients using a default value to set > both the SDP language attribute and the HTTP Content-Language, unless > configured differently.) > > As for reusing existing mechanisms, the draft does contain two > alternative proposals, one to re-use the existing 'language' SDP > attribute, and one to define a new attribute. > >> - Dependency between media descriptions? >> >> Another example would be a user who is able to speak but is deaf or >> hard-of-hearing and requires a voice stream plus a text stream >> (known as voice carry over). Making language a media attribute >> allows the standard session negotiation mechanism to handle this by >> providing the information and mechanism for the endpoints to make >> appropriate decisions. >> >> This scenario suggests that there might be dependency or interaction >> between language specifications for different media descriptions. >> Whether this is needed should be determined and documented. >> >> - Specifying preference levels? >> >> For example, some users may be able to speak several languages, but >> have a preference. >> >> This might argue for describing degrees of preference using "q" >> parameters (as in the SIP Accept-Language header). >> >> - Expressing multiple languages in answers >> >> (While it is true that a conversation among multilingual people >> often involves multiple languages, it does not seem useful enough >> as a general facility to warrant complicating the desired semantics >> of the SDP attribute to allow negotiation of multiple simultaneous >> languages within an interactive media stream.) >> >> Why shouldn't an answer be able to indicate multiple languages? At >> the least, this might provide the offerer with useful information. > > You raise good questions that I think need more discussion. I am > hoping to keep the work as simple as possible and not add additional > complexity, which argues for not solving every aspect of the problem, > but only those that must be solved immediately. > >> >> - Reusing a=lang >> >> Searching, I can only find these descriptions of the use of >> "a=lang:...": >> >> RFC 4566 >> draft-saintandre-sip-xmpp-chat >> draft-gellens-negotiating-human-language >> >> So it looks like "a=lang:..." is entirely unused at the present and is >> safe to be redefined. > > > > > --------------040800080507030709090604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Before this discussion got its home in mmusic, we discussed quite similar topics as you, Dale brought up now.

It was about what was needed to be expressed by the parameters and if SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could be a suitable mechanism for routing and decisions on the parameters.

Here is part of that discussion that we need to capture.


I see some complication that might be needed in order to reflect reality. At least they should be discussed.

And I am also seeing some different ways to specify it.

The complications to discuss are:

1. Level of preference.

There may be a need for specifying levels of preference for languages.  I might strongly prefer to talk English, but have some useful capability in French. I want to display that preference and that capability with that difference, so that I get English whenever possible, but get the call connected even if English is not available at all but French is.

I would assume that two levels are sufficient, but that can be discussed:  Preferred and capable.

The draft already proposes that languages be listed in order of preference, which should handle the example you mention: you list English first and French second.  The called party selects English if it is capable and falls back to French if English is not and French is.  This seems much simpler and is a common way of handling situations where there is a preference.  It would be good to keep the mechanism as simple as possible.
Yes, I am afraid of complicating this beyond the point when users do not manage to get their settings right.
Still, I do not think that the order is sufficient as level of preference indicator. You may want to indicate capability for one modality but preference for another. ( as my example, capability for ASL, but preference for talking and reading )

If you have a capability for ASL but preference for talking and reading, you could initially offer two media streams: a voice with English and a text with English.  If accepted, you have your preferred communications.  If those are rejected you could then offer video with ASL.  Would that handle the case?
No, video is still very valuable for judging the emergency case. Or seeing a friend. So, if you support it you want to offer it. But the decision on languages and modalities may end up in video being not important for language communication.




2. Directionality
There is a need for a direction of the language preference. "Transmit, receive or both". or   "Produce, perceive or both". That is easy to understand for the relay service examples.
A hard-of-hearing user may declare:

Text, capable, produce, English
Text, prefer, perceive, English
Audio, prefer, produce, English
Audio, capable, perceive, English    ( tricky, a typical hard-of-hearing user may have benefit of receiving audio, while it is not usable enough for reliable perception. I do not want to see this eternally complex, but I see a need for refined expressions here)
video, capable, both, ASL 

This should be understood as that the user prefers to speak and get text back, and has benefit of getting voice in parallel with text.  ASL signing can be an alternative if the other party has corresponding capability or preference.


The draft does support this (and even mentions some of these specific uses) because it proposes an SDP media attribute, and media can be specified to be send, receive, or both.
No, that is not the same. You want the media to flow, but by the parameter you want to indicate your preference for how to use it.  You do not want to turn off incoming audio just because you prefer to talk but read text.

Yes, I see, thanks for the clarification.  Does this need to be part of the session setup?  If you establish all media streams that you wish to use, can you then just use them as you prefer?  I will consult with the NENA accessibility committee on this.
No, there are specific services providing service with one direction but not the other. The information is needed for decision on what assisting service to invoke. One such service is the captioned telephony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a very strong preference for getting just that service, but could accept with much lower preference to get a direct conversation with the far end in combined text and voice.


I think it would be useful  to move most of the introduction to a structured use case chapter and express the different cases according to a template. Thast can then be used to test if proposed approaches will work.

I'm not sure I fully understand what you mean by "structured" in "structured use case" or "template."  Can you be more specific?
I mean just a simple template for how the use case descriptions are written.

E.g.
A title indicating what case we have.
Description of the calling user and its capabilities and preferences.
Description of the answering user and its capabilities and preferences
Description of a possible assisting service and its capabilities and preferences
Description of the calling user's indications.
Description of the answering user's indications.
The resulting decision and outcome


3.  Specify language and modality at SIP Media tag level instead.
There could be some benfits to declare these parameters at the SIP media tag level instead of SDP level.
A call center can then register with their capabilities already at the SIP REGISTER time, and the caller preferences / callee capabilities mechanism from RFC 3840/ 3841 can be used to select modalities and languages and route the call to the best capable person or combination of person and assisting interpreting.

Maybe, but one advantage of using SDP is that the ESInet can take language and media needs into account during policy-based routing.  For example, in some European countries emergency calls placed by a speaker of language x in country y may be routed to a PSAP in a country where x is the native language.  Or, there might be regional or national text relay or sign language interpreter services as opposed to PSAP-level capabilities.
Is there a complete specification for how policy based routing is thought to work? Where?
Does it not use RFC 3840/3841?
That procedure is already supported by SIP servers. Using SDP requires new SIP server programming.

NENA has a document under development.  I thought it was able to take SDP into account but I'll look into it, and I'm sure Brian will have something to say.
Yes, I think I have seen that. But it needs to come into IETF to be possible to refer to.


But, on the other hand, then we need a separate specification of what modality the parameters indicate, because the language tags only distinguish between signed and other languages, and "other" seems to mean either spoken or written without any difference.


The SDP media already indicates the type (audio, video, text).
Yes, convenient. But there is no knowledge about the parameters until at call time. It could be better to know the callee capabilities in advance if available. Then middle boxes can do the routing instead of the far end. There may be many terminals competing for the call and the comparison about who to get it should be done by a sip server instead of an endpoint.

I think call time is the right time.  For emergency calls, it isolates the decision making about how to process calls requiring text, sign language, foreign language, etc. to the ESInet and PSAPs, which is I think the right place.  The processing rules in the ESInet can then be changed without involving any carrier.  The capabilities of an entity may vary based on dynamic factors (time of day, load, etc.) so the decision as to how to support a need may be best made by the ESInet or PSAP in the case of an emergency call, or called party for non-emergency calls.  For example, at some times or under some loads, emergency calls may be routed to a specific PSAP that is not the geographically indicated one.  Likewise, a non-emergency call to a call center may be routed to a center in a country that has support for the language or media needed.
The decision is of course made at call time. With the RFC 3840/3841 method, the different agents and services available register their availability and capabilities when they go on duty, and unregister when they stop, so that their information is available at call time.
 

Further, it is often the case that the cost of relay, interpretation, or translation services is affected by which entity invokes the service.
Yes, that is a complicating policy issue.


4. Problem that 3GPP specifies that it is the UAs only who specify and act on these parameters.
I think it is a problem that 3GPP inserted the restriction that the language and modality negotiation shall only bother the involved UAs.
It would be more natural that it is a service provider between them who detect the differences and make the decision to invoke a relay service for the relay case.
How do you propose to solve that? Let the service provider behave as a B2BUA, who then can behave as both a UA and a service provider?

What do you mean by "service provider?"  In the case of a voice service provider such as a cellular carrier or a VoIP provider, I think this should be entirely transparent.  The voice service provider knows it is an emergency call and routes to an ESInet.  It is then up to the ESInet and the PSAPs to handle the call as they wish.
It can be a service provider for just the function to make advanced call invocation based on language preferences. The same type of decisions, call connections and assisting service invocation are needed in everyday calls as in emergency calls. But it can also be a service provider for emergency services and the user is registered by that service provider. They can make decisions on the call. E.g. detect that it is an emergency call requiring interpreter, and therefore connect to both the PSAP and interpreter at the same time to save time.

I think it's best to make these decisions at the end, not the middle.  In the case of emergency calls, the ESInet can route to a particular PSAP, the PSAP may bridge in translation or interpretation services, etc.  In the case of non-emergency calls, the call center may support some capabilities locally at some hours but route to a different call center at other times.
The end is not decided until you have evaluated the alternative possible ends and decided who has the right capability and preference.



There is another issue with using sdp for decisions. SIP Message is included in the set of methods to handle in emergency calls in RFC 6443. It can be used within sessions to carry text messages if other media are used as well. It is no favored way to have text communication, but possible. SIP message has no sdp.  I know that the 3GPP sections  about emergency calling in TS 22.101 points towards using MSRP for text messaging, so it should not be an issue for 3GPP. Can we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media?  I do not urge for solving it for SIP Message, I just wanted to point out that result by basing the mechanism on SDP.

 




Will there be a possibility for remote participation on Thursday. I am sorry I am not there, but would like to participate if possible.
/Gunnar

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-03-11 16:57, Randall Gellens wrote:
[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:

 (It's not clear to me what the proper mailing list is to discuss this
 draft.  From the headers of the messages, it appears that the primary
 list is ietf@ietf.org, but the first message in this thread about that
 draft already has a "Re:" in the subject line, so the discussion
 started somewhere else.)

There has been some discussion among those listed in the CC header of this message.  I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft.

By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal).  Please let me know if you can make it.

 (Also, it's not clear why Randall's messages are coming through in
 HTML.)

My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well.


 But onward to questions of substance:

 - Why SDP and not SIP?

 I'd like to see a more thorough exploration of why language
 negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
 uses the Content-Language header to specify languages.)  In principle,
 specifying data that may be used in call-routing should be done in the
 SIP layer, but it's well-accepted in the SIP world that call routing
 may be affected by the SDP content as well (e.g., media types).

I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video.


 And some discussion and comparison should be done with the SIP/HTTP
 Content-Language header (used to specify the language of the
 communications) and the SIP Accept-Language header (used to specify
 the language of text components of SIP messages), particularly given
 that Accept-Language has different set of language specifiers and a
 richer syntax for specifying preferences.  In any case, preference
 should be given to reusing one of the existing syntaxes for specifying
 language preferences.

I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL.  (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.)

As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute.

 - Dependency between media descriptions?

    Another example would be a user who is able to speak but is deaf or
    hard-of-hearing and requires a voice stream plus a text stream
    (known as voice carry over).  Making language a media attribute
    allows the standard session negotiation mechanism to handle this by
    providing the information and mechanism for the endpoints to make
    appropriate decisions.

 This scenario suggests that there might be dependency or interaction
 between language specifications for different media descriptions.
 Whether this is needed should be determined and documented.

 - Specifying preference levels?

    For example, some users may be able to speak several languages, but
    have a preference.

 This might argue for describing degrees of preference using "q"
 parameters (as in the SIP Accept-Language header).

 - Expressing multiple languages in answers

    (While it is true that a conversation among multilingual people
    often involves multiple languages, it does not seem useful enough
    as a general facility to warrant complicating the desired semantics
    of the SDP attribute to allow negotiation of multiple simultaneous
    languages within an interactive media stream.)

 Why shouldn't an answer be able to indicate multiple languages?  At
 the least, this might provide the offerer with useful information.

You raise good questions that I think need more discussion.  I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately.


 - Reusing a=lang

 Searching, I can only find these descriptions of the use of
 "a=lang:...":

     RFC 4566
     draft-saintandre-sip-xmpp-chat
     draft-gellens-negotiating-human-language

 So it looks like "a=lang:..." is entirely unused at the present and is
 safe to be redefined.






--------------040800080507030709090604-- From worley@shell01.TheWorld.com Mon Mar 11 14:51:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B621F8FA3 for ; Mon, 11 Mar 2013 14:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, 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 V58czYN+LMRp for ; Mon, 11 Mar 2013 14:51:11 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68821F8F3E for ; Mon, 11 Mar 2013 14:51:11 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BLod24032645; Mon, 11 Mar 2013 17:50:41 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BLod6g234124; Mon, 11 Mar 2013 16:50:39 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BLocqs234131; Mon, 11 Mar 2013 17:50:38 -0400 (EDT) Date: Mon, 11 Mar 2013 17:50:38 -0400 (EDT) Message-Id: <201303112150.r2BLocqs234131@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Ejzak, Richard P (Richard)" In-reply-to: <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> (richard.ejzak@alcatel-lucent.com) References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:51:12 -0000 > From: "Ejzak, Richard P (Richard)" > > > it does not see media. (It does not suffice for the answerer to > > provide a null transport address and non-zero port for the MD, or for > > the answerer to send "a=inactive", as an intermediate entity may see > > the MD as being accepted and expect the offerer to send RTCP.) > > Considering the following text from RFC 3264: > > "Of course, when used, the port number MUST NOT be zero, which would > specify that the stream has been disabled. An agent MUST be capable > of receiving SDP with a connection address of 0.0.0.0, in which case > it means that neither RTP nor RTCP should be sent to the peer." > > There is no ambiguity here about the meaning of zero port. > > While this text could be interpreted to not specifically preclude > the peer that indicates an unspecified address from sending RTCP to > the peer indicating a valid address, this seems really far-fetched > to me. Sending this RTCP would be pointless and wasteful since by > definition it would have nothing to report on and there is no > possibility to receive reports. > > If would be nice to eliminate this ambiguity by ending the quoted > sentence "...neither RTP nor RTCP should be sent to either peer." > > The text also says that the peer indicating an unspecified address > "...doesn't know the addresses and ports at the time..." Again, it > seems like a real stretch to assume that the peer can send RTCP if > it doesn't have an address or port available for receipt of RTP. Sorry, I was hasty in writing the message. What I should have said is (It does not suffice for the answerer to provide a null transport address and non-zero port for the MD, or for the answerer to send "a=inactive", as an intermediate entity may see the MD as being accepted and expect the answerer to send RTCP.) ^^^^^^^^ The problem being that an offer with a real address and an answer with a null address historically has meant that the answerer has put the call on hold; the answerer is expected to send media to the offerer but the offerer is not expected to send media to the answerer. The answerer is also expected to send RTCP, but of course the offerer cannot send RTCP (as it has no address to send it to). If the answerer specifies "a=inactive" with a real address, then neither the offerer nor the answerer should send media, but both are expected to send RTCP: RFC 4566, section 6, item "a=inactive" a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. [...] Combining the two techniques suppresses everything but expectation of RTCP from the answerer to the offerer. Unfortunately, I expect dialog-stateful SBCs to pay attention to that RTCP in order to time out abandoned dialogs. Dale From francois.audet@skype.net Mon Mar 11 15:24:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AFE21F8E4C for ; Mon, 11 Mar 2013 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=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 QsD9OhsUzN-P for ; Mon, 11 Mar 2013 15:24:50 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.25]) by ietfa.amsl.com (Postfix) with ESMTP id E488321F8B4C for ; Mon, 11 Mar 2013 15:24:49 -0700 (PDT) Received: from BY2SR01CA104.namsdf01.sdf.exchangelabs.com (10.255.93.149) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.0.651.5; Mon, 11 Mar 2013 22:24:44 +0000 Received: from SN2FFOFD004.ffo.gbl (157.55.158.26) by BY2SR01CA104.outlook.office365.com (10.255.93.149) with Microsoft SMTP Server (TLS) id 15.0.651.5 via Frontend Transport; Mon, 11 Mar 2013 22:24:44 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.17) by SN2FFOFD004.mail.o365filtering.com (10.111.201.41) with Microsoft SMTP Server (TLS) id 15.0.641.0 via Frontend Transport; Mon, 11 Mar 2013 22:24:44 +0000 Received: from DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.123.1; Mon, 11 Mar 2013 15:24:15 -0700 Received: from DFM-DB3MBX15-07.exchange.corp.microsoft.com (10.166.18.225) by DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) with Microsoft SMTP Server (TLS) id 15.0.620.14; Mon, 11 Mar 2013 15:23:53 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com (10.166.18.224) by DFM-DB3MBX15-07.exchange.corp.microsoft.com (10.166.18.225) with Microsoft SMTP Server (TLS) id 15.0.620.14; Mon, 11 Mar 2013 15:23:50 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com ([169.254.10.250]) by DFM-DB3MBX15-06.exchange.corp.microsoft.com ([169.254.10.155]) with mapi id 15.00.0620.012; Mon, 11 Mar 2013 15:23:50 -0700 From: Francois Audet To: Gunnar Hellstrom , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-gellens-negotiating-human-language-02 Thread-Index: AQHOHqHkW+vZghnZxUGfZiQe0zOl0ZihDnRw Date: Mon, 11 Mar 2013 22:23:50 +0000 Message-ID: References: <513E504F.1010209@omnitor.se> In-Reply-To: <513E504F.1010209@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51694001)(377424002)(199002)(189002)(24454001)(479174001)(52034002)(51914002)(51444002)(47736001)(16406001)(5343655001)(33646001)(74502001)(20776003)(4396001)(63696002)(47446002)(80022001)(56776001)(47976001)(56816002)(512934001)(66066001)(54316002)(46102001)(5343635001)(59766001)(77982001)(16236675001)(31966008)(15202345002)(54356001)(65816001)(50986001)(876001)(561944001)(44976002)(51856001)(53806001)(16297215001)(74662001)(79102001)(76482001)(49866001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB609; H:hybrid.exchange.microsoft.com; RD:mail1.exchange.microsoft.com; A:1; MX:1; LANG:en; X-Forefront-PRVS: 0782EC617F X-OriginatorOrg: msft.ccsctp.net Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:25:00 -0000 --_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I tought about this a while ago. I guess this is a contact center scenario. While it would certainly be possible to express your caller pref using q-va= lues, it seems the wrong way to approach the problem. Really, what you want= is the caller resource to be of a specific language. Therefore, I think th= at rather, the URL itself should have the information to map it to the appr= opriate agent. Kind of similar to 1-800-help-product, 1800-aide-produit, bu= t with a SIP URI. You could use a parameter sip:help@example.com?lang=3Den = or it could be in the URI itself, SIP:help?example.com/en or SIP:en@example= .com. The calling party would consult the directory and select the desired langua= ge. This approach also eliminates the confusing "feature" of having an answ= er in a different language than you expect... My 2 cents. From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Gunnar Hellstrom Sent: Monday, March 11, 2013 2:45 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 Before this discussion got its home in mmusic, we discussed quite similar t= opics as you, Dale brought up now. It was about what was needed to be expressed by the parameters and if SDP o= r SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could= be a suitable mechanism for routing and decisions on the parameters. Here is part of that discussion that we need to capture. I see some complication that might be needed in order to reflect reality. A= t least they should be discussed. And I am also seeing some different ways to specify it. The complications to discuss are: 1. Level of preference. There may be a need for specifying levels of preference for languages. I m= ight strongly prefer to talk English, but have some useful capability in Fr= ench. I want to display that preference and that capability with that diffe= rence, so that I get English whenever possible, but get the call connected = even if English is not available at all but French is. I would assume that two levels are sufficient, but that can be discussed: = Preferred and capable. The draft already proposes that languages be listed in order of preference,= which should handle the example you mention: you list English first and Fr= ench second. The called party selects English if it is capable and falls b= ack to French if English is not and French is. This seems much simpler and= is a common way of handling situations where there is a preference. It wo= uld be good to keep the mechanism as simple as possible. Yes, I am afraid of complicating this beyond the point when users do not ma= nage to get their settings right. Still, I do not think that the order is sufficient as level of preference i= ndicator. You may want to indicate capability for one modality but preferen= ce for another. ( as my example, capability for ASL, but preference for tal= king and reading ) If you have a capability for ASL but preference for talking and reading, yo= u could initially offer two media streams: a voice with English and a text = with English. If accepted, you have your preferred communications. If tho= se are rejected you could then offer video with ASL. Would that handle the= case? No, video is still very valuable for judging the emergency case. Or seeing = a friend. So, if you support it you want to offer it. But the decision on l= anguages and modalities may end up in video being not important for languag= e communication. 2. Directionality There is a need for a direction of the language preference. "Transmit, rece= ive or both". or "Produce, perceive or both". That is easy to understand = for the relay service examples. A hard-of-hearing user may declare: Text, capable, produce, English Text, prefer, perceive, English Audio, prefer, produce, English Audio, capable, perceive, English ( tricky, a typical hard-of-hearing us= er may have benefit of receiving audio, while it is not usable enough for r= eliable perception. I do not want to see this eternally complex, but I see = a need for refined expressions here) video, capable, both, ASL This should be understood as that the user prefers to speak and get text ba= ck, and has benefit of getting voice in parallel with text. ASL signing ca= n be an alternative if the other party has corresponding capability or pref= erence. The draft does support this (and even mentions some of these specific uses)= because it proposes an SDP media attribute, and media can be specified to = be send, receive, or both. No, that is not the same. You want the media to flow, but by the parameter = you want to indicate your preference for how to use it. You do not want to= turn off incoming audio just because you prefer to talk but read text. Yes, I see, thanks for the clarification. Does this need to be part of the= session setup? If you establish all media streams that you wish to use, c= an you then just use them as you prefer? I will consult with the NENA acce= ssibility committee on this. No, there are specific services providing service with one direction but no= t the other. The information is needed for decision on what assisting servi= ce to invoke. One such service is the captioned telephony, that adds rapidl= y created speech-to-text in parallel with the voice. They provide just that= . A user will have a very strong preference for getting just that service, = but could accept with much lower preference to get a direct conversation wi= th the far end in combined text and voice. I think it would be useful to move most of the introduction to a structure= d use case chapter and express the different cases according to a template.= Thast can then be used to test if proposed approaches will work. I'm not sure I fully understand what you mean by "structured" in "structure= d use case" or "template." Can you be more specific? I mean just a simple template for how the use case descriptions are written= . E.g. A title indicating what case we have. Description of the calling user and its capabilities and preferences. Description of the answering user and its capabilities and preferences Description of a possible assisting service and its capabilities and prefer= ences Description of the calling user's indications. Description of the answering user's indications. The resulting decision and outcome 3. Specify language and modality at SIP Media tag level instead. There could be some benfits to declare these parameters at the SIP media ta= g level instead of SDP level. A call center can then register with their capabilities already at the SIP = REGISTER time, and the caller preferences / callee capabilities mechanism f= rom RFC 3840/ 3841 can be used to select modalities and languages and route= the call to the best capable person or combination of person and assisting= interpreting. Maybe, but one advantage of using SDP is that the ESInet can take language = and media needs into account during policy-based routing. For example, in = some European countries emergency calls placed by a speaker of language x i= n country y may be routed to a PSAP in a country where x is the native lang= uage. Or, there might be regional or national text relay or sign language = interpreter services as opposed to PSAP-level capabilities. Is there a complete specification for how policy based routing is thought t= o work? Where? Does it not use RFC 3840/3841? That procedure is already supported by SIP servers. Using SDP requires new = SIP server programming. NENA has a document under development. I thought it was able to take SDP i= nto account but I'll look into it, and I'm sure Brian will have something t= o say. Yes, I think I have seen that. But it needs to come into IETF to be possibl= e to refer to. But, on the other hand, then we need a separate specification of what modal= ity the parameters indicate, because the language tags only distinguish bet= ween signed and other languages, and "other" seems to mean either spoken or= written without any difference. The SDP media already indicates the type (audio, video, text). Yes, convenient. But there is no knowledge about the parameters until at ca= ll time. It could be better to know the callee capabilities in advance if a= vailable. Then middle boxes can do the routing instead of the far end. Ther= e may be many terminals competing for the call and the comparison about who= to get it should be done by a sip server instead of an endpoint. I think call time is the right time. For emergency calls, it isolates the = decision making about how to process calls requiring text, sign language, f= oreign language, etc. to the ESInet and PSAPs, which is I think the right p= lace. The processing rules in the ESInet can then be changed without invol= ving any carrier. The capabilities of an entity may vary based on dynamic = factors (time of day, load, etc.) so the decision as to how to support a ne= ed may be best made by the ESInet or PSAP in the case of an emergency call,= or called party for non-emergency calls. For example, at some times or un= der some loads, emergency calls may be routed to a specific PSAP that is no= t the geographically indicated one. Likewise, a non-emergency call to a ca= ll center may be routed to a center in a country that has support for the l= anguage or media needed. The decision is of course made at call time. With the RFC 3840/3841 method,= the different agents and services available register their availability an= d capabilities when they go on duty, and unregister when they stop, so that= their information is available at call time. Further, it is often the case that the cost of relay, interpretation, or tr= anslation services is affected by which entity invokes the service. Yes, that is a complicating policy issue. 4. Problem that 3GPP specifies that it is the UAs only who specify and act = on these parameters. I think it is a problem that 3GPP inserted the restriction that the languag= e and modality negotiation shall only bother the involved UAs. It would be more natural that it is a service provider between them who det= ect the differences and make the decision to invoke a relay service for the= relay case. How do you propose to solve that? Let the service provider behave as a B2BU= A, who then can behave as both a UA and a service provider? What do you mean by "service provider?" In the case of a voice service pro= vider such as a cellular carrier or a VoIP provider, I think this should be= entirely transparent. The voice service provider knows it is an emergency= call and routes to an ESInet. It is then up to the ESInet and the PSAPs t= o handle the call as they wish. It can be a service provider for just the function to make advanced call in= vocation based on language preferences. The same type of decisions, call co= nnections and assisting service invocation are needed in everyday calls as = in emergency calls. But it can also be a service provider for emergency ser= vices and the user is registered by that service provider. They can make de= cisions on the call. E.g. detect that it is an emergency call requiring int= erpreter, and therefore connect to both the PSAP and interpreter at the sam= e time to save time. I think it's best to make these decisions at the end, not the middle. In t= he case of emergency calls, the ESInet can route to a particular PSAP, the = PSAP may bridge in translation or interpretation services, etc. In the cas= e of non-emergency calls, the call center may support some capabilities loc= ally at some hours but route to a different call center at other times. The end is not decided until you have evaluated the alternative possible en= ds and decided who has the right capability and preference. There is another issue with using sdp for decisions. SIP Message is include= d in the set of methods to handle in emergency calls in RFC 6443. It can be= used within sessions to carry text messages if other media are used as wel= l. It is no favored way to have text communication, but possible. SIP messa= ge has no sdp. I know that the 3GPP sections about emergency calling in T= S 22.101 points towards using MSRP for text messaging, so it should not be = an issue for 3GPP. Can we neglect SIP Message from the discussion and aim a= t solving it only for real-time conversational media? I do not urge for so= lving it for SIP Message, I just wanted to point out that result by basing = the mechanism on SDP. Will there be a possibility for remote participation on Thursday. I am sorr= y I am not there, but would like to participate if possible. /Gunnar ________________________________ Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-03-11 16:57, Randall Gellens wrote: [[[ resending without Cc list ]]] Hi Dale, At 11:00 AM -0500 2/25/13, Dale R. Worley wrote: (It's not clear to me what the proper mailing list is to discuss this draft. From the headers of the messages, it appears that the primary list is ietf@ietf.org, but the first message in this= thread about that draft already has a "Re:" in the subject line, so the discussion started somewhere else.) There has been some discussion among those listed in the CC header of this = message. I think the mmusic list is probably the right place to continue t= he discussion and was planning on doing so more formally with the next revi= sion of the draft. By the way, the draft was updated and is now at -02: http://www.ietf.org/in= ternet-drafts/draft-gellens-negotiating-human-language-02.txt There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (th= e cafe in the Caribe Royal). Please let me know if you can make it. (Also, it's not clear why Randall's messages are coming through in HTML.) My apologies; I have gotten in the habit when replying to messages that hav= e style to allow Eudora to send my reply styled as well. But onward to questions of substance: - Why SDP and not SIP? I'd like to see a more thorough exploration of why language negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, uses the Content-Language header to specify languages.) In principle, specifying data that may be used in call-routing should be done in the SIP layer, but it's well-accepted in the SIP world that call routing may be affected by the SDP content as well (e.g., media types). I think it fits more naturally in SDP since the language is related to the = media, e.g., English for audio and ASL for video. And some discussion and comparison should be done with the SIP/HTTP Content-Language header (used to specify the language of the communications) and the SIP Accept-Language header (used to specify the language of text components of SIP messages), particularly given that Accept-Language has different set of language specifiers and a richer syntax for specifying preferences. In any case, preference should be given to reusing one of the existing syntaxes for specifying language preferences. I think the semantics of Content-Language and Accept-Language are different= from the semantics here, especially when setting up a session with, as an = example, an audio stream using English and a video stream using ASL. (But = I can see clients using a default value to set both the SDP language attrib= ute and the HTTP Content-Language, unless configured differently.) As for reusing existing mechanisms, the draft does contain two alternative = proposals, one to re-use the existing 'language' SDP attribute, and one to = define a new attribute. - Dependency between media descriptions? Another example would be a user who is able to speak but is deaf or hard-of-hearing and requires a voice stream plus a text stream (known as voice carry over). Making language a media attribute allows the standard session negotiation mechanism to handle this by providing the information and mechanism for the endpoints to make appropriate decisions. This scenario suggests that there might be dependency or interaction between language specifications for different media descriptions. Whether this is needed should be determined and documented. - Specifying preference levels? For example, some users may be able to speak several languages, but have a preference. This might argue for describing degrees of preference using "q" parameters (as in the SIP Accept-Language header). - Expressing multiple languages in answers (While it is true that a conversation among multilingual people often involves multiple languages, it does not seem useful enough as a general facility to warrant complicating the desired semantics of the SDP attribute to allow negotiation of multiple simultaneous languages within an interactive media stream.) Why shouldn't an answer be able to indicate multiple languages? At the least, this might provide the offerer with useful information. You raise good questions that I think need more discussion. I am hoping to= keep the work as simple as possible and not add additional complexity, whi= ch argues for not solving every aspect of the problem, but only those that = must be solved immediately. - Reusing a=3Dlang Searching, I can only find these descriptions of the use of "a=3Dlang:...": RFC 4566 draft-saintandre-sip-xmpp-chat draft-gellens-negotiating-human-language So it looks like "a=3Dlang:..." is entirely unused at the present and is safe to be redefined. --_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I tought about this a whi= le ago. I guess this is a contact center scenario.

 <= /p>

While it would certainly = be possible to express your caller pref using q-values, it seems the wrong = way to approach the problem. Really, what you want is the caller resource to be of a specific language. Therefore, I think that rath= er, the URL itself should have the information to map it to the appropriate= agent. Kind of similar to 1-800-help-product, 1800-aide-produit, but with = a SIP URI. You could use a parameter sip:help@example.com?lang=3Den or it could be in the URI itself, SIP:help?example.com/en or SIP:en@example.com.

 <= /p>

The calling party would c= onsult the directory and select the desired language. This approach also el= iminates the confusing “feature” of having an answer in a different language than you expect…

 <= /p>

My 2 cents.

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@= ietf.org] On Behalf Of Gunnar Hellstrom
Sent: Monday, March 11, 2013 2:45 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02

 

Before this discussion got its home in mmusic, we di= scussed quite similar topics as you, Dale brought up now.

It was about what was needed to be expressed by the parameters and if SDP o= r SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could= be a suitable mechanism for routing and decisions on the parameters.

Here is part of that discussion that we need to capture.


I see some complication that might be needed in order to reflect reality. A= t least they should be discussed.

And I am also seeing some different ways to specify it.

The complications to discuss are:

1. Level of preference.

There may be a need for specifying levels of preference for languages. = ; I might strongly prefer to talk English, but have some useful capability = in French. I want to display that preference and that capability with that = difference, so that I get English whenever possible, but get the call connected even if English is not available at a= ll but French is.

I would assume that two levels are sufficient, but that can be discussed:&n= bsp; Preferred and capable.

 

The draft already proposes that languages be listed = in order of preference, which should handle the example you mention: you li= st English first and French second.  The called party selects English = if it is capable and falls back to French if English is not and French is.  This seems much simpler and is a co= mmon way of handling situations where there is a preference.  It would= be good to keep the mechanism as simple as possible.

Yes, I am afraid of complicating this beyond the poi= nt when users do not manage to get their settings right.

Still, I do not think that the order is sufficient a= s level of preference indicator. You may want to indicate capability for on= e modality but preference for another. ( as my example, capability for ASL,= but preference for talking and reading )

 

If you have a capability for ASL but preference for = talking and reading, you could initially offer two media streams: a voice w= ith English and a text with English.  If accepted, you have your prefe= rred communications.  If those are rejected you could then offer video with ASL.  Would that handle the case?

No, video is still very valuable for judging the eme= rgency case. Or seeing a friend. So, if you support it you want to offer it= . But the decision on languages and modalities may end up in video being no= t important for language communication.



 

 

2. Directionality
There is a need for a direction of the language preference. "Transmit,= receive or both". or   "Produce, perceive or both"= ;. That is easy to understand for the relay service examples.
A hard-of-hearing user may declare:

Text, capable, produce, English
Text, prefer, perceive, English
Audio, prefer, produce, English
Audio, capable, perceive, English    ( tricky, a typical har= d-of-hearing user may have benefit of receiving audio, while it is not usab= le enough for reliable perception. I do not want to see this eternally comp= lex, but I see a need for refined expressions here)
video, capable, both, ASL 

This should be understood as that the user prefers to speak and get text ba= ck, and has benefit of getting voice in parallel with text.  ASL signi= ng can be an alternative if the other party has corresponding capability or= preference.

 

 

The draft does support this (and even mentions some = of these specific uses) because it proposes an SDP media attribute, and med= ia can be specified to be send, receive, or both.

No, that is not the same. You want the media to flow= , but by the parameter you want to indicate your preference for how to use = it.  You do not want to turn off incoming audio just because you prefe= r to talk but read text.

 

Yes, I see, thanks for the clarification.  Does= this need to be part of the session setup?  If you establish all medi= a streams that you wish to use, can you then just use them as you prefer?&n= bsp; I will consult with the NENA accessibility committee on this.

No, there are specific services providing service wi= th one direction but not the other. The information is needed for decision = on what assisting service to invoke. One such service is the captioned tele= phony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a ver= y strong preference for getting just that service, but could accept with mu= ch lower preference to get a direct conversation with the far end in combin= ed text and voice.

 

 

I think it would be useful  to move most of the= introduction to a structured use case chapter and express the different ca= ses according to a template. Thast can then be used to test if proposed app= roaches will work.

 

I'm not sure I fully understand what you mean by &qu= ot;structured" in "structured use case" or "template.&q= uot;  Can you be more specific?

I mean just a simple template for how the use case d= escriptions are written.

E.g.
A title indicating what case we have.
Description of the calling user and its capabilities and preferences.
Description of the answering user and its capabilities and preferences
Description of a possible assisting service and its capabilities and prefer= ences
Description of the calling user's indications.
Description of the answering user's indications.
The resulting decision and outcome

 



3.  Specify language and modality at SIP Med= ia tag level instead.
There could be some benfits to declare these parameters at the SIP medi= a tag level instead of SDP level.
A call center can then register with their capabilities already at the SIP = REGISTER time, and the caller preferences / callee capabilities mechanism f= rom RFC 3840/ 3841 can be used to select modalities and languages and route= the call to the best capable person or combination of person and assisting interpreting.

 

Maybe, but one advantage of using SDP is that the ES= Inet can take language and media needs into account during policy-based rou= ting.  For example, in some European countries emergency calls placed = by a speaker of language x in country y may be routed to a PSAP in a country where x is the native language. = Or, there might be regional or national text relay or sign language interp= reter services as opposed to PSAP-level capabilities.

Is there a complete specification for how policy bas= ed routing is thought to work? Where?
Does it not use RFC 3840/3841?
That procedure is already supported by SIP servers. Using SDP requires new = SIP server programming.

 

NENA has a document under development.  I thoug= ht it was able to take SDP into account but I'll look into it, and I'm sure= Brian will have something to say.

Yes, I think I have seen that. But it needs to come = into IETF to be possible to refer to.

 

 

But, on the other hand, then we need a separate spec= ification of what modality the parameters indicate, because the language ta= gs only distinguish between signed and other languages, and "other&quo= t; seems to mean either spoken or written without any difference.

 

 

The SDP media already indicates the type (audio, vid= eo, text).

Yes, convenient. But there is no knowledge about the= parameters until at call time. It could be better to know the callee capab= ilities in advance if available. Then middle boxes can do the routing inste= ad of the far end. There may be many terminals competing for the call and the comparison about who to get it sh= ould be done by a sip server instead of an endpoint.

 

I think call time is the right time.  For emerg= ency calls, it isolates the decision making about how to process calls requ= iring text, sign language, foreign language, etc. to the ESInet and PSAPs, = which is I think the right place.  The processing rules in the ESInet can then be changed without involving any c= arrier.  The capabilities of an entity may vary based on dynamic facto= rs (time of day, load, etc.) so the decision as to how to support a need ma= y be best made by the ESInet or PSAP in the case of an emergency call, or called party for non-emergency calls.=   For example, at some times or under some loads, emergency calls may = be routed to a specific PSAP that is not the geographically indicated one.&= nbsp; Likewise, a non-emergency call to a call center may be routed to a center in a country that has support for th= e language or media needed.

The decision is of course made at call time. With th= e RFC 3840/3841 method, the different agents and services available registe= r their availability and capabilities when they go on duty, and unregister = when they stop, so that their information is available at call time.
 

 

Further, it is often the case that the cost of relay= , interpretation, or translation services is affected by which entity invok= es the service.

Yes, that is a complicating policy issue.

 

 

4. Problem that 3GPP specifies that it is the UAs= only who specify and act on these parameters.
I think it is a problem that 3GPP inserted the restriction that the lan= guage and modality negotiation shall only bother the involved UAs.
It would be more natural that it is a service provider between them who det= ect the differences and make the decision to invoke a relay service for the= relay case.
How do you propose to solve that? Let the service provider behave as a B2BU= A, who then can behave as both a UA and a service provider?

 

What do you mean by "service provider?"&nb= sp; In the case of a voice service provider such as a cellular carrier or a= VoIP provider, I think this should be entirely transparent.  The voic= e service provider knows it is an emergency call and routes to an ESInet.  It is then up to the ESInet and the PSAPs to handle th= e call as they wish.

It can be a service provider for just the function t= o make advanced call invocation based on language preferences. The same typ= e of decisions, call connections and assisting service invocation are neede= d in everyday calls as in emergency calls. But it can also be a service provider for emergency services and th= e user is registered by that service provider. They can make decisions on t= he call. E.g. detect that it is an emergency call requiring interpreter, an= d therefore connect to both the PSAP and interpreter at the same time to save time.

 

I think it's best to make these decisions at the end= , not the middle.  In the case of emergency calls, the ESInet can rout= e to a particular PSAP, the PSAP may bridge in translation or interpretatio= n services, etc.  In the case of non-emergency calls, the call center may support some capabilities locally at some hours= but route to a different call center at other times.

The end is not decide= d until you have evaluated the alternative possible ends and decided who ha= s the right capability and preference.



There is another issue with using sdp for decisions. SIP Message is include= d in the set of methods to handle in emergency calls in RFC 6443. It can be= used within sessions to carry text messages if other media are used as wel= l. It is no favored way to have text communication, but possible. SIP message has no sdp.  I know tha= t the 3GPP sections  about emergency calling in TS 22.101 points towar= ds using MSRP for text messaging, so it should not be an issue for 3GPP. Ca= n we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media?  I do = not urge for solving it for SIP Message, I just wanted to point out that re= sult by basing the mechanism on SDP.

 




Will there be a possibility for remote participation on Thursday. I am sorr= y I am not there, but would like to participate if possible.
/Gunnar

On 2013-03-11 16:57, Randall Gellens wrote:

[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:


 (It's not clear to me what the proper mailing = list is to discuss this
 draft.  From the headers of the messages, it appears that the pr= imary
 list is ietf@ietf.org, but the f= irst message in this thread about that
 draft already has a "Re:" in the subject line, so the discu= ssion
 started somewhere else.)


There has been some discussion among those listed in the CC header of this = message.  I think the mmusic list is probably the right place to conti= nue the discussion and was planning on doing so more formally with the next= revision of the draft.

By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-languag= e-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (th= e cafe in the Caribe Royal).  Please let me know if you can make it.


 (Also, it's not clear why Randall's messages a= re coming through in
 HTML.)


My apologies; I have gotten in the habit when replying to messages that hav= e style to allow Eudora to send my reply styled as well.



 But onward to questions of substance:

 - Why SDP and not SIP?

 I'd like to see a more thorough exploration of why language
 negotiation is to be handled in SDP rather than SIP.  (SIP, like= HTTP,
 uses the Content-Language header to specify languages.)  In prin= ciple,
 specifying data that may be used in call-routing should be done in th= e
 SIP layer, but it's well-accepted in the SIP world that call routing =
 may be affected by the SDP content as well (e.g., media types). =


I think it fits more naturally in SDP since the language is related to the = media, e.g., English for audio and ASL for video.



 And some discussion and comparison should be d= one with the SIP/HTTP
 Content-Language header (used to specify the language of the
 communications) and the SIP Accept-Language header (used to specify <= br>  the language of text components of SIP messages), particularly given =
 that Accept-Language has different set of language specifiers and a <= br>  richer syntax for specifying preferences.  In any case, preferen= ce
 should be given to reusing one of the existing syntaxes for specifyin= g
 language preferences.


I think the semantics of Content-Language and Accept-Language are different= from the semantics here, especially when setting up a session with, as an = example, an audio stream using English and a video stream using ASL.  = (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language= , unless configured differently.)

As for reusing existing mechanisms, the draft does contain two alternative = proposals, one to re-use the existing 'language' SDP attribute, and one to = define a new attribute.


 - Dependency between media descriptions?

    Another example would be a user who is able to speak but= is deaf or
    hard-of-hearing and requires a voice stream plus a text = stream
    (known as voice carry over).  Making language a med= ia attribute
    allows the standard session negotiation mechanism to han= dle this by
    providing the information and mechanism for the endpoint= s to make
    appropriate decisions.

 This scenario suggests that there might be dependency or interaction =
 between language specifications for different media descriptions.  Whether this is needed should be determined and documented.

 - Specifying preference levels?

    For example, some users may be able to speak several lan= guages, but
    have a preference.

 This might argue for describing degrees of preference using "q&q= uot;
 parameters (as in the SIP Accept-Language header).

 - Expressing multiple languages in answers

    (While it is true that a conversation among multilingual= people
    often involves multiple languages, it does not seem usef= ul enough
    as a general facility to warrant complicating the desire= d semantics
    of the SDP attribute to allow negotiation of multiple si= multaneous
    languages within an interactive media stream.)

 Why shouldn't an answer be able to indicate multiple languages? = At
 the least, this might provide the offerer with useful information.


You raise good questions that I think need more discussion.  I am hopi= ng to keep the work as simple as possible and not add additional complexity= , which argues for not solving every aspect of the problem, but only those = that must be solved immediately.



 - Reusing a=3Dlang

 Searching, I can only find these descriptions of the use of
 "a=3Dlang:...":

     RFC 4566
     draft-saintandre-sip-xmpp-chat
     draft-gellens-negotiating-human-language

 So it looks like "a=3Dlang:..." is entirely unused at the p= resent and is
 safe to be redefined.





 

--_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_-- From internet-drafts@ietf.org Mon Mar 11 15:32:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC07F21F8E3D; Mon, 11 Mar 2013 15:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 xTs+LfvGPKAe; Mon, 11 Mar 2013 15:32:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BFE21F8E4D; Mon, 11 Mar 2013 15:32:15 -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.42 Message-ID: <20130311223215.16605.60313.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2013 15:32:15 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:32:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : SDP: Session Description Protocol Author(s) : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-08.txt Pages : 50 Date : 2013-03-11 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.stach@siemens-enterprise.com Mon Mar 11 15:35:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44A21F8FB1 for ; Mon, 11 Mar 2013 15:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=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 sTFLs22txF9H for ; Mon, 11 Mar 2013 15:35:20 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 42BCA21F8FAA for ; Mon, 11 Mar 2013 15:35:20 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 73CD723F04BC; Mon, 11 Mar 2013 23:35:19 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 23:35:19 +0100 From: "Stach, Thomas" To: "Dale R. Worley" , "Ejzak, Richard P (Richard)" Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling Thread-Index: AQHOHqKQbqVQWTYTsEWWfsBShL5T/ZihERbQ Date: Mon, 11 Mar 2013 22:35:18 +0000 Message-ID: References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> In-Reply-To: <201303112150.r2BLocqs234131@shell01.TheWorld.com> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:35:21 -0000 Dale, I don't think the hold argument below hold.=20 More inline Dale R. Worley wrote: >> From: "Ejzak, Richard P (Richard)" > >>=20 >>> it does not see media. (It does not suffice for the answerer to >>> provide a null transport address and non-zero port for the MD, or >>> for the answerer to send "a=3Dinactive", as an intermediate entity >>> may see the MD as being accepted and expect the offerer to send >>> RTCP.)=20 >>=20 >> Considering the following text from RFC 3264: >>=20 >> "Of course, when used, the port number MUST NOT be zero, which would >> specify that the stream has been disabled. An agent MUST be capable >> of receiving SDP with a connection address of 0.0.0.0, in which case >> it means that neither RTP nor RTCP should be sent to the peer." >>=20 >> There is no ambiguity here about the meaning of zero port. >>=20 >> While this text could be interpreted to not specifically preclude >> the peer that indicates an unspecified address from sending RTCP to >> the peer indicating a valid address, this seems really far-fetched >> to me. Sending this RTCP would be pointless and wasteful since by >> definition it would have nothing to report on and there is no >> possibility to receive reports. >>=20 >> If would be nice to eliminate this ambiguity by ending the quoted >> sentence "...neither RTP nor RTCP should be sent to either peer." >>=20 >> The text also says that the peer indicating an unspecified address >> "...doesn't know the addresses and ports at the time..." Again, it >> seems like a real stretch to assume that the peer can send RTCP if >> it doesn't have an address or port available for receipt of RTP. >=20 > Sorry, I was hasty in writing the message. What I should have said is >=20 > (It does not suffice for the answerer to > provide a null transport address and non-zero port for > the MD, or for > the answerer to send "a=3Dinactive", as an intermediate > entity may see > the MD as being accepted and expect the answerer to send RTCP.) > ^^^^^^^^ >=20 > The problem being that an offer with a real address and an answer with > a null address historically has meant that the answerer has put the > call on hold;=20 In 2543 hold indicated by the offerer sending 0.0.0.0. It would we awkward if I sent out a valid offer and being suddenly=20 held by the answerer. Further this pratice is no longer recommended since 3264, i.e. I don't we=20 need to bother anymore. I think from the cited text of 3264 it is clear what receipt of 0.0.0.0=20 from the answerer means.=20 Regards Thomas > the answerer is expected to send media to the offerer > but the offerer is not expected to send media to the answerer. The > answerer is also expected to send RTCP, but of course the offerer > cannot send RTCP (as it has no address to send it to). >=20 > If the answerer specifies "a=3Dinactive" with a real address, then > neither the offerer nor the answerer should send media, but both are > expected to send RTCP:=20 >=20 > RFC 4566, section 6, item "a=3Dinactive" >=20 > a=3Dinactive >=20 > This specifies that the tools should be started in inactive > mode. This is necessary for interactive conferences where > users can put other users on hold. No media is sent over an > inactive media stream. Note that an RTP-based system SHOULD > still send RTCP, even if started inactive. [...] >=20 > Combining the two techniques suppresses everything but expectation of > RTCP from the answerer to the offerer. >=20 > Unfortunately, I expect dialog-stateful SBCs to pay attention to that > RTCP in order to time out abandoned dialogs. >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic= From abegen@cisco.com Mon Mar 11 15:35:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83521F8FAA for ; Mon, 11 Mar 2013 15:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 rla7F5T3mCLp for ; Mon, 11 Mar 2013 15:35:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA5E21F8FAB for ; Mon, 11 Mar 2013 15:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=486; q=dns/txt; s=iport; t=1363041320; x=1364250920; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=blWYy8MPOFzUkeumBJHTjhXuqvHkKgqZYwKAJNOUDXY=; b=lmNIvi++NxWX+rFCyyW7iz39EorZcnZncpJEJ5W/xJtvUEBgM6+9lMOl MvRu3MKYo4M6nDYKUg+3J1vWm87sJlc0mGW9yb8PEBsL49pcIa6ivoIgp a4fx+bCcBw8gDpBXGc1uQZJX+M9blBZX88HGIwWlqA3VbNtlDWuxzqqbh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAKhaPlGtJV2a/2dsb2JhbABDhDyBE4ITR7w7aXQWbQeCKwEEIxFXASICBiACBDAVEgQbAYgKAQYFniiOVZJcgSONOoEbgUoyYQOnSoJ9DYIo X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186269216" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 11 Mar 2013 22:35:20 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2BMZKQn030565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 22:35:20 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 17:35:20 -0500 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" Thread-Topic: -08 version for 4566bis Thread-Index: AQHOHqi2jPoPZigj4UmMgOmIM6Svrg== Date: Mon, 11 Mar 2013 22:35:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.252.165] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] -08 version for 4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:35:21 -0000 Q2hhbmdlcyBhcmUgaGVyZToNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtbW11c2ljLXJmYzQ1NjZiaXMtMDgNCg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBjaGFuZ2Vz IChzb3JyeSBmb3IgdGhlIGNoYW5nZXMgcmVzdWx0aW5nIGZyb20gZnJlZQ0Kc3BhY2UvdGFicywg SSBkb24ndCBrbm93IHdoeSB0aGV5IGhhcHBlbmVkIGFzIEkgdXNlZCB0aGUgc2FtZSB0b29sIGZv cg0KeG1sMnJmYyBjb252ZXJzaW9uKS4NCg0KSSBzdXBwb3NlIHRoZSBjaGFpcnMgd291bGQgbGlr ZSB0byBrZWVwIHRoaXMgZHJhZnQgb3BlbiBmb3IgYSBsaXR0bGUgbW9yZQ0Kd2hpbGUuDQoNCi1h Y2JlZ2VuDQoNCg== From richard.ejzak@alcatel-lucent.com Mon Mar 11 15:53:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33721F90D3 for ; Mon, 11 Mar 2013 15:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_18=0.6, 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 Qtl1jyxIdqND for ; Mon, 11 Mar 2013 15:53:01 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5078821F8F37 for ; Mon, 11 Mar 2013 15:53:01 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BMql70028017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 23:52:47 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 23:52:47 +0100 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 18:52:45 -0400 From: "Ejzak, Richard P (Richard)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling Thread-Index: AQHOHgF3Mop2zAIAB0ia8HPK7HA92Zignn4AgABqlJmAAATFgA== Date: Mon, 11 Mar 2013 22:52:45 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> In-Reply-To: <201303112150.r2BLocqs234131@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:53:02 -0000 Agreed that an endpoint signaling a valid address and port is required to b= e capable of receiving RTP and RTCP, irrespective of what is signaled by th= e peer. But ICE cannot succeed without valid addresses/candidates from both endpoin= ts. Consent cannot be established without valid addresses from both endpoi= nts. Many systems require symmetric RTP, which also is not possible withou= t valid addresses from both endpoints. So if either endpoint signals an un= specified address, then packets will not usually be able to flow in either = direction. It is not reasonable (or intelligent) for any intermediate to time out a se= ssion for a lack of packet transmissions that cannot possibly occur (or at = least that frequently cannot occur). This is the only compatibility concer= n identified with the asymmetric use of the unspecified address, but this c= oncern is clearly misplaced for rtcweb applications where ICE and consent a= re mandatory. Richard > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Monday, March 11, 2013 4:51 PM > To: Ejzak, Richard P (Richard) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Difficulties accepting and rejecting with > bundling >=20 > > From: "Ejzak, Richard P (Richard)" > > > > > it does not see media. (It does not suffice for the answerer to > > > provide a null transport address and non-zero port for the MD, or > > > for the answerer to send "a=3Dinactive", as an intermediate entity > may > > > see the MD as being accepted and expect the offerer to send RTCP.) > > > > Considering the following text from RFC 3264: > > > > "Of course, when used, the port number MUST NOT be zero, which would > > specify that the stream has been disabled. An agent MUST be capable > > of receiving SDP with a connection address of 0.0.0.0, in which case > > it means that neither RTP nor RTCP should be sent to the peer." > > > > There is no ambiguity here about the meaning of zero port. > > > > While this text could be interpreted to not specifically preclude the > > peer that indicates an unspecified address from sending RTCP to the > > peer indicating a valid address, this seems really far-fetched to me. > > Sending this RTCP would be pointless and wasteful since by definition > > it would have nothing to report on and there is no possibility to > > receive reports. > > > > If would be nice to eliminate this ambiguity by ending the quoted > > sentence "...neither RTP nor RTCP should be sent to either peer." > > > > The text also says that the peer indicating an unspecified address > > "...doesn't know the addresses and ports at the time..." Again, it > > seems like a real stretch to assume that the peer can send RTCP if it > > doesn't have an address or port available for receipt of RTP. >=20 > Sorry, I was hasty in writing the message. What I should have said is >=20 > (It does not suffice for the answerer to > provide a null transport address and non-zero port for the MD, or > for > the answerer to send "a=3Dinactive", as an intermediate entity may > see > the MD as being accepted and expect the answerer to send RTCP.) > ^^^^^^^^ >=20 > The problem being that an offer with a real address and an answer with > a null address historically has meant that the answerer has put the > call on hold; the answerer is expected to send media to the offerer but > the offerer is not expected to send media to the answerer. The > answerer is also expected to send RTCP, but of course the offerer > cannot send RTCP (as it has no address to send it to). >=20 > If the answerer specifies "a=3Dinactive" with a real address, then > neither the offerer nor the answerer should send media, but both are > expected to send RTCP: >=20 > RFC 4566, section 6, item "a=3Dinactive" >=20 > a=3Dinactive >=20 > This specifies that the tools should be started in inactive > mode. This is necessary for interactive conferences where > users can put other users on hold. No media is sent over an > inactive media stream. Note that an RTP-based system SHOULD > still send RTCP, even if started inactive. [...] >=20 > Combining the two techniques suppresses everything but expectation of > RTCP from the answerer to the offerer. >=20 > Unfortunately, I expect dialog-stateful SBCs to pay attention to that > RTCP in order to time out abandoned dialogs. >=20 > Dale From ietf@meetecho.com Mon Mar 11 16:04:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F005821F8FFD for ; Mon, 11 Mar 2013 16:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=0.082, 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 jaxiTOQZFXzB for ; Mon, 11 Mar 2013 16:04:28 -0700 (PDT) Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FF21F8C71 for ; Mon, 11 Mar 2013 16:04:27 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd01.ad.aruba.it with bizsmtp id AP4Q1l00Z0wzZHu01P4SnR; Tue, 12 Mar 2013 00:04:27 +0100 Date: Mon, 11 Mar 2013 19:03:51 -0700 (PDT) From: Meetecho Team To: mmusic@ietf.org Message-ID: <18552487.11.1363053832000.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_24685282.1363053831999" Subject: [MMUSIC] Meetecho support for MMUSIC session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:04:29 -0000 ------=_Part_10_24685282.1363053831999 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the MMUSIC WG meeting session. Access to the on-line session (including audio and video streams) will be available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/mmusic The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_10_24685282.1363053831999-- From worley@shell01.TheWorld.com Mon Mar 11 18:03:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3B121F8EFD for ; Mon, 11 Mar 2013 18:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 KHau6tIhVQcx for ; Mon, 11 Mar 2013 18:03:05 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id EE94621F8EE6 for ; Mon, 11 Mar 2013 18:03:04 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2C12XhR007157; Mon, 11 Mar 2013 21:02:35 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2C12WVv239046; Mon, 11 Mar 2013 20:02:33 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2C12W0g240047; Mon, 11 Mar 2013 21:02:32 -0400 (EDT) Date: Mon, 11 Mar 2013 21:02:32 -0400 (EDT) Message-Id: <201303120102.r2C12W0g240047@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Ejzak, Richard P (Richard)" In-reply-to: <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> (richard.ejzak@alcatel-lucent.com) References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 01:03:06 -0000 > From: "Ejzak, Richard P (Richard)" > > This is the only compatibility concern identified with the > asymmetric use of the unspecified address, but this concern is > clearly misplaced for rtcweb applications where ICE and consent are > mandatory. I'm not limiting my attention to WebRTC only. Even in situations where WebRTC is gatewayed to existing SIP infrastructure these problems appear. If we restrict ourselves to WebRTC, then we have even more freedom, and in that case, I'd simply remove the rule regarding rejects MDs as members of groups. Dale From wwwrun@rfc-editor.org Mon Mar 11 18:11:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBB221F8D1A for ; Mon, 11 Mar 2013 18:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 HySo+zl4VMzh for ; Mon, 11 Mar 2013 18:11:55 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 176C821F8C87 for ; Mon, 11 Mar 2013 18:11:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB62962186; Mon, 11 Mar 2013 18:11:42 -0700 (PDT) To: fandreas@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, fandreas@cisco.com, ari.keranen@ericsson.com From: RFC Errata System Message-Id: <20130312011142.BB62962186@rfc-editor.org> Date: Mon, 11 Mar 2013 18:11:42 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Editorial Errata Reported] RFC5939 (3545) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 01:11:57 -0000 The following errata report has been submitted for RFC5939, "Session Description Protocol (SDP) Capability Negotiation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5939&eid=3545 -------------------------------------- Type: Editorial Reported by: Dale Worley Section: 3.4.1 Original Text ------------- a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" Corrected Text -------------- a=acap:2 pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" Notes ----- The existing text, with "a=" before "pcfg", is outright syntactically incorrect per the syntax in the first paragraph of the section. The correction is needed for the text to be the intended demonstration of a semantic error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5939 (draft-ietf-mmusic-sdp-capability-negotiation-13) -------------------------------------- Title : Session Description Protocol (SDP) Capability Negotiation Publication Date : September 2010 Author(s) : F. Andreasen Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From fandreas@cisco.com Tue Mar 12 10:39:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1D11E80D2 for ; Tue, 12 Mar 2013 10:39:48 -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 LZHYYKW2EiQd for ; Tue, 12 Mar 2013 10:39:46 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC4E11E80A3 for ; Tue, 12 Mar 2013 10:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=441; q=dns/txt; s=iport; t=1363109985; x=1364319585; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=mfC403nSQf8JQ9HMb1n530JP1iittjQ8SDsIv9x4d+k=; b=Awp4fTxEH+X1ylf8izh5asFqjeZfJ2sFIO6zZy3BkcTSPMHPQJgrd6C8 Yzya3qkSyO1PnktsymzLtgYr8FRGMsw+jVeV9DFDLjg3OFOyGLvY+m7oB GzBf2dWcOdSsqzTaylBUrw8f60jhFYX1iA5uX3eROYyWNK/wAHHszc2IT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPdmP1GrRDoJ/2dsb2JhbABDh1C+ZRZ0gmhAPRYYAwIBAgFLDQgBAQWICg2gQJEVj3+SVAOWVpB2gyYg X-IronPort-AV: E=Sophos;i="4.84,832,1355097600"; d="scan'208";a="75224199" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 12 Mar 2013 17:39:44 +0000 Received: from dhcp-170e.meeting.ietf.org ([10.86.252.241]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2CHdhSN015317 for ; Tue, 12 Mar 2013 17:39:44 GMT Message-ID: <513F685F.3010503@cisco.com> Date: Tue, 12 Mar 2013 13:39:43 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC slight agenda reordering for Tuesday X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:39:51 -0000 Just a heads-up that we've had to move the "ICE Mobility" and "Happy Eyeballs" presentations to the end of the agenda today. This implies that traffic-class, Trickle ICE and RTCWEB/CLUE related drafts discussion will start 20 minutes earlier than previously announced. Updated agenda times here (may need to refresh your browser): http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic Thanks Ari & Flemming From martin.thomson@gmail.com Tue Mar 12 13:32:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34211E8179 for ; Tue, 12 Mar 2013 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Id-KDQ5TxhIZ for ; Tue, 12 Mar 2013 13:32:19 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E4DA911E8168 for ; Tue, 12 Mar 2013 13:32:18 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so287199wey.5 for ; Tue, 12 Mar 2013 13:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=izyID2PetmnbPzhhGYEoz5Lgg5cEM2eL6Tb/DWqMCSc=; b=Qo7zAmTn2eTElxsQjniFTt1h9Fczvs9eNg6S+gjhYHZVs6O6X27NoHo5NVd+ofiFFr zTs/6iQuIdsCVcfvM/K4CJKgJhHaBOoQrzMhgoZ4ovaolG2mzzk3clB9Mn/db3UV9zUa Hj+fWzV/hAabNFWIU8DNO3R3RKW84MR/xHf9M0wo+votD84lTuja6YNHusELYl0J4tdl ytuMHVKS53Cyq+oejfk2+v/Andm+fMTArpjBMHMs4lnrWxeo5puTnameAVik5016j6nb QCcwbmciXto9Q7FJlRo9ycp2Srf4wo8hXGjjC363jvEkpBhuVf11D8gPdihnqJgYK5pM 0Wjw== MIME-Version: 1.0 X-Received: by 10.194.91.211 with SMTP id cg19mr29685442wjb.43.1363120338016; Tue, 12 Mar 2013 13:32:18 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Tue, 12 Mar 2013 13:32:17 -0700 (PDT) Date: Tue, 12 Mar 2013 16:32:17 -0400 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c6f2898abb04d7c02faa Subject: [MMUSIC] Trickle algorithm option X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:32:19 -0000 --047d7bf0c6f2898abb04d7c02faa Content-Type: text/plain; charset=UTF-8 Form a pseudo-checklist from the first (and highest component/stream) candidate pair on each foundation. Use that ahead of all other components/streams. Note that new pairs can arrive in this checklist after commencing, these need to be inserted into the priority. Once a foundation resolves, progress in order, favouring pairs that are present over ones that are not ;) If a higher priority foundation resolves on the pseudo-checklist, you MAY switch to that foundation, abandoning the checks on the first successful foundation. Rinse and repeat as desired (until the end). --047d7bf0c6f2898abb04d7c02faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Form a pseudo-checklist from the first= (and highest component/stream) candidate pair on each foundation.=C2=A0 Us= e that ahead of all other components/streams.

Note that new pa= irs can arrive in this checklist after commencing, these need to be inserte= d into the priority.

Once a foundation resolves, progress in order, favouring pairs th= at are present over ones that are not ;)

If a higher prio= rity foundation resolves on the pseudo-checklist, you MAY switch to that fo= undation, abandoning the checks on the first successful foundation.=C2=A0 R= inse and repeat as desired (until the end).
--047d7bf0c6f2898abb04d7c02faa-- From ietf@meetecho.com Tue Mar 12 16:17:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A573011E80F0 for ; Tue, 12 Mar 2013 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=0.059, 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 FRphs-e1YP7D for ; Tue, 12 Mar 2013 16:17:58 -0700 (PDT) Received: from smtpdg1.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADF611E80E1 for ; Tue, 12 Mar 2013 16:17:57 -0700 (PDT) Received: from dell-tcastaldi ([130.129.130.228]) by smtpcmd01.ad.aruba.it with bizsmtp id AnHs1l00k4voso201nHuZi; Wed, 13 Mar 2013 00:17:55 +0100 Date: Tue, 12 Mar 2013 19:17:50 -0400 (EDT) From: Meetecho Team To: mmusic@ietf.org Message-ID: <4916061.1.1363130270643.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_9166034.1363130270600" Subject: [MMUSIC] MMUSIC session recording available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 23:17:58 -0000 ------=_Part_0_9166034.1363130270600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the MMUSIC WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#MMUSIC In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_9166034.1363130270600-- From internet-drafts@ietf.org Wed Mar 13 06:39:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7862521F85DC; Wed, 13 Mar 2013 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qXnLg5TpC-9Z; Wed, 13 Mar 2013 06:39:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5B121F8651; Wed, 13 Mar 2013 06:39:20 -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.42 Message-ID: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 06:39:20 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:39:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Pages : 21 Date : 2013-03-13 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Wed Mar 13 08:09:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C77F21F8DFF for ; Wed, 13 Mar 2013 08:09:11 -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 kVl2b4LKJqXF for ; Wed, 13 Mar 2013 08:09:10 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E13AE21F89AA for ; Wed, 13 Mar 2013 08:09:09 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2DF8rJ6008074; Wed, 13 Mar 2013 17:09:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 17:08:57 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0328.011; Wed, 13 Mar 2013 15:08:56 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8w Date: Wed, 13 Mar 2013 15:08:56 +0000 Message-ID: References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> In-Reply-To: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWkPb3JY0xFuatV6kzCBSrLWTKSsnTttdHvHk18KwzhuGNHLHDTB8SyQdAjv67EQCzBcYkvF3ODXzvXu9mc5dNpHipUn+wP3jCy2zmpZkbAAMMsKYLax7Exex4bJRVuqHfN+hgHFZFeNEisRXMBghp3Ex829RgVgrc49gJ5p3QwvGWqZMErtIj+h8pB8n/ONRrfpKBjiCI/RYCTHtbDgk1UwYGsUPFqJsaj5jkWZkp1Kg= x-originating-ip: [10.163.150.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2013 15:08:57.0222 (UTC) FILETIME=[AF37EA60:01CE1FFC] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 15:09:11 -0000 Hello, We just submitted a new version of the miscellaneous-caps draft, with text = that states that if the connection data capability attribute (a=3Dccap) is = used the port number in the resulting SDP MUST be the same as in the origin= al "m=3D" line, except for PSTN type bearers (when the port number used is = 9). Regards, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 13. maaliskuuta 2013 15:39 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Pages : 21 Date : 2013-03-13 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line fo= r each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mohamed.boucadair@orange.com Wed Mar 13 08:20:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8221F8E01 for ; Wed, 13 Mar 2013 08:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 mPkJRmQosTuf for ; Wed, 13 Mar 2013 08:20:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6293121F8DFC for ; Wed, 13 Mar 2013 08:20:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 65EE222CDCB; Wed, 13 Mar 2013 16:20:04 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E1D524C05D; Wed, 13 Mar 2013 16:20:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 13 Mar 2013 16:20:03 +0100 From: To: "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Wed, 13 Mar 2013 16:20:02 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 15:20:06 -0000 Hi Simo, The document says: The 'ccap' attribute MUST NOT be used in situations where an existing mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245]) can be used to select between different connection addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). Would it be possible to change it to the following: NEW: The 'ccap' attribute MUST NOT be used in situations where a mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to select between different connection addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). Thanks. Cheers, Med >-----Message d'origine----- >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >De la part de Simo.Veikkolainen@nokia.com >Envoy=E9 : mercredi 13 mars 2013 16:09 >=C0 : mmusic@ietf.org >Objet : Re: [MMUSIC] I-D Action:=20 >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Hello, > >We just submitted a new version of the miscellaneous-caps=20 >draft, with text that states that if the connection data=20 >capability attribute (a=3Dccap) is used the port number in the=20 >resulting SDP MUST be the same as in the original "m=3D" line,=20 >except for PSTN type bearers (when the port number used is 9). > >Regards, >Simo > >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >On Behalf Of ext internet-drafts@ietf.org >Sent: 13. maaliskuuta 2013 15:39 >To: i-d-announce@ietf.org >Cc: mmusic@ietf.org >Subject: [MMUSIC] I-D Action:=20 >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia=20 >Session Control Working Group of the IETF. > > Title : Miscellaneous Capabilities=20 >Negotiation in the Session Description Protocol (SDP) > Author(s) : Miguel A. Garcia-Martin > Simo Veikkolainen > Robert R. Gilman > Filename :=20 >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > Pages : 21 > Date : 2013-03-13 > >Abstract: > SDP has been extended with a capability negotiation mechanism > framework that allows the endpoints to negotiate transport protocols > and attributes. This framework has been extended with a media > capabilities negotiation mechanism that allows endpoints to=20 >negotiate > additional media-related capabilities. This negotiation is embedded > into the widely-used SDP offer/answer procedures. > > This memo extends the SDP capability negotiation framework to allow > endpoints to negotiate three additional SDP capabilities. In > particular, this memo provides a mechanism to negotiate bandwidth > ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line f= or > each session or media). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >neous-caps > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella >neous-caps-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic >= From thomas.stach@siemens-enterprise.com Wed Mar 13 09:57:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D6921F8735 for ; Wed, 13 Mar 2013 09:57:12 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWj8V5GokJSq for ; Wed, 13 Mar 2013 09:57:12 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AA77F21F8623 for ; Wed, 13 Mar 2013 09:57:11 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DA57923F04DD; Wed, 13 Mar 2013 17:57:10 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 17:57:10 +0100 From: "Stach, Thomas" To: "mohamed.boucadair@orange.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMA== Date: Wed, 13 Mar 2013 16:57:09 +0000 Message-ID: References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:57:12 -0000 Mohammed, I think you have draft-boucadair-mmusic-altc in mind. This is an individual submission intended to document some proporietary mec= hanism. I don't think we should make restrictions in a standards track document in = support of proprietary mechanisms. Otherwise I could also think of additional proprietary stuff that could be = mentioned as well. Regards Thomas =20 > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > Im Auftrag von mohamed.boucadair@orange.com > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: Re: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Hi Simo, >=20 > The document says: >=20 > The 'ccap' attribute MUST NOT be used in > situations where an existing mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245]) can be used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). >=20 > Would it be possible to change it to the following: >=20 > NEW: >=20 > The 'ccap' attribute MUST NOT be used in > situations where a mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is=20 > used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). >=20 >=20 > Thanks. > Cheers, > Med >=20 >=20 > >-----Message d'origine----- > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > >De la part de Simo.Veikkolainen@nokia.com > >Envoy=E9 : mercredi 13 mars 2013 16:09 > >=C0 : mmusic@ietf.org > >Objet : Re: [MMUSIC] I-D Action:=20 > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > >Hello, > > > >We just submitted a new version of the miscellaneous-caps=20 > >draft, with text that states that if the connection data=20 > >capability attribute (a=3Dccap) is used the port number in the=20 > >resulting SDP MUST be the same as in the original "m=3D" line,=20 > >except for PSTN type bearers (when the port number used is 9). > > > >Regards, > >Simo > > > >-----Original Message----- > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > >On Behalf Of ext internet-drafts@ietf.org > >Sent: 13. maaliskuuta 2013 15:39 > >To: i-d-announce@ietf.org > >Cc: mmusic@ietf.org > >Subject: [MMUSIC] I-D Action:=20 > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >A New Internet-Draft is available from the on-line=20 > >Internet-Drafts directories. > > This draft is a work item of the Multiparty Multimedia=20 > >Session Control Working Group of the IETF. > > > > Title : Miscellaneous Capabilities=20 > >Negotiation in the Session Description Protocol (SDP) > > Author(s) : Miguel A. Garcia-Martin > > Simo Veikkolainen > > Robert R. Gilman > > Filename :=20 > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Pages : 21 > > Date : 2013-03-13 > > > >Abstract: > > SDP has been extended with a capability negotiation mechanism > > framework that allows the endpoints to negotiate=20 > transport protocols > > and attributes. This framework has been extended with a media > > capabilities negotiation mechanism that allows endpoints to=20 > >negotiate > > additional media-related capabilities. This negotiation=20 > is embedded > > into the widely-used SDP offer/answer procedures. > > > > This memo extends the SDP capability negotiation=20 > framework to allow > > endpoints to negotiate three additional SDP capabilities. In > > particular, this memo provides a mechanism to negotiate bandwidth > > ('b=3D' line), connection data ('c=3D' line), and titles=20 > ('i=3D' line for > > each session or media). > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > >neous-caps > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneou > s-caps-04 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > >neous-caps-04 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From mohamed.boucadair@orange.com Wed Mar 13 10:39:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34B21F86D5 for ; Wed, 13 Mar 2013 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 cQnBFgdBErSU for ; Wed, 13 Mar 2013 10:39:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B621F865D for ; Wed, 13 Mar 2013 10:39:56 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 55DAC22CD20; Wed, 13 Mar 2013 18:39:55 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3B04627C053; Wed, 13 Mar 2013 18:39:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 13 Mar 2013 18:39:55 +0100 From: To: "Stach, Thomas" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Wed, 13 Mar 2013 18:39:54 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvG Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.151516 Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:39:57 -0000 Dear Thomas, I'm not proposing to change the existing behavior; I'm just asking whether = it is acceptable to add an additional example to the one already cited in t= he text. Wouldn't that be acceptable? You can propose to add another example if you have any in mind. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0= 4.txt Mohammed, I think you have draft-boucadair-mmusic-altc in mind. This is an individual submission intended to document some proporietary mec= hanism. I don't think we should make restrictions in a standards track document in = support of proprietary mechanisms. Otherwise I could also think of additional proprietary stuff that could be = mentioned as well. Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > Im Auftrag von mohamed.boucadair@orange.com > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Hi Simo, > > The document says: > > The 'ccap' attribute MUST NOT be used in > situations where an existing mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245]) can be used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). > > Would it be possible to change it to the following: > > NEW: > > The 'ccap' attribute MUST NOT be used in > situations where a mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). > > > Thanks. > Cheers, > Med > > > >-----Message d'origine----- > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > >De la part de Simo.Veikkolainen@nokia.com > >Envoy=E9 : mercredi 13 mars 2013 16:09 > >=C0 : mmusic@ietf.org > >Objet : Re: [MMUSIC] I-D Action: > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > >Hello, > > > >We just submitted a new version of the miscellaneous-caps > >draft, with text that states that if the connection data > >capability attribute (a=3Dccap) is used the port number in the > >resulting SDP MUST be the same as in the original "m=3D" line, > >except for PSTN type bearers (when the port number used is 9). > > > >Regards, > >Simo > > > >-----Original Message----- > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > >On Behalf Of ext internet-drafts@ietf.org > >Sent: 13. maaliskuuta 2013 15:39 > >To: i-d-announce@ietf.org > >Cc: mmusic@ietf.org > >Subject: [MMUSIC] I-D Action: > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > This draft is a work item of the Multiparty Multimedia > >Session Control Working Group of the IETF. > > > > Title : Miscellaneous Capabilities > >Negotiation in the Session Description Protocol (SDP) > > Author(s) : Miguel A. Garcia-Martin > > Simo Veikkolainen > > Robert R. Gilman > > Filename : > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Pages : 21 > > Date : 2013-03-13 > > > >Abstract: > > SDP has been extended with a capability negotiation mechanism > > framework that allows the endpoints to negotiate > transport protocols > > and attributes. This framework has been extended with a media > > capabilities negotiation mechanism that allows endpoints to > >negotiate > > additional media-related capabilities. This negotiation > is embedded > > into the widely-used SDP offer/answer procedures. > > > > This memo extends the SDP capability negotiation > framework to allow > > endpoints to negotiate three additional SDP capabilities. In > > particular, this memo provides a mechanism to negotiate bandwidth > > ('b=3D' line), connection data ('c=3D' line), and titles > ('i=3D' line for > > each session or media). > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > >neous-caps > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneou > s-caps-04 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > >neous-caps-04 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From thomas.stach@siemens-enterprise.com Wed Mar 13 11:18:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E558A21F8EB3 for ; Wed, 13 Mar 2013 11:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 r7AjyD9PyT8l for ; Wed, 13 Mar 2013 11:17:54 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 131EF21F8EB1 for ; Wed, 13 Mar 2013 11:17:53 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C6DB71EB845E; Wed, 13 Mar 2013 19:17:51 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 19:17:51 +0100 From: "Stach, Thomas" To: "mohamed.boucadair@orange.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oA= Date: Wed, 13 Mar 2013 18:17:50 +0000 Message-ID: References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:18:02 -0000 Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be=20 preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'.=20 The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and=20 the 'ccap' attribute it MUST use ICE to select between different connection= addresses=20 (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas =20 > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com=20 > [mailto:mohamed.boucadair@orange.com]=20 > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Dear Thomas, >=20 > I'm not proposing to change the existing behavior; I'm just=20 > asking whether it is acceptable to add an additional example=20 > to the one already cited in the text. > Wouldn't that be acceptable? >=20 > You can propose to add another example if you have any in mind. >=20 > Cheers, > Med >=20 > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;=20 > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Mohammed, >=20 > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some=20 > proporietary mechanism. > I don't think we should make restrictions in a standards=20 > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff=20 > that could be mentioned as well. >=20 >=20 > Regards > Thomas >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate=20 > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > = From atle.monrad@ericsson.com Wed Mar 13 11:31:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5637F21F86E3 for ; Wed, 13 Mar 2013 11:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5COl-Ddl+yt for ; Wed, 13 Mar 2013 11:31:43 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A2B4821F8DEC for ; Wed, 13 Mar 2013 11:31:42 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-05-5140c6091bf4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1C.F1.32353.906C0415; Wed, 13 Mar 2013 19:31:37 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.183]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 19:31:36 +0100 From: Atle Monrad To: "Stach, Thomas" , "mohamed.boucadair@orange.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oCAAAlOcA== Date: Wed, 13 Mar 2013 18:31:36 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjS7nMYdAg49L5SymLn/MYnH47VN2 i3Of7rJY7Npe48DisWTJTyaPu7cuMXm0PDvJ5nHj9nvmAJYoLpuU1JzMstQifbsEroxlcyMK ftlX7Du3jrmBcZVxFyMnh4SAiUT7hPmsELaYxIV769m6GLk4hAQOMUocn7KTFcJZwijx4k4T WBWbgI7EuZ93wBIiAg8YJW797WAHSQgLBEt0rl0JViQiECIx6/xnNgg7TOLa6a1MIDaLgKrE to8zwOp5Bbwlzp/7xQixYS+zxLVH+5lBEpwC/hITJ89i6WLk4GAUkJWY28QLEmYWEJe49WQ+ E8SpAhJL9pxnhrBFJV4+/gf1gqJE+9MGRoh6PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjKKz kIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9/ECIyZg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB 9MSS1OzU1ILUovii0pzU4kOMTBycUkB3nfz1ISJPnHWmtz3z5u6bufMM7s/arhwaKHA5X33V jFvlZ38vMXqncfFEfOaH7J6qqL/fp336//9IzMU6AZ4F/DPsufg7OL32pe4/5qVtsUj29imh FpE7xxSKt2x+ciMg4/qhcwb+VR5nVRZfzeC6XmdS9/lCq8Cl6auKbqpqPLm7fe56t11LlViK MxINtZiLihMBRjZcg2cCAAA= Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:31:44 -0000 All I'd like to support not adding any new dependencies to the miscellaneous-ca= ps draft. The proposed new text below seems OK, even thugh I personally lik= e the existing text better.=20 This draft has been on the 3GPP depenceny list for years, and we need the d= raft completed. thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Stach, Thomas Sent: 13. mars 2013 14:18 To: mohamed.boucadair@orange.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'.=20 The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent connection addresses (e.g. "IP4" and "IP6" or different IP addresses w= ithin the same IP address family). Regards Thomas =20 > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Dear Thomas, >=20 > I'm not proposing to change the existing behavior; I'm just asking=20 > whether it is acceptable to add an additional example to the one=20 > already cited in the text. > Wouldn't that be acceptable? >=20 > You can propose to add another example if you have any in mind. >=20 > Cheers, > Med >=20 > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed=20 > OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW:=20 > [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Mohammed, >=20 > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some=20 > proporietary mechanism. > I don't think we should make restrictions in a standards track=20 > document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff that=20 > could be mentioned as well. >=20 >=20 > Regards > Thomas >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im=20 > > Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to=20 > > select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la=20 > > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 mars 2013=20 > > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps draft,=20 > > >with text that states that if the connection data capability=20 > > >attribute (a=3Dccap) is used the port number in the resulting SDP=20 > > >MUST be the same as in the original "m=3D" line, except for PSTN type= =20 > > >bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > >Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > > >directories. > > > This draft is a work item of the Multiparty Multimedia Session=20 > > >Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to=20 > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > >-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mohamed.boucadair@orange.com Wed Mar 13 11:32:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273F421F8DEC for ; Wed, 13 Mar 2013 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 HXK2uiixTl26 for ; Wed, 13 Mar 2013 11:32:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EED8C21F8D98 for ; Wed, 13 Mar 2013 11:32:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DBA3622CE52; Wed, 13 Mar 2013 19:32:53 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BF94E23804B; Wed, 13 Mar 2013 19:32:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 13 Mar 2013 19:32:53 +0100 From: To: "Stach, Thomas" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Wed, 13 Mar 2013 19:32:53 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oCAAAoB3w== Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1A9@PUEXCB1B.nanterre.francetelecom.fr> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.172125 Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:32:56 -0000 Re-, The wording you propose is better as it explicits this behavior is about IC= E and not something else. So, I'm fine with that wording if this is the int= ent of the authors. BTW, the altc draft already mentions that if altc and c= cap are both supported, then both are offered.=20 In fact, I stopped to track this draft since the Anaheim meeting when it se= ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I= Pv6 address. The misc draft should specify ccap when distinct nettypes are = in use. It seems that consensus is not anymore valid. =20 The current text of ccap is under-specified if it is to be used to convey a= n IPv4 and IPv6 address.=20 Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0= 4.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between different connection= addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just > asking whether it is acceptable to add an additional example > to the one already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff > that could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > From mohamed.boucadair@orange.com Wed Mar 13 11:34:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA01121F8700 for ; Wed, 13 Mar 2013 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 RaCnu2bBhPTq for ; Wed, 13 Mar 2013 11:34:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A021F87D0 for ; Wed, 13 Mar 2013 11:34:47 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DD9DD22C303; Wed, 13 Mar 2013 19:34:46 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C05504C015; Wed, 13 Mar 2013 19:34:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 13 Mar 2013 19:34:46 +0100 From: To: Atle Monrad , "Stach, Thomas" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Wed, 13 Mar 2013 19:33:47 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oCAAAlOcIAAA7fP Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1AA@PUEXCB1B.nanterre.francetelecom.fr> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> , <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.152725 Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:34:49 -0000 Dear Atle,=20 To my knowledge, 3GPP never discussed the use of ccap to convey IPv4 and IP= v6 addresses.=20 Can you please confirm/infirm? Thanks. Cheers, Med ________________________________________ De : Atle Monrad [atle.monrad@ericsson.com] Date d'envoi : mercredi 13 mars 2013 19:31 =C0 : Stach, Thomas; BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.co= m; mmusic@ietf.org Objet : RE: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0= 4.txt All I'd like to support not adding any new dependencies to the miscellaneous-ca= ps draft. The proposed new text below seems OK, even thugh I personally lik= e the existing text better. This draft has been on the 3GPP depenceny list for years, and we need the d= raft completed. thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Stach, Thomas Sent: 13. mars 2013 14:18 To: mohamed.boucadair@orange.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent connection addresses (e.g. "IP4" and "IP6" or different IP addresses w= ithin the same IP address family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just asking > whether it is acceptable to add an additional example to the one > already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed > OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: > [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards track > document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff that > could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im > > Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to > > select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la > > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 mars 2013 > > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps draft, > > >with text that states that if the connection data capability > > >attribute (a=3Dccap) is used the port number in the resulting SDP > > >MUST be the same as in the original "m=3D" line, except for PSTN type > > >bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > >Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > This draft is a work item of the Multiparty Multimedia Session > > >Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > >-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From md3135@att.com Wed Mar 13 11:35:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490C21F8700 for ; Wed, 13 Mar 2013 11:35:42 -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 Bz8ozUkYBgM9 for ; Wed, 13 Mar 2013 11:35:41 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0607A21F8653 for ; Wed, 13 Mar 2013 11:35:40 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id cf6c0415.2aaaca803940.255830.00-539.713909.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 13 Mar 2013 18:35:40 +0000 (UTC) X-MXL-Hash: 5140c6fc07067dc5-60b9686671ef3a76d42ef68d1e48627c002e5fff Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id af6c0415.0.255802.00-469.713834.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 13 Mar 2013 18:35:40 +0000 (UTC) X-MXL-Hash: 5140c6fc0ad515d9-510b3ca203e9abc6e7cf7365fb50fa46fc3905a3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2DIZc6A028847; Wed, 13 Mar 2013 14:35:38 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2DIZUsc028702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2013 14:35:34 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 13 Mar 2013 18:35:20 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 14:35:19 -0400 From: "DOLLY, MARTIN C" To: Atle Monrad , "Stach, Thomas" , "mohamed.boucadair@orange.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oCAAAlOcIAABAsQ Date: Wed, 13 Mar 2013 18:35:19 +0000 Message-ID: References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.225.211] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Z4pb6gtA c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=xHSwhPuwlgsA:10 a=elXZJPOiDegA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=HoGi4KEj8kkA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=9qxNCY_qAAAA:8 a=ag3Orf1RAAAA:8 a=lbd8934S8IwBEtJZM3MA:] X-AnalysisOut: [9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=] X-AnalysisOut: [1pxjJC3EenQA:10 a=KwNp_X_GjOYA:10 a=4SvUAKCvBaR2UXnD:21 a=] X-AnalysisOut: [RbQ4rIYLVyCDDiBX:21] Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:35:42 -0000 I agree with Atle -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Atle Monrad Sent: Wednesday, March 13, 2013 2:32 PM To: Stach, Thomas; mohamed.boucadair@orange.com; Simo.Veikkolainen@nokia.co= m; mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt All I'd like to support not adding any new dependencies to the miscellaneous-ca= ps draft. The proposed new text below seems OK, even thugh I personally lik= e the existing text better.=20 This draft has been on the 3GPP depenceny list for years, and we need the d= raft completed. thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Stach, Thomas Sent: 13. mars 2013 14:18 To: mohamed.boucadair@orange.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'.=20 The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent connection addresses (e.g. "IP4" and "IP6" or different IP addresses w= ithin the same IP address family). Regards Thomas =20 > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action:=20 > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Dear Thomas, >=20 > I'm not proposing to change the existing behavior; I'm just asking=20 > whether it is acceptable to add an additional example to the one=20 > already cited in the text. > Wouldn't that be acceptable? >=20 > You can propose to add another example if you have any in mind. >=20 > Cheers, > Med >=20 > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed=20 > OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW:=20 > [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >=20 > Mohammed, >=20 > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some=20 > proporietary mechanism. > I don't think we should make restrictions in a standards track=20 > document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff that=20 > could be mentioned as well. >=20 >=20 > Regards > Thomas >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im=20 > > Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to=20 > > select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la=20 > > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 mars 2013=20 > > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps draft,=20 > > >with text that states that if the connection data capability=20 > > >attribute (a=3Dccap) is used the port number in the resulting SDP=20 > > >MUST be the same as in the original "m=3D" line, except for PSTN type= =20 > > >bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > >Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > > >directories. > > > This draft is a work item of the Multiparty Multimedia Session=20 > > >Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to=20 > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > >-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=4784c40367=aallen@blackberry.com Wed Mar 13 11:37:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D5311E80BA for ; Wed, 13 Mar 2013 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Q55gbyaH1PQw for ; Wed, 13 Mar 2013 11:37:37 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 66A9E11E80BF for ; Wed, 13 Mar 2013 11:37:32 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-0c-5140c75e17fe Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 06.FE.09265.F57C0415; Wed, 13 Mar 2013 13:37:19 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 13:37:18 -0500 From: Andrew Allen To: "mohamed.boucadair@orange.com" , "thomas.stach@siemens-enterprise.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBkwXT5Az9vc8ESGJDl11VtRr5ij82Dg Date: Wed, 13 Mar 2013 18:37:17 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB755B1A9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5ZyvpRt/3CHQ4PZVXoupyx+zWBx++5Td 4tynuywWu7bXOLB4LFnyk8nj7q1LTB4tz06yedy4/Z45gCWqgdEmKbGkLDgzPU/fziYxLy+/ JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RW KbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2ekmdPJkHP3/nr3gi2tF x44WtgbGTosuRk4OCQETiX0vPrJD2GISF+6tZ+ti5OIQEljJKPF2/l4oZzOjxPwDzWwgVWwC WhL7D09nAkmICHxjlGjcvpwRJCEsECHxZvVFFhBbRCBS4t77GawQtpHEsZt/wFawCKhKPL28 BWwQr4CHxMrtHWA1nAIxEn8/rgOLMwrISuw+e50JxGYWEJe49WQ+E8R5AhJL9pxnhrBFJV4+ /scKYStK/N37nRWiXk/ixtQpbBC2tsSyha+ZIXYJSpyc+YRlAqPILCRjZyFpmYWkZRaSlgWM LKsYBXMzig3MDJLzkvWKMnP18lJLNjGCEoSjhv4OxrfvLQ4xCnAwKvHwiu9yCBRiTSwrrsw9 xCjBwawkwrs8FyjEm5JYWZValB9fVJqTWnyI0RUYEhOZpbiT84HJK68k3tjAADdHSZxXJFA0 UEggHZhoslNTC1KLYOYwcXCC7OGSEikGpovUosTSkox4UFKLLwamNakGRpM9LtUfn2d0Pp5+ 5aaL2/Qv4vvzlG4nGHvNUbmVLC1uYTrJP2iuzuQ5yw3cPdTz7opey/5hw1Im4T8zcd6O47uC wsN4XafLLzr0b25g1o9LDBO7pptUft2uP/NwheaUCU5Vy2+eOqArufPPgqs3o20DeQud3nJc Fl++qVtuip3/t7tnXWMzbyqxFGckGmoxFxUnAgBzrhgtUQMAAA== Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:37:39 -0000 The main use of the CCAP parameter is to indicate the capability to use CS S= DP and E.164 numbers as a connection address and is not intended for IPv4 vs= IPv6 for which ICE is the IETF defined mechanism. ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time=0A= To: Stach, Thomas ; Simo.Veikkolainen@n= okia.com ; mmusic@ietf.org Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Re-, The wording you propose is better as it explicits this behavior is about ICE= and not something else. So, I'm fine with that wording if this is the inten= t of the authors. BTW, the altc draft already mentions that if altc and ccap= are both supported, then both are offered. In fact, I stopped to track this draft since the Anaheim meeting when it see= ms the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv= 6 address. The misc draft should specify ccap when distinct nettypes are in= use. It seems that consensus is not anymore valid. The current text of ccap is under-specified if it is to be used to convey an= IPv4 and IPv6 address. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.o= rg Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04= .txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE M= UST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propri= etary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte sp= ecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) [= RFC5245] and the 'ccap' attribute it MUST use ICE to select between different connection= addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just > asking whether it is acceptable to add an additional example > to the one already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff > that could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mohamed.boucadair@orange.com Wed Mar 13 11:42:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18EC21F8A0C for ; Wed, 13 Mar 2013 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 w4etcNWlPvdJ for ; Wed, 13 Mar 2013 11:42:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A35B821F89EE for ; Wed, 13 Mar 2013 11:42:50 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0902D324D2D; Wed, 13 Mar 2013 19:42:50 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DEB4835C055; Wed, 13 Mar 2013 19:42:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 13 Mar 2013 19:42:49 +0100 From: To: Andrew Allen , "thomas.stach@siemens-enterprise.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Wed, 13 Mar 2013 19:38:20 +0100 Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBkwXT5Az9vc8ESGJDl11VtRr5ij82DggAAATF8= Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB755B1A9@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.152725 Subject: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:42:52 -0000 Hi Andrew, This was also my understanding but it seems the current text opens the door= to signal an IPv4 and IPv6 address. If it is not allowed, then the text should be clear. Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo= .Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c= aps-04.txt The main use of the CCAP parameter is to indicate the capability to use CS = SDP and E.164 numbers as a connection address and is not intended for IPv4 = vs IPv6 for which ICE is the IETF defined mechanism. ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time To: Stach, Thomas ; Simo.Veikkolainen@= nokia.com ; mmusic@ietf.org Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps= -04.txt Re-, The wording you propose is better as it explicits this behavior is about IC= E and not something else. So, I'm fine with that wording if this is the int= ent of the authors. BTW, the altc draft already mentions that if altc and c= cap are both supported, then both are offered. In fact, I stopped to track this draft since the Anaheim meeting when it se= ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I= Pv6 address. The misc draft should specify ccap when distinct nettypes are = in use. It seems that consensus is not anymore valid. The current text of ccap is under-specified if it is to be used to convey a= n IPv4 and IPv6 address. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0= 4.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between different connection= addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just > asking whether it is acceptable to add an additional example > to the one already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff > that could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From atle.monrad@ericsson.com Wed Mar 13 11:59:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE28721F86C2 for ; Wed, 13 Mar 2013 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.047 X-Spam-Level: X-Spam-Status: No, score=-6.047 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbWlLJgelBmy for ; Wed, 13 Mar 2013 11:59:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8721F8C9F for ; Wed, 13 Mar 2013 11:59:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ea-5140ccaa0a3c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.1E.10459.AACC0415; Wed, 13 Mar 2013 19:59:54 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.183]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 19:59:54 +0100 From: Atle Monrad To: "mohamed.boucadair@orange.com" , "Stach, Thomas" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOH/Be4rgAa1GkG0S6QlhY7FpQY5ijt+8wgAADtrCAAAMhMIAAIwvGgAAD4oCAAAlOcIAAA7fPgAACtcA= Date: Wed, 13 Mar 2013 18:59:53 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C082A28@ESESSMB203.ericsson.se> References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EB73564EC@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1A8@PUEXCB1B.nanterre.francetelecom.fr> , <7D2F7D7ADBA812449F25F4A69922881C082946@ESESSMB203.ericsson.se> <94C682931C08B048B7A8645303FDC9F36EB755B1AA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB755B1AA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje6qMw6BBt3vDSymLn/MYnH47VN2 i3Of7rJY7Npe48DisWTJTyaPu7cuMXm0PDvJ5nHj9nvmAJYoLpuU1JzMstQifbsEroxb3R2s BV89K2YuWcncwHjYuouRk0NCwERi0Y/fLBC2mMSFe+vZuhi5OIQEDjFKNLyYwAjhLGGUONHa xQpSxSagI3Hu5x1WkISIwD1GifWrVoElhAWCJTrXrgSzRQRCJGad/8wGYSdJTHrbyAxiswio ShxoW83excjBwSvgLfGoD2rBeRaJx58fsYPUcArESCw7f5YZpIZRQFZibhMvSJhZQFzi1pP5 TBCXCkgs2XOeGcIWlXj5+B8rhK0o0f60gRGiXk/ixtQpbBC2tsSyha/B6nkFBCVOznzCMoFR dBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eWGmxiBMXNwy2/dHYynzokcYpTmYFES5w1zvRAg JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHyX2/yVTN9ztVbHpZ1/K+ctElidb52XPdXNw0G j+NWHfH/gi+/29z9dFPWL6fdYux6bxqtUtuVl1zluPOvZq3P4bexdSribL47wpl3CC15X6q/ jt/umbrr4nXxvzcsZc1t5Hj20cTmxG3FxtoJrSw8XmFpYqcPnd+x/pXNL+7+/VG6J8/4zldi Kc5INNRiLipOBAD4z1kMZwIAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:59:59 -0000 Hi 3GPP use this draft in our centralized services which is a feature since 3G= PP Rel-8 as mentioned by Andrew. My point was to avoid adding new references to new drafts on this topic whe= re 3GPP is waiting for completion. My personal preference on the sentence is clearly stated below, but should = in no way be seen as a showstopper. cheers /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: 13. mars 2013 14:34 To: Atle Monrad; Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.or= g Subject: RE : [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps= -04.txt Dear Atle,=20 To my knowledge, 3GPP never discussed the use of ccap to convey IPv4 and IP= v6 addresses.=20 Can you please confirm/infirm? Thanks. Cheers, Med ________________________________________ De : Atle Monrad [atle.monrad@ericsson.com] Date d'envoi : mercredi 13 mars= 2013 19:31 =C0 : Stach, Thomas; BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolai= nen@nokia.com; mmusic@ietf.org Objet : RE: [MMUSIC] I-D Action: draft-ietf-= mmusic-sdp-miscellaneous-caps-04.txt All I'd like to support not adding any new dependencies to the miscellaneous-ca= ps draft. The proposed new text below seems OK, even thugh I personally lik= e the existing text better. This draft has been on the 3GPP depenceny list for years, and we need the d= raft completed. thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Stach, Thomas Sent: 13. mars 2013 14:18 To: mohamed.boucadair@orange.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent connection addresses (e.g. "IP4" and "IP6" or different IP addresses w= ithin the same IP address family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just asking=20 > whether it is acceptable to add an additional example to the one=20 > already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed=20 > OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: > [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some=20 > proporietary mechanism. > I don't think we should make restrictions in a standards track=20 > document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff that=20 > could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im=20 > > Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to=20 > > select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la=20 > > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 mars 2013 > > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps draft,=20 > > >with text that states that if the connection data capability=20 > > >attribute (a=3Dccap) is used the port number in the resulting SDP=20 > > >MUST be the same as in the original "m=3D" line, except for PSTN type= =20 > > >bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > >Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > > >directories. > > > This draft is a work item of the Multiparty Multimedia Session=20 > > >Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to=20 > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > >-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=5784dd8711=aallen@blackberry.com Wed Mar 13 12:03:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1911E81B0 for ; Wed, 13 Mar 2013 12:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 2BQXg1Tpfvoy for ; Wed, 13 Mar 2013 12:03:50 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E47B11E8174 for ; Wed, 13 Mar 2013 12:03:43 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-74-5140cd7f2007 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id AC.DF.09265.68DC0415; Wed, 13 Mar 2013 14:03:36 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 14:03:27 -0500 From: Andrew Allen To: "mohamed.boucadair@orange.com" , "thomas.stach@siemens-enterprise.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" , "jonathan@vidyo.com" Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBkwXT5Az9vc8ESGJDl11VtRr5ij82DggAAATF+AAAcDiQ== Date: Wed, 13 Mar 2013 19:03:26 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsXC5Zyvrdtx1iHQ4Np+BYv9i88zW0xd/pjF 4vDbp+wW5z7dZbHYtb3GgdVjyZKfTB53b11i8mh5dpLN48bt98webc/usAewRjUw2iQllpQF Z6bn6dvZJObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm5qYWKSlkptgqmSgp FOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0tdQyU73YRO noxP67tYCs6EVExu2sbYwHjUpYuRk0NCwERi55smdghbTOLCvfVsXYxcHEICKxkl9jT9ZIZw NjNKzPzeywxSxSagJbH/8HQmkISIwGImiY62D0wgCWGBWIlZb9tZQWwRgTiJn31LmSFsJ4ln B+aC1bAIqEp03n7IAmLzCnhItM94DlbPKRAjMenrUrAaRgFZid1nr4PZzALiEreezGeCOE9A Ysme88wQtqjEy8f/WCFsRYm/e7+zQtTrSdyYOoUNwtaWWLbwNTPELkGJkzOfsExgFJmFZOws JC2zkLTMQtKygJFlFaNgbkaxgZlBcl6yXlFmrl5easkmRlDScNTQ38H49r3FIUYBDkYlHl7x XQ6BQqyJZcWVuYcYJTiYlUR4l+cChXhTEiurUovy44tKc1KLDzG6AkNiIrMUd3I+MKHllcQb Gxjg5iiJ84oEigYKCaQDE012ampBahHMHCYOTpA9XFIixcB0kVqUWFqSEQ9KavHFwLQm1cDI 9/dR2+Pv7g/fOicY8UhtvzL54Xpl5eUVQpoav+crfD65psVyGV/ugm3tk07v15d6odH5Qkps U31MDVfeRAHvmcFz53qdu39jhuUy/1IxtS9cByMZl5YcWFfX6PV1nyd3Co+ov6cEj3POiUWq nxt6p/66PiFx7udv6Uy75l8IE4t9xbznu91qJZbijERDLeai4kQA3xnMtVsDAAA= Subject: Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:03:51 -0000 The text in the draft was worked out with Jonathan Lennox who raised the ini= tial concen about conflict with ICE. If Jonathan is ok with the revised prop= osal from Thomas then I am OK with it. Andrew ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time=0A= To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ;= mmusic@ietf.org Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-= caps-04.txt Hi Andrew, This was also my understanding but it seems the current text opens the door= to signal an IPv4 and IPv6 address. If it is not allowed, then the text should be clear. Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.= Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-ca= ps-04.txt The main use of the CCAP parameter is to indicate the capability to use CS S= DP and E.164 numbers as a connection address and is not intended for IPv4 vs= IPv6 for which ICE is the IETF defined mechanism. ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time To: Stach, Thomas ; Simo.Veikkolainen@n= okia.com ; mmusic@ietf.org Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-= 04.txt Re-, The wording you propose is better as it explicits this behavior is about ICE= and not something else. So, I'm fine with that wording if this is the inten= t of the authors. BTW, the altc draft already mentions that if altc and ccap= are both supported, then both are offered. In fact, I stopped to track this draft since the Anaheim meeting when it see= ms the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv= 6 address. The misc draft should specify ccap when distinct nettypes are in= use. It seems that consensus is not anymore valid. The current text of ccap is under-specified if it is to be used to convey an= IPv4 and IPv6 address. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.o= rg Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04= .txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE M= UST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propri= etary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte sp= ecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) [= RFC5245] and the 'ccap' attribute it MUST use ICE to select between different connection= addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just > asking whether it is acceptable to add an additional example > to the one already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff > that could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mohamed.boucadair@orange.com Wed Mar 13 12:23:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94A11E81BE for ; Wed, 13 Mar 2013 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 cCV4p2eEOJj8 for ; Wed, 13 Mar 2013 12:23:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55B11E81B9 for ; Wed, 13 Mar 2013 12:23:25 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B5ED1264AB1; Wed, 13 Mar 2013 20:23:24 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 93A5435C055; Wed, 13 Mar 2013 20:23:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 13 Mar 2013 20:23:24 +0100 From: To: Andrew Allen , "thomas.stach@siemens-enterprise.com" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" , "jonathan@vidyo.com" Date: Wed, 13 Mar 2013 20:18:33 +0100 Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBkwXT5Az9vc8ESGJDl11VtRr5ij82DggAAATF+AAAcDiYAABDlR Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.152725 Subject: [MMUSIC] RE : RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:23:27 -0000 Re-, The point is that if the attribute is extended to be able to convey an IPv4= and an alternate IPv6@, then your statement " and is not intended for IPv= 4 vs IPv6 for which ICE is the IETF defined mechanism." is not valid anymo= re...If that consensus changed then I'm puzzled why that argument was raise= d against altc and not ccap?!! OTOH, if the attribute is extended to cover IPv4/IPv6 then it should be cl= early specified. The current text does not say much for that case.=20 Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2013 20:03 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo= .Veikkolainen@nokia.com; mmusic@ietf.org; jonathan@vidyo.com Objet : Re: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellane= ous-caps-04.txt The text in the draft was worked out with Jonathan Lennox who raised the in= itial concen about conflict with ICE. If Jonathan is ok with the revised pr= oposal from Thomas then I am OK with it. Andrew ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com = ; mmusic@ietf.org Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous= -caps-04.txt Hi Andrew, This was also my understanding but it seems the current text opens the door= to signal an IPv4 and IPv6 address. If it is not allowed, then the text should be clear. Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo= .Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c= aps-04.txt The main use of the CCAP parameter is to indicate the capability to use CS = SDP and E.164 numbers as a connection address and is not intended for IPv4 = vs IPv6 for which ICE is the IETF defined mechanism. ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time To: Stach, Thomas ; Simo.Veikkolainen@= nokia.com ; mmusic@ietf.org Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps= -04.txt Re-, The wording you propose is better as it explicits this behavior is about IC= E and not something else. So, I'm fine with that wording if this is the int= ent of the authors. BTW, the altc draft already mentions that if altc and c= cap are both supported, then both are offered. In fact, I stopped to track this draft since the Anaheim meeting when it se= ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I= Pv6 address. The misc draft should specify ccap when distinct nettypes are = in use. It seems that consensus is not anymore valid. The current text of ccap is under-specified if it is to be used to convey a= n IPv4 and IPv6 address. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.= org Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0= 4.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between different connection= addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address= family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just > asking whether it is acceptable to add an additional example > to the one already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; > mmusic@ietf.org > Objet : AW: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some > proporietary mechanism. > I don't think we should make restrictions in a standards > track document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff > that could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > Im Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is > > used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >De la part de Simo.Veikkolainen@nokia.com > > >Envoy=E9 : mercredi 13 mars 2013 16:09 > > >=C0 : mmusic@ietf.org > > >Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps > > >draft, with text that states that if the connection data > > >capability attribute (a=3Dccap) is used the port number in the > > >resulting SDP MUST be the same as in the original "m=3D" line, > > >except for PSTN type bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > > >On Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > This draft is a work item of the Multiparty Multimedia > > >Session Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From suhasietf@gmail.com Wed Mar 13 12:38:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2104C1F0D08 for ; Wed, 13 Mar 2013 12:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 GlfEWGNg5atU for ; Wed, 13 Mar 2013 12:38:29 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2461021F8CC7 for ; Wed, 13 Mar 2013 12:38:24 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so1386575wey.19 for ; Wed, 13 Mar 2013 12:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cegnbcldHNYJjFCDIfqnRWd0LtAH6WI90v0e0JQ4Bvg=; b=MzRsyvTGkxHnWSZQYJG4UYvBVoZd4P/Xaie4O7B/4UAZo+Cgc809d6aEGdwMrYyjBI BX315OmTE49XkdMo07nYy4mfoVjUIyCFkCj3HSibsRi8W7R6AuwjFghd0KBpKOQxTXlI ga/pkcn2GCi1c+dxCspcafBGLvty8EVdMK+bZhCNayeOE7Hv5RGYr8DHCSkNErBEy6rY A12XCiQ4hMv61YZ1oqgBb0ulA31H7oPzyEpnL3HYeGmp/weR+3AN+UT7hzj27Jgcinut hxdnscsGienHJIeiiDV7hMSlKFwccV55YEuOZaCnJ5gGP6nh9+LYCHDbqGNrjRVlZA0F l7uQ== MIME-Version: 1.0 X-Received: by 10.194.170.165 with SMTP id an5mr36661012wjc.41.1363203504344; Wed, 13 Mar 2013 12:38:24 -0700 (PDT) Received: by 10.194.16.170 with HTTP; Wed, 13 Mar 2013 12:38:24 -0700 (PDT) In-Reply-To: <201303120102.r2C12W0g240047@shell01.TheWorld.com> References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303120102.r2C12W0g240047@shell01.TheWorld.com> Date: Wed, 13 Mar 2013 12:38:24 -0700 Message-ID: From: Suhas Nandakumar To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=089e013c6848a2168604d7d38c0b Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:38:30 -0000 --089e013c6848a2168604d7d38c0b Content-Type: text/plain; charset=ISO-8859-1 I am just curios ... instead of playing with connection address and port numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would making a particular m=line direction inactive make things simpler .... since for m=lines with direction as inactive would mean no ICE setup , no reject port needed , no resource allocation on intermediary(?) Any thoughts ? ./Suhas On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley wrote: > > From: "Ejzak, Richard P (Richard)" > > > > This is the only compatibility concern identified with the > > asymmetric use of the unspecified address, but this concern is > > clearly misplaced for rtcweb applications where ICE and consent are > > mandatory. > > I'm not limiting my attention to WebRTC only. Even in situations > where WebRTC is gatewayed to existing SIP infrastructure these > problems appear. If we restrict ourselves to WebRTC, then we have > even more freedom, and in that case, I'd simply remove the rule > regarding rejects MDs as members of groups. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e013c6848a2168604d7d38c0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am just curios ... instead of playing with connection address and port nu= mbers for indicating accepting/rejecting a m=3Dline in BUNDLE O/A, would ma= king a particular m=3Dline direction inactive make things simpler ....
= since for m=3Dlines with direction as inactive would mean no ICE setup , no= reject port needed , no resource allocation on intermediary(?)=A0

Any thoughts ?

./Suhas

=
On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley = <worley@ariadne.com> wrote:
> From: "Ejzak, Ri= chard P (Richard)" <richard.ejzak@alcatel-lucent.com>
>
> This is the only compatibility concern identif= ied with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are > mandatory.

I'm not limiting my attention to WebRTC only. =A0Even in situatio= ns
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear. =A0If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.

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

--089e013c6848a2168604d7d38c0b-- From richard.ejzak@alcatel-lucent.com Wed Mar 13 12:42:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9721F8D22 for ; Wed, 13 Mar 2013 12:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.674 X-Spam-Level: X-Spam-Status: No, score=-9.674 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 4zcPeH9eWWEz for ; Wed, 13 Mar 2013 12:42:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 201A021F8D1B for ; Wed, 13 Mar 2013 12:42:42 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2DJgQNF003095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Mar 2013 14:42:27 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2DJg9RD024908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2013 14:42:26 -0500 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 15:42:17 -0400 From: "Ejzak, Richard P (Richard)" To: Suhas Nandakumar , "Dale R. Worley" Thread-Topic: [MMUSIC] Difficulties accepting and rejecting with bundling Thread-Index: AQHOHgF3Mop2zAIAB0ia8HPK7HA92Zignn4AgABqlJmAAATFgIAAMN0dgAMM/QD//71iUA== Date: Wed, 13 Mar 2013 19:42:17 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EB8C95@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303120102.r2C12W0g240047@shell01.TheWorld.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F36EB8C95US70TWXCHMBA12z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:42:43 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F36EB8C95US70TWXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The direction attribute is one that needs to be preserved for each m line t= o indicate direction of the media associated with that m line. It is just = not available for other purposes. Furthermore, inactive does not disable I= CE or RTCP, which would still be expected to proceed. From: Suhas Nandakumar [mailto:suhasietf@gmail.com] Sent: Wednesday, March 13, 2013 2:38 PM To: Dale R. Worley Cc: Ejzak, Richard P (Richard); mmusic@ietf.org Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling I am just curios ... instead of playing with connection address and port nu= mbers for indicating accepting/rejecting a m=3Dline in BUNDLE O/A, would ma= king a particular m=3Dline direction inactive make things simpler .... since for m=3Dlines with direction as inactive would mean no ICE setup , no= reject port needed , no resource allocation on intermediary(?) Any thoughts ? ./Suhas On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley > wrote: > From: "Ejzak, Richard P (Richard)" > > > This is the only compatibility concern identified with the > asymmetric use of the unspecified address, but this concern is > clearly misplaced for rtcweb applications where ICE and consent are > mandatory. I'm not limiting my attention to WebRTC only. Even in situations where WebRTC is gatewayed to existing SIP infrastructure these problems appear. If we restrict ourselves to WebRTC, then we have even more freedom, and in that case, I'd simply remove the rule regarding rejects MDs as members of groups. Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_03FBA798AC24E3498B74F47FD082A92F36EB8C95US70TWXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The direction attribute i= s one that needs to be preserved for each m line to indicate direction of t= he media associated with that m line.  It is just not available for other purposes.  Furthermore, inactive does not disable ICE or RT= CP, which would still be expected to proceed.

 <= /p>

From: Suhas Na= ndakumar [mailto:suhasietf@gmail.com]
Sent: Wednesday, March 13, 2013 2:38 PM
To: Dale R. Worley
Cc: Ejzak, Richard P (Richard); mmusic@ietf.org
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bund= ling

 

I am just curios ... instead of playing with connect= ion address and port numbers for indicating accepting/rejecting a m=3Dline = in BUNDLE O/A, would making a particular m=3Dline direction inactive make t= hings simpler ....

since for m=3Dlines with direction as inactive would= mean no ICE setup , no reject port needed , no resource allocation on inte= rmediary(?) 

 

Any thoughts ?

 

./Suhas

On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

> This is the only= compatibility concern identified with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are > mandatory.

I'm not limiting my attention to WebRTC only.  = Even in situations
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear.  If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.


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

 

--_000_03FBA798AC24E3498B74F47FD082A92F36EB8C95US70TWXCHMBA12z_-- From andrew.hutton@siemens-enterprise.com Wed Mar 13 13:00:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFE321F85B1 for ; Wed, 13 Mar 2013 13:00:18 -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 p-fdtvHxrdVr for ; Wed, 13 Mar 2013 13:00:18 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E8AD021F84B2 for ; Wed, 13 Mar 2013 13:00:17 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 2AEBB1EB8614 for ; Wed, 13 Mar 2013 21:00:17 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 21:00:16 +0100 From: "Hutton, Andrew" To: "mmusic@ietf.org" Thread-Topic: Bundle, TURN and Legacy Interop Thread-Index: Ac4gJWBA5pPebVuMT3uFsh7F2mnB0Q== Date: Wed, 13 Mar 2013 20:00:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Bundle, TURN and Legacy Interop X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:00:18 -0000 Hi, It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/s= lides-86-mmusic-9.pdf). One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used. I am not sure if there is a way to avoid this other but the draft should I = think mention this issue. Regards Andy From christer.holmberg@ericsson.com Wed Mar 13 13:11:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB3C11E8152 for ; Wed, 13 Mar 2013 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.208, 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 1vOSEgTRYX-A for ; Wed, 13 Mar 2013 13:11:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79511E8174 for ; Wed, 13 Mar 2013 13:11:42 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-06-5140dd7deb2d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 17.68.32353.D7DD0415; Wed, 13 Mar 2013 21:11:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 21:11:40 +0100 From: Christer Holmberg To: "Hutton, Andrew" , mmusic_ietf.org Thread-Topic: [MMUSIC] Bundle, TURN and Legacy Interop Thread-Index: AQHOICb5AxXzpX08C0acIsAKtzXqbA== Date: Wed, 13 Mar 2013 20:11:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B126210@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B126210ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW7tXYdAg729YhZn+7rYLaYuf8zi wOSxZMlPJo8bt98zBzBFcdmkpOZklqUW6dslcGV8er6StWCXfMXRhWfYGxgXSncxcnJICJhI PL00iwnCFpO4cG89WxcjF4eQwCFGiftvrjNDOIsZJT6sfQDkcHCwCVhIdP/TBmkQEUiQWDv5 PTOILSxgKrHv1BYmiLiZxJWpNxkhbD2J/es/soDYLAKqEuv//WcDsXkFvCXmv2sD6xUS8JN4 e30mK4jNKeAvsfdpG1gNI9BB30+tAZvJLCAucevJfKhDBSSW7DnPDGGLSrx8/I8VoiZf4sCh ZmaI+YISJ2c+YZnAKDwLSfssJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzs uYmZOenl5psYgTFycMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoGx6lH5lYrfIrrb6r87cK8Jq9KyUs9zX+JXEXpCjeFZl1XC34jjz1+Zn130xWz9Eftr 3BbL6m5F/+eTn+ZX/e/KrF+2j0ucFGviuflm3ufd8YeL8z2Xik36mdA8zim/4p9J+z1gm/h+ h1LcvpJP0wPPy5ifnf+RV+PvAh6P3f3R2wQaDh5S+t6rxFKckWioxVxUnAgASWpQrV8CAAA= Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:11:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B126210ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Nothing prevents you from only sending host candidates in the first offer, = of you want to do. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] To: mmusic@ietf.org [mmusic@ietf.org] Subject: [MMUSIC] Bundle, TURN and Legacy Interop Hi, It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/s= lides-86-mmusic-9.pdf). One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used. I am not sure if there is a way to avoid this other but the draft should I = think mention this issue. Regards Andy _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B126210ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Nothing prevents you from only sending host can= didates in the first offer, of you want to do.
 
Regards,
 
Christer
 


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

-----Original Message-----
From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
To: mmusic@ietf.org [mmusic@ietf.org]
Subject: [MMUSIC] Bundle, TURN and Legacy Interop
Hi,

It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).
One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used.

I am not sure if there is a way to avoid this other but the draft should I = think mention this issue.

Regards
Andy
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B126210ESESSMB209ericsso_-- From suhasietf@gmail.com Wed Mar 13 13:25:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8519321F8CB8 for ; Wed, 13 Mar 2013 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 g7efR0dNOGOB for ; Wed, 13 Mar 2013 13:25:00 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2768B21F8C7C for ; Wed, 13 Mar 2013 13:25:00 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id 15so370194wgd.7 for ; Wed, 13 Mar 2013 13:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iEtN6ewDMlrr3b93i6UeyN8x+3rkmpZyr0jwryANgD4=; b=a38bjAAixJ5dkcstvh4Xn5DDkfmz/rxwteAIogohO1MRZl6RCPpMhYhinE0DEDRaWd 6VIsm0Rri9S5+M7mvjf+vPi3n7JMZlPkzgYx1gwe/14vXLGHYp4Lg+v1yl9uTOSkLJpN 44D/nGHJiunH03WIH+o8sV1RysFtzwPBLNMpVYgOqzqwRYwUYoft0K/J17kZ0cgqHhHa bNCC2410Zgag2xLnBH/U/mds6EjMiRfCGuxVUfawPC4htSRqLQm7/JxvOVrHRxVXWcNw yG5HgURU4S9WiybK1Y2TGjvJLiMg5GIuU4vilzX8/YPZ1NSlS/6obEJaLlLMmVnclC9y mJew== MIME-Version: 1.0 X-Received: by 10.180.85.97 with SMTP id g1mr29810334wiz.29.1363206299307; Wed, 13 Mar 2013 13:24:59 -0700 (PDT) Received: by 10.194.16.170 with HTTP; Wed, 13 Mar 2013 13:24:59 -0700 (PDT) In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EB8C95@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <201303110237.r2B2btIS180463@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB73DA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303112150.r2BLocqs234131@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB74CA@US70TWXCHMBA12.zam.alcatel-lucent.com> <201303120102.r2C12W0g240047@shell01.TheWorld.com> <03FBA798AC24E3498B74F47FD082A92F36EB8C95@US70TWXCHMBA12.zam.alcatel-lucent.com> Date: Wed, 13 Mar 2013 13:24:59 -0700 Message-ID: From: Suhas Nandakumar To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=f46d0444036c39d6b104d7d4330f Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:25:10 -0000 --f46d0444036c39d6b104d7d4330f Content-Type: text/plain; charset=ISO-8859-1 Ah ! my bad, That's true On Wed, Mar 13, 2013 at 12:42 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > The direction attribute is one that needs to be preserved for each m > line to indicate direction of the media associated with that m line. It is > just not available for other purposes. Furthermore, inactive does not > disable ICE or RTCP, which would still be expected to proceed.**** > > ** ** > > *From:* Suhas Nandakumar [mailto:suhasietf@gmail.com] > *Sent:* Wednesday, March 13, 2013 2:38 PM > *To:* Dale R. Worley > *Cc:* Ejzak, Richard P (Richard); mmusic@ietf.org > > *Subject:* Re: [MMUSIC] Difficulties accepting and rejecting with bundling > **** > > ** ** > > I am just curios ... instead of playing with connection address and port > numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would > making a particular m=line direction inactive make things simpler ....**** > > since for m=lines with direction as inactive would mean no ICE setup , no > reject port needed , no resource allocation on intermediary(?) **** > > ** ** > > Any thoughts ?**** > > ** ** > > ./Suhas**** > > On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley > wrote:**** > > > From: "Ejzak, Richard P (Richard)" > >**** > > > This is the only compatibility concern identified with the > > asymmetric use of the unspecified address, but this concern is > > clearly misplaced for rtcweb applications where ICE and consent are > > mandatory.**** > > I'm not limiting my attention to WebRTC only. Even in situations > where WebRTC is gatewayed to existing SIP infrastructure these > problems appear. If we restrict ourselves to WebRTC, then we have > even more freedom, and in that case, I'd simply remove the rule > regarding rejects MDs as members of groups.**** > > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic**** > > ** ** > --f46d0444036c39d6b104d7d4330f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ah ! my bad, That's true=A0

On Wed, M= ar 13, 2013 at 12:42 PM, Ejzak, Richard P (Richard) <<= a href=3D"mailto:richard.ejzak@alcatel-lucent.com" target=3D"_blank">richar= d.ejzak@alcatel-lucent.com> wrote:

The direction attribute i= s one that needs to be preserved for each m line to indicate direction of t= he media associated with that m line.=A0 It is just not available for other purposes.=A0 Furthermore, inactive does not disable ICE or RTCP,= which would still be expected to proceed.

=A0<= /p>

From: Suhas Na= ndakumar [mailto:s= uhasietf@gmail.com]
Sent: Wednesday, March 13, 2013 2:38 PM
To: Dale R. Worley
Cc: Ejzak, Richard P (Richard); mmusic@ietf.org


Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bund= ling

=A0

I am just curios ... instead of playing with connect= ion address and port numbers for indicating accepting/rejecting a m=3Dline = in BUNDLE O/A, would making a particular m=3Dline direction inactive make t= hings simpler ....

since for m=3Dlines with direction as inactive would= mean no ICE setup , no reject port needed , no resource allocation on inte= rmediary(?)=A0

=A0

Any thoughts ?

=A0

./Suhas=

On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

> This is the only= compatibility concern identified with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are > mandatory.

I'm not limiting my attention to WebRTC only. = =A0Even in situations
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear. =A0If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.


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

=A0


--f46d0444036c39d6b104d7d4330f-- From andrew.hutton@siemens-enterprise.com Wed Mar 13 14:00:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0F511E80DC for ; Wed, 13 Mar 2013 14:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Tg+Hb2Rhd9g5 for ; Wed, 13 Mar 2013 14:00:43 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id AC49711E80D9 for ; Wed, 13 Mar 2013 14:00:42 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E1FB61EB8561; Wed, 13 Mar 2013 22:00:41 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 22:00:41 +0100 From: "Hutton, Andrew" To: Christer Holmberg Thread-Topic: [MMUSIC] Bundle, TURN and Legacy Interop Thread-Index: Ac4gJWBA5pPebVuMT3uFsh7F2mnB0f//8m4AgAAedU4= Date: Wed, 13 Mar 2013 21:00:40 +0000 Message-ID: <4411CF98-016E-4DB1-8709-594312EDB4D1@siemens-enterprise.com> References: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net>, <7594FB04B1934943A5C02806D1A2204B126210@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B126210@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4411CF98016E4DB18709594312EDB4D1siemensenterprisecom_" MIME-Version: 1.0 Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:00:47 -0000 --_000_4411CF98016E4DB18709594312EDB4D1siemensenterprisecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is if you have been configured to use TURN and are known to need to u= se it. Andy On 13 Mar 2013, at 16:11, "Christer Holmberg" > wrote: Hi, Nothing prevents you from only sending host candidates in the first offer, = of you want to do. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] To: mmusic@ietf.org [mmusic@ietf.org] Subject: [MMUSIC] Bundle, TURN and Legacy Interop Hi, It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/s= lides-86-mmusic-9.pdf). One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used. I am not sure if there is a way to avoid this other but the draft should I = think mention this issue. Regards Andy _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_4411CF98016E4DB18709594312EDB4D1siemensenterprisecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is if you have been configured to use TURN and are known to need= to use it.

Andy

On 13 Mar 2013, at 16:11, "Christer Holmberg" <christer.holmberg@ericsson.com> w= rote:

Hi,
 
Nothing prevents you from only sending host can= didates in the first offer, of you want to do.
 
Regards,
 
Christer
 


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

-----Original Message-----
From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
To: mmusic@ietf.org [mmusic@ietf.org]
Subject: [MMUSIC] Bundle, TURN and Legacy Interop
Hi,

It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).
One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used.

I am not sure if there is a way to avoid this other but the draft should I = think mention this issue.

Regards
Andy
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
--_000_4411CF98016E4DB18709594312EDB4D1siemensenterprisecom_-- From magnus.westerlund@ericsson.com Wed Mar 13 14:48:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468321F8D2E for ; Wed, 13 Mar 2013 14:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H228j7wlPo1K for ; Wed, 13 Mar 2013 14:48:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0143221F8D22 for ; Wed, 13 Mar 2013 14:48:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-1f-5140f42b1585 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.C7.10459.B24F0415; Wed, 13 Mar 2013 22:48:28 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Mar 2013 22:48:27 +0100 Message-ID: <5140F428.2040101@ericsson.com> Date: Wed, 13 Mar 2013 17:48:24 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ross Finlayson References: <50CEE45A.3000502@alvestrand.no> <50CEE66F.8020902@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvja7OF4dAg9mvOS2mNv5ntZi6/DGL A5PHkiU/mTxWL/nDGsAUxWWTkpqTWZZapG+XwJXx/PMr1oKlAhXbTs5jbmD8x9PFyMkhIWAi sWrTLFYIW0ziwr31bF2MXBxCAicZJd5OWscE4SxnlGj+OJ0NpIpXQFti4udOFhCbRUBVYsqU newgNpuAhcTNH41gNaICwRI/X51hgagXlDg58wmQzcEhIqAlcXVSDUiYWUBY4sL540wgtrCA i8SOPV0sELuOMEq8/nsZbA6ngL1E57N5LBDXSUpsedHODtGsJzHlagsjhC0v0bx1NjOILQR0 W0NTB+sERqFZSFbPQtIyC0nLAkbmVYzsuYmZOenlhpsYgcF6cMtv3R2Mp86JHGKU5mBREucN c70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRxrL0qKasdqhjyouNx21NFtZxB7+cH1Yj dTZL2ThTYe7EORMVL/2TNNgq+bjyVXb+toO3764Ui+rffPvUmYyF0aVbnvcvy7y/75XQRaGn Ifo9sybv0ls2sz/g9uQasxteW7qz5gnHdqz9KrN6+3HDCFsZtWsNm57NLn1wdEr0x3jnfK8d jVI3lFiKMxINtZiLihMBq24lFiQCAAA= Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:48:30 -0000 WG, I hereby proposes the following text In addition to the registered default ports, i.e. 554 (rtsp) and 322 (rtsps), there are an alternative port 8554 registered. This port may provide some benefits from non-registered ports if a RTSP server is unable to use the default port. The benefits may include pre-configured security policies as well as classifiers in network monitoring tools. to be added in Section 10.2 after the first paragraph. Please comment if you see issues with this or thinks it is fine. Cheers Magnus On 2012-12-17 22:17, Ross Finlayson wrote: > (Grumple... I wish this mailing list were set up so that replies went to > the mailing list by default. Resending to the whole mailing list > instead of just Magnus.) > >> The question is if this port number has any benefit at all. > > Yes it does. If a RTSP server cannot use port 554 (most likely because > it is running on a Unix system, but not as 'root'), then it can try > using port 8554 instead. (FWIW, our RTSP server implementation - widely > used on the Internet - does this.) As you noted, if a server uses port > 8554 (or any port other than 554), then this port number will need to be > included in the "rtsp://" URLs that clients use. But it's beneficial to > know - e.g., if you're managing a network's 'security' policy - that > RTSP will likely be used on either port 554 or port 8554 (rather than > either port 554 or some unspecified other port number). Similarly, it's > useful for network monitoring tools to know that traffic on port 8554 is > likely to be RTSP. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Markus.Isomaki@nokia.com Wed Mar 13 15:20:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF021F89B5 for ; Wed, 13 Mar 2013 15:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 0rZJWGKytKKd for ; Wed, 13 Mar 2013 15:20:05 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 55B741F0D09 for ; Wed, 13 Mar 2013 15:20:04 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2DMJxsE002561; Thu, 14 Mar 2013 00:20:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 00:19:58 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0328.011; Wed, 13 Mar 2013 22:19:58 +0000 From: To: , , Thread-Topic: Question about Bundle and Legacy Interop (RE: [MMUSIC] Bundle, TURN and Legacy Interop) Thread-Index: Ac4gM9MduoawFmZZSIaG4bq0lnVGTQ== Date: Wed, 13 Mar 2013 22:19:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.65] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7623BD7B3008AM1MPN1042mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2013 22:19:59.0073 (UTC) FILETIME=[E6153510:01CE2038] X-Nokia-AV: Clean Subject: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:20:10 -0000 --_000_E44893DD4E290745BB608EB23FDDB7623BD7B3008AM1MPN1042mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A question related to legacy interop for Bundle. Bundle was originally moti= vated by RTCWeb, but since RTCWeb uses SDP, it has become a more generic SD= P issue. However, does the legacy interop issue concern RTCWeb at all, or i= s it issue purely for SIP-based devices wanting to apply Bundle? As far as I understand it, RTCWeb to Legacy interop can be accommodated by = a gateway that on one side supports all the bells and whistles of RTCWeb su= ch as Bundle and trickle-ICE, and to the other side uses existing offer/ans= wer procedures without ICE or Bundle. Right? Or is there a particular reaso= n why a WebRTC implementation should assume the other end (from its perspec= tive) won't do Bundle? I've seen some drafts claiming that Bundle would be harmful in for instance= cellular networks for QoS differentiation. Is that the motivation where th= e non-Bundled RTCWeb use comes from, or are there some other good reasons? For SIP the legacy considerations are of course much more clear. But are th= e SIP vendors interested in Bundle? Presumably the IMS SIP vendors at least= not, if it complicates their QoS setup. Markus From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Christer Holmberg Sent: 13 March, 2013 22:12 To: Hutton, Andrew; mmusic_ietf.org Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop Hi, Nothing prevents you from only sending host candidates in the first offer, = of you want to do. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] To: mmusic@ietf.org [mmusic@ietf.org] Subject: [MMUSIC] Bundle, TURN and Legacy Interop Hi, It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/s= lides-86-mmusic-9.pdf). One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used. I am not sure if there is a way to avoid this other but the draft should I = think mention this issue. Regards Andy _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E44893DD4E290745BB608EB23FDDB7623BD7B3008AM1MPN1042mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

A question related to leg= acy interop for Bundle. Bundle was originally motivated by RTCWeb, but sinc= e RTCWeb uses SDP, it has become a more generic SDP issue. However, does the legacy interop issue concern RTCWeb at all, or is it iss= ue purely for SIP-based devices wanting to apply Bundle?<= /p>

 <= /p>

As far as I understand it= , RTCWeb to Legacy interop can be accommodated by a gateway that on one sid= e supports all the bells and whistles of RTCWeb such as Bundle and trickle-ICE, and to the other side uses existing offer/answer p= rocedures without ICE or Bundle. Right? Or is there a particular reason why= a WebRTC implementation should assume the other end (from its perspective)= won’t do Bundle?

 <= /p>

I’ve seen some draf= ts claiming that Bundle would be harmful in for instance cellular networks = for QoS differentiation. Is that the motivation where the non-Bundled RTCWeb use comes from, or are there some other good reasons?

 <= /p>

For SIP the legacy consid= erations are of course much more clear. But are the SIP vendors interested = in Bundle? Presumably the IMS SIP vendors at least not, if it complicates their QoS setup.

 <= /p>

Markus<= /p>

 <= /p>

 <= /p>

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christer Holmberg
Sent: 13 March, 2013 22:12
To: Hutton, Andrew; mmusic_ietf.org
Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop

 

Hi,

 

Nothing prevents you from o= nly sending host candidates in the first offer, of you want to do.

 

Regards,<= /p>

 

Christer<= /p>

 



Sent from Windows using Tou= chDown (www.nitrodesk.com)


-----Original Message-----
From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
To: mmusic@ietf.org [mmusic@ietf.org]
Subject: [MMUSIC] Bundle, TURN and Legacy Interop<= /p>

Hi,

It seems that one of the motivations of the current bundle-03 proposal is t= hat the first offer is compatible with a legacy device and that a second of= fer is required for bundle (See http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).
One issue that I see is that if TURN is being used there could be a signifi= cant overhead in creating the first offer is multiple TURN allocations are = needed for each m-line which will all then have to be released if bundle is= used.

I am not sure if there is a way to avoid this other but the draft should I = think mention this issue.

Regards
Andy
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_E44893DD4E290745BB608EB23FDDB7623BD7B3008AM1MPN1042mgdn_-- From eckelcu@cisco.com Wed Mar 13 15:55:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E1611E8116 for ; Wed, 13 Mar 2013 15:55:37 -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 7F9ZT7jjM1H1 for ; Wed, 13 Mar 2013 15:55:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5511E8103 for ; Wed, 13 Mar 2013 15:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3403; q=dns/txt; s=iport; t=1363215336; x=1364424936; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HGRiMXv66XLrdYrZBbBcUgm1N9GpYgzSnSQR773MirQ=; b=Oiu7NMIPGLxzXxRcYD58vUGNUUY+FaQrUhOWeKcre61Brjm0xaIgjDKj HQp4KKPeSEol7TBc+XoXaHSPeZKR02hD1SnsZEH8Cm8Lh3BYWxS5Zl95N tpEfUweXqMUggsz99bmL9+GG63TjkN8lp9NKFn/lbSBOb3u+LBbH2mGkO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAH8CQVGtJXG//2dsb2JhbABDxFmBVxZ0gioBAQECAQEBAQE3NBcEAgEIEQQBAQsUCQcnCxQDAQUIAQEEARIIAYgFBgzCQBeOXyYSBoJZYQOnWoFUgTaCKA X-IronPort-AV: E=Sophos;i="4.84,840,1355097600"; d="scan'208";a="187242590" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 13 Mar 2013 22:55:36 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2DMtaF4013901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 22:55:36 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 17:55:35 -0500 From: "Charles Eckel (eckelcu)" To: "Markus.Isomaki@nokia.com" , "christer.holmberg@ericsson.com" , "andrew.hutton@siemens-enterprise.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) Thread-Index: Ac4gM9MduoawFmZZSIaG4bq0lnVGTQACchYg Date: Wed, 13 Mar 2013 22:55:34 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D3FC7@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:55:37 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Markus.Isomaki@nokia.com > Sent: Wednesday, March 13, 2013 6:20 PM > To: christer.holmberg@ericsson.com; andrew.hutton@siemens- > enterprise.com; mmusic@ietf.org > Subject: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, > TURN and Legacy Interop) >=20 > Hi, >=20 >=20 >=20 > A question related to legacy interop for Bundle. Bundle was originally > motivated by RTCWeb, but since RTCWeb uses SDP, it has become a more > generic SDP issue. However, does the legacy interop issue concern RTCWeb > at all, or is it issue purely for SIP-based devices wanting to apply Bund= le? >=20 >=20 >=20 > As far as I understand it, RTCWeb to Legacy interop can be accommodated > by a gateway that on one side supports all the bells and whistles of RTCW= eb > such as Bundle and trickle-ICE, and to the other side uses existing > offer/answer procedures without ICE or Bundle. Right? Or is there a > particular reason why a WebRTC implementation should assume the other > end (from its perspective) won't do Bundle? >=20 >=20 >=20 > I've seen some drafts claiming that Bundle would be harmful in for instan= ce > cellular networks for QoS differentiation. Is that the motivation where t= he > non-Bundled RTCWeb use comes from, or are there some other good > reasons? Not just for cellular but for any scenario in which QoS is based on using d= ifferent 5-tuples for media flows for which different treatment is desired. Cheers, Charles >=20 > For SIP the legacy considerations are of course much more clear. But are = the > SIP vendors interested in Bundle? Presumably the IMS SIP vendors at least > not, if it complicates their QoS setup. >=20 >=20 >=20 > Markus >=20 >=20 >=20 >=20 >=20 > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Christer Holmberg > Sent: 13 March, 2013 22:12 > To: Hutton, Andrew; mmusic_ietf.org > Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > Nothing prevents you from only sending host candidates in the first offer= , of > you want to do. >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) >=20 >=20 > -----Original Message----- > From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > To: mmusic@ietf.org [mmusic@ietf.org] > Subject: [MMUSIC] Bundle, TURN and Legacy Interop >=20 > Hi, >=20 > It seems that one of the motivations of the current bundle-03 proposal is > that the first offer is compatible with a legacy device and that a second= offer > is required for bundle (See > http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf). >=20 > One issue that I see is that if TURN is being used there could be a signi= ficant > overhead in creating the first offer is multiple TURN allocations are nee= ded > for each m-line which will all then have to be released if bundle is used= . >=20 > I am not sure if there is a way to avoid this other but the draft should = I think > mention this issue. >=20 > Regards > Andy > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From randy@qti.qualcomm.com Wed Mar 13 19:11:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDA321F8A08 for ; Wed, 13 Mar 2013 19:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.431 X-Spam-Level: X-Spam-Status: No, score=-101.431 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_HTML_ONLY=1.457, 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 zX5pDz8Xoc+9 for ; Wed, 13 Mar 2013 19:11:00 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C221F89EE for ; Wed, 13 Mar 2013 19:10:59 -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=1363227060; x=1394763060; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=JfGo+5WmkpguiNM/U1D6nT9uj6Z0X0pLE05JwsTwfWI=; b=j9MsfcIkXuOgWMX/2UbCCOhfTHEyvsXed8xONSaa718XKI7yEhS3Z9tZ VEJxLKTgZ7XNGZRxUz1L7sULQ/VsRniT9TGzYPbjWiQhuW+JL5EYTQRac r0FrtNlVuU11bHdXrC2STrvkMkQu+lIjsfISjCTSdrCuG3T7T7/KhUpKx k=; X-IronPort-AV: E=Sophos;i="4.84,840,1355126400"; d="scan'208,217";a="29891117" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 13 Mar 2013 19:10:45 -0700 X-IronPort-AV: E=Sophos;i="4.84,840,1355126400"; d="scan'208,217";a="451207149" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2013 19:10:45 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Mar 2013 19:10:43 -0700 Message-ID: In-Reply-To: <513E504F.1010209@omnitor.se> References: <513E504F.1010209@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 13 Mar 2013 19:10:15 -0700 To: Gunnar Hellstrom , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 02:11:02 -0000 Re: [MMUSIC] draft-gellens-negotiating-human-language-02
At 10:44 PM +0100 3/11/13, Gunnar Hellstrom wrote:

Before this discussion got its home in mmusic, we discussed quite similar topics as you, Dale brought up now.

It was about what was needed to be expressed by the parameters and if SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could be a suitable mechanism for routing and decisions on the parameters.

Here is part of that discussion that we need to capture.


I see some complication that might be needed in order to reflect reality. At least they should be discussed.

And I am also seeing some different ways to specify it.

The complications to discuss are:

1. Level of preference.

There may be a need for specifying levels of preference for languages.  I might strongly prefer to talk English, but have some useful capability in French. I want to display that preference and that capability with that difference, so that I get English whenever possible, but get the call connected even if English is not available at all but French is.

I would assume that two levels are sufficient, but that can be discussed:  Preferred and capable.

The draft already proposes that languages be listed in order of preference, which should handle the example you mention: you list English first and French second.  The called party selects English if it is capable and falls back to French if English is not and French is.  This seems much simpler and is a common way of handling situations where there is a preference.  It would be good to keep the mechanism as simple as possible.
Yes, I am afraid of complicating this beyond the point when users do not manage to get their settings right.
Still, I do not think that the order is sufficient as level of preference indicator. You may want to indicate capability for one modality but preference for another. ( as my example, capability for ASL, but preference for talking and reading )

If you have a capability for ASL but preference for talking and reading, you could initially offer two media streams: a voice with English and a text with English.  If accepted, you have your preferred communications.  If those are rejected you could then offer video with ASL.  Would that handle the case?
No, video is still very valuable for judging the emergency case. Or seeing a friend. So, if you support it you want to offer it. But the decision on languages and modalities may end up in video being not important for language communication.

If you don't care about language for a media stream (e.g., the video in your example) then simply leave off the language tag when offering that media.


2. Directionality
There is a need for a direction of the language preference. "Transmit, receive or both". or   "Produce, perceive or both". That is easy to understand for the relay service examples.
A hard-of-hearing user may declare:

Text, capable, produce, English
Text, prefer, perceive, English
Audio, prefer, produce, English
Audio, capable, perceive, English    ( tricky, a typical hard-of-hearing user may have benefit of receiving audio, while it is not usable enough for reliable perception. I do not want to see this eternally complex, but I see a need for refined expressions here)
video, capable, both, ASL 

This should be understood as that the user prefers to speak and get text back, and has benefit of getting voice in parallel with text.  ASL signing can be an alternative if the other party has corresponding capability or preference.


The draft does support this (and even mentions some of these specific uses) because it proposes an SDP media attribute, and media can be specified to be send, receive, or both.
No, that is not the same. You want the media to flow, but by the parameter you want to indicate your preference for how to use it.  You do not want to turn off incoming audio just because you prefer to talk but read text.


Yes, I see, thanks for the clarification.  Does this need to be part of the session setup?  If you establish all media streams that you wish to use, can you then just use them as you prefer?  I will consult with the NENA accessibility committee on this.
No, there are specific services providing service with one direction but not the other. The information is needed for decision on what assisting service to invoke. One such service is the captioned telephony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a very strong preference for getting just that service, but could accept with much lower preference to get a direct conversation with the far end in combined text and voice.

I think it would be better to have a different mechanism for requesting services (such as captioned telephony) rather than trying to pack everything into language.


I think it would be useful  to move most of the introduction to a structured use case chapter and express the different cases according to a template. Thast can then be used to test if proposed approaches will work.

I'm not sure I fully understand what you mean by "structured" in "structured use case" or "template."  Can you be more specific?
I mean just a simple template for how the use case descriptions are written.

E.g.
A title indicating what case we have.
Description of the calling user and its capabilities and preferences.
Description of the answering user and its capabilities and preferences
Description of a possible assisting service and its capabilities and preferences
Description of the calling user's indications.
Description of the answering user's indications.
The resulting decision and outcome

I agree that the Introduction needs to be made more clear as to the purpose of the document and the problem it is solving, and the use cases be more detailed and clear.  I don't know yet if a formal template is needed or not, but more detailed use cases would be helpful.


3.  Specify language and modality at SIP Media tag level instead.
There could be some benfits to declare these parameters at the SIP media tag level instead of SDP level.
A call center can then register with their capabilities already at the SIP REGISTER time, and the caller preferences / callee capabilities mechanism from RFC 3840/ 3841 can be used to select modalities and languages and route the call to the best capable person or combination of person and assisting interpreting.

Maybe, but one advantage of using SDP is that the ESInet can take language and media needs into account during policy-based routing.  For example, in some European countries emergency calls placed by a speaker of language x in country y may be routed to a PSAP in a country where x is the native language.  Or, there might be regional or national text relay or sign language interpreter services as opposed to PSAP-level capabilities.
Is there a complete specification for how policy based routing is thought to work? Where?
Does it not use RFC 3840/3841?
That procedure is already supported by SIP servers. Using SDP requires new SIP server programming.

NENA has a document under development.  I thought it was able to take SDP into account but I'll look into it, and I'm sure Brian will have something to say.
Yes, I think I have seen that. But it needs to come into IETF to be possible to refer to.

We don't need to refer to it in this document.  It would refer to this document.


But, on the other hand, then we need a separate specification of what modality the parameters indicate, because the language tags only distinguish between signed and other languages, and "other" seems to mean either spoken or written without any difference.


The SDP media already indicates the type (audio, video, text).
Yes, convenient. But there is no knowledge about the parameters until at call time. It could be better to know the callee capabilities in advance if available. Then middle boxes can do the routing instead of the far end. There may be many terminals competing for the call and the comparison about who to get it should be done by a sip server instead of an endpoint.


I think call time is the right time.  For emergency calls, it isolates the decision making about how to process calls requiring text, sign language, foreign language, etc. to the ESInet and PSAPs, which is I think the right place.  The processing rules in the ESInet can then be changed without involving any carrier.  The capabilities of an entity may vary based on dynamic factors (time of day, load, etc.) so the decision as to how to support a need may be best made by the ESInet or PSAP in the case of an emergency call, or called party for non-emergency calls.  For example, at some times or under some loads, emergency calls may be routed to a specific PSAP that is not the geographically indicated one.  Likewise, a non-emergency call to a call center may be routed to a center in a country that has support for the language or media needed.
The decision is of course made at call time. With the RFC 3840/3841 method, the different agents and services available register their availability and capabilities when they go on duty, and unregister when they stop, so that their information is available at call time.

Language and media go together; consider that in the example of emergency services, not all PSAPs will be capable of accepting all media.  Smaller PSAPs may have arrangements with larger ones to handle some forms of media and some languages, or may bridge in third parties to translate/interpret the media and/or language.  Hence the use of SDP makes sense for both.

 



Further, it is often the case that the cost of relay, interpretation, or translation services is affected by which entity invokes the service.
Yes, that is a complicating policy issue.


4. Problem that 3GPP specifies that it is the UAs only who specify and act on these parameters.
I think it is a problem that 3GPP inserted the restriction that the language and modality negotiation shall only bother the involved UAs.
It would be more natural that it is a service provider between them who detect the differences and make the decision to invoke a relay service for the relay case.
How do you propose to solve that? Let the service provider behave as a B2BUA, who then can behave as both a UA and a service provider?

What do you mean by "service provider?"  In the case of a voice service provider such as a cellular carrier or a VoIP provider, I think this should be entirely transparent.  The voice service provider knows it is an emergency call and routes to an ESInet.  It is then up to the ESInet and the PSAPs to handle the call as they wish.
It can be a service provider for just the function to make advanced call invocation based on language preferences. The same type of decisions, call connections and assisting service invocation are needed in everyday calls as in emergency calls. But it can also be a service provider for emergency services and the user is registered by that service provider. They can make decisions on the call. E.g. detect that it is an emergency call requiring interpreter, and therefore connect to both the PSAP and interpreter at the same time to save time.

I think it's best to make these decisions at the end, not the middle.  In the case of emergency calls, the ESInet can route to a particular PSAP, the PSAP may bridge in translation or interpretation services, etc.  In the case of non-emergency calls, the call center may support some capabilities locally at some hours but route to a different call center at other times.
The end is not decided until you have evaluated the alternative possible ends and decided who has the right capability and preference.

Neither the UE nor the carrier (service provider) should need to be involved in this.  In the case of emergency services, let the ESInet handle it; then there is a single entity that needs to be updated.  In the case of a corporate call center, let the call center's internal router handle it.  Internally, it may use the SIP registration mechanism, but that's out of scope of this document.


There is another issue with using sdp for decisions. SIP Message is included in the set of methods to handle in emergency calls in RFC 6443. It can be used within sessions to carry text messages if other media are used as well. It is no favored way to have text communication, but possible. SIP message has no sdp.  I know that the 3GPP sections  about emergency calling in TS 22.101 points towards using MSRP for text messaging, so it should not be an issue for 3GPP. Can we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media?  I do not urge for solving it for SIP Message, I just wanted to point out that result by basing the mechanism on SDP.

 


Will there be a possibility for remote participation on Thursday. I am sorry I am not there, but would like to participate if possible.

I am sorry you won't be here.  There was not time to get this on the mmusic agenda, so it is an informal lunch meeting on Thursday at the hotel cafe, hence I do not think any remote participation, unless one of the people present wants to set up a laptop with a video call (I am planning to use pen and paper for my notes).
 


On 2013-03-11 16:57, Randall Gellens wrote:
[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:
 (It's not clear to me what the proper mailing list is to discuss this
 draft.  From the headers of the messages, it appears that the primary
 list is ietf@ietf.org, but the first message in this thread about that
 draft already has a "Re:" in the subject line, so the discussion
 started somewhere else.)

There has been some discussion among those listed in the CC header of this message.  I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft.

By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal).  Please let me know if you can make it.
 (Also, it's not clear why Randall's messages are coming through in
 HTML.)

My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well.
 But onward to questions of substance:

 - Why SDP and not SIP?

 I'd like to see a more thorough exploration of why language
 negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
 uses the Content-Language header to specify languages.)  In principle,
 specifying data that may be used in call-routing should be done in the
 SIP layer, but it's well-accepted in the SIP world that call routing
 may be affected by the SDP content as well (e.g., media types).

I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video.
 And some discussion and comparison should be done with the SIP/HTTP
 Content-Language header (used to specify the language of the
 communications) and the SIP Accept-Language header (used to specify
 the language of text components of SIP messages), particularly given
 that Accept-Language has different set of language specifiers and a
 richer syntax for specifying preferences.  In any case, preference
 should be given to reusing one of the existing syntaxes for specifying
 language preferences.

I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL.  (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.)

As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute.
 - Dependency between media descriptions?

    Another example would be a user who is able to speak but is deaf or
    hard-of-hearing and requires a voice stream plus a text stream
    (known as voice carry over).  Making language a media attribute
    allows the standard session negotiation mechanism to handle this by
    providing the information and mechanism for the endpoints to make
    appropriate decisions.

 This scenario suggests that there might be dependency or interaction
 between language specifications for different media descriptions.
 Whether this is needed should be determined and documented.

 - Specifying preference levels?

    For example, some users may be able to speak several languages, but
    have a preference.

 This might argue for describing degrees of preference using "q"
 parameters (as in the SIP Accept-Language header).

 - Expressing multiple languages in answers

    (While it is true that a conversation among multilingual people
    often involves multiple languages, it does not seem useful enough
    as a general facility to warrant complicating the desired semantics
    of the SDP attribute to allow negotiation of multiple simultaneous
    languages within an interactive media stream.)

 Why shouldn't an answer be able to indicate multiple languages?  At
 the least, this might provide the offerer with useful information.

You raise good questions that I think need more discussion.  I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately.

 - Reusing a=lang

 Searching, I can only find these descriptions of the use of
 "a=lang:...":

     RFC 4566
     draft-saintandre-sip-xmpp-chat
     draft-gellens-negotiating-human-language

 So it looks like "a=lang:..." is entirely unused at the present and is
 safe to be redefined.







_______________________________________________
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: ---------------
We have met the enemy, and he is us.
                      --Walt Kelly
From ted.ietf@gmail.com Wed Mar 13 19:17:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50921F8DA0 for ; Wed, 13 Mar 2013 19:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, 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 UvCuAqEDKTV4 for ; Wed, 13 Mar 2013 19:17:38 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F3D4421F8D9C for ; Wed, 13 Mar 2013 19:17:37 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id k13so2381472iea.35 for ; Wed, 13 Mar 2013 19:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YqRS+krIJU+3dbVDxX+P4AYulZSfYA6Rhn6in7cq+Bo=; b=VAKyThS6gHnsbEYFAuQrQ36rSgHDlPF3jTWrGTlgR6Oye42HoyP1Ind4mjYmudWuSM Bjev4jo14VCkllfN2stqx80kCN/AnbVue+3tAkZmwiPVmexgc62wrhQQVf/C6zkF4Xbj rWQbjJmixPJv9AOGSc6eOQBKe7HS2YPen9MFLjUnJNLR2sXzvObnOe9qQjtSV37WkDNM n00F0joPi2Oiwc1nEUqTaq/yR92VhH6JZNDLxcVHZcagRIg6T5N3bGUS62L3DHa2+8PM uL0NqMrlaOyput8qWD0eulwt932n3T8n44L9FEtvht0yWT6qtlmJDRCwXU0RpREQ6eI4 ITDA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr18780906igj.96.1363227457642; Wed, 13 Mar 2013 19:17:37 -0700 (PDT) Received: by 10.43.135.202 with HTTP; Wed, 13 Mar 2013 19:17:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 22:17:37 -0400 Message-ID: From: Ted Hardie To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 02:17:38 -0000 On Wed, Mar 13, 2013 at 6:19 PM, wrote: > A question related to legacy interop for Bundle. Bundle was originally > motivated by RTCWeb, but since RTCWeb uses SDP, it has become a more generic > SDP issue. However, does the legacy interop issue concern RTCWeb at all, or > is it issue purely for SIP-based devices wanting to apply Bundle? > Hi Markus, The rtcweb charter says "There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients." I believe we have generally read that to mean that the focus should be on browser-based clients and interop with non-WebRTC endpoints may end up relying on gateways or other intermediaries. My personal view, not a consensus view of the chairs, regards, Ted Hardie From randy@qti.qualcomm.com Wed Mar 13 19:28:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1849A21F8ADC for ; Wed, 13 Mar 2013 19:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.396 X-Spam-Level: X-Spam-Status: No, score=-100.396 tagged_above=-999 required=5 tests=[AWL=-1.851, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 O1XYQWZnKQel for ; Wed, 13 Mar 2013 19:28:09 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC821F8AD8 for ; Wed, 13 Mar 2013 19:28:09 -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=1363228089; x=1394764089; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=lKOii4CgEjlnDtwT2HHRT7v8VRprngVN4L3jeD52v8U=; b=fudvZdgzq9vFWaAnFHpMQfVdPPoXbFasMUh8zfNMy5DwjKpQOa1euuEp epcEg8CUkwqnFb2GJrM6s/JAgYWzw7dpb3RE0PEwyt2vi8FHPO8UW2KDH Zfpm7i/ytjkLOlDdSndWyqsZFwJtoMwl7lUXPmxeI6TvvK8s92DvFvR9J s=; X-IronPort-AV: E=Sophos;i="4.84,840,1355126400"; d="scan'208,217";a="29915124" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 13 Mar 2013 19:27:50 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2013 19:27:50 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Mar 2013 19:27:49 -0700 Message-ID: In-Reply-To: References: <513E504F.1010209@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 13 Mar 2013 19:13:04 -0700 To: Francois Audet , Gunnar Hellstrom , "mmusic@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 02:28:11 -0000 Re: [MMUSIC] draft-gellens-negotiating-human-language-02
Call centers and emergency services.

I think it would be difficult to get this into a URL parameter.  Also, there may be one language for a voice or text stream (e.g., English), and another language for a video stream (e.g., ASL).  Hence, a single parameter may not work because it needs to express both desired media and desired language.

At 10:23 PM +0000 3/11/13, Francois Audet wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
     boundary=3D"_000_ba5960bc7f784aeab46571825f8ef969DFMDB3MBX1506exchangeco_"
I tought about this a while ago. I guess this is a contact center scenario.
 
While it would certainly be possible to express your caller pref using q-values, it seems the wrong way to approach the problem. Really, what you want is the caller resource to be of a specific language. Therefore, I think that rather, the URL itself should have the information to map it to the appropriate agent. Kind of similar to 1-800-help-product, 1800-aide-produit, but with a SIP URI. You could use a parameter sip:help@example.com?lang=3Den or it could be in the URI itself, SIP:help?example.com/en or SIP:en@example.com.
 
The calling party would consult the directory and select the desired language. This approach also eliminates the confusing "feature" of having an answer in a different language than you expect=8A
 
My 2 cents.
 
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gunnar Hellstrom
Sent: Monday, March 11, 2013 2:45 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02
 
Before this discussion got its home in mmusic, we discussed quite similar topics as you, Dale brought up now.

It was about what was needed to be expressed by the parameters and if SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could be a suitable mechanism for routing and decisions on the parameters.

Here is part of that discussion that we need to capture.


I see some complication that might be needed in order to reflect reality. At least they should be discussed.

And I am also seeing some different ways to specify it.

The complications to discuss are:

1. Level of preference.

There may be a need for specifying levels of preference for languages.  I might strongly prefer to talk English, but have some useful capability in French. I want to display that preference and that capability with that difference, so that I get English whenever possible, but get the call connected even if English is not available at all but French is.

I would assume that two levels are sufficient, but that can be discussed:  Preferred and capable.
 
The draft already proposes that languages be listed in order of preference, which should handle the example you mention: you list English first and French second.  The called party selects English if it is capable and falls back to French if English is not and French is.  This seems much simpler and is a common way of handling situations where there is a preference.  It would be good to keep the mechanism as simple as possible.
Yes, I am afraid of complicating this beyond the point when users do not manage to get their settings right.
Still, I do not think that the order is sufficient as level of preference indicator. You may want to indicate capability for one modality but preference for another. ( as my example, capability for ASL, but preference for talking and reading )
 
If you have a capability for ASL but preference for talking and reading, you could initially offer two media streams: a voice with English and a text with English.  If accepted, you have your preferred communications.  If those are rejected you could then offer video with ASL.  Would that handle the case?
No, video is still very valuable for judging the emergency case. Or seeing a friend. So, if you support it you want to offer it. But the decision on languages and modalities may end up in video being not important for language communication.

 
 
2. Directionality
There is a need for a direction of the language preference. "Transmit, receive or both". or   "Produce, perceive or both". That is easy to understand for the relay service examples.
A hard-of-hearing user may declare:

Text, capable, produce, English
Text, prefer, perceive, English
Audio, prefer, produce, English
Audio, capable, perceive, English    ( tricky, a typical hard-of-hearing user may have benefit of receiving audio, while it is not usable enough for reliable perception. I do not want to see this eternally complex, but I see a need for refined expressions here)
video, capable, both, ASL 

This should be understood as that the user prefers to speak and get text back, and has benefit of getting voice in parallel with text.  ASL signing can be an alternative if the other party has corresponding capability or preference.
 
 
The draft does support this (and even mentions some of these specific uses) because it proposes an SDP media attribute, and media can be specified to be send, receive, or both.
No, that is not the same. You want the media to flow, but by the parameter you want to indicate your preference for how to use it.  You do not want to turn off incoming audio just because you prefer to talk but read text.
 
Yes, I see, thanks for the clarification.  Does this need to be part of the session setup?  If you establish all media streams that you wish to use, can you then just use them as you prefer?  I will consult with the NENA accessibility committee on this.
No, there are specific services providing service with one direction but not the other. The information is needed for decision on what assisting service to invoke. One such service is the captioned telephony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a very strong preference for getting just that service, but could accept with much lower preference to get a direct conversation with the far end in combined text and voice.
 
 
I think it would be useful  to move most of the introduction to a structured use case chapter and express the different cases according to a template. Thast can then be used to test if proposed approaches will work.
 
I'm not sure I fully understand what you mean by "structured" in "structured use case" or "template."  Can you be more specific?
I mean just a simple template for how the use case descriptions are written.

E.g.
A title indicating what case we have.
Description of the calling user and its capabilities and preferences.
Description of the answering user and its capabilities and preferences
Description of a possible assisting service and its capabilities and preferences
Description of the calling user's indications.
Description of the answering user's indications.
The resulting decision and outcome
 


3.  Specify language and modality at SIP Media tag level instead.
There could be some benfits to declare these parameters at the SIP media tag level instead of SDP level.
A call center can then register with their capabilities already at the SIP REGISTER time, and the caller preferences / callee capabilities mechanism from RFC 3840/ 3841 can be used to select modalities and languages and route the call to the best capable person or combination of person and assisting interpreting.
 
Maybe, but one advantage of using SDP is that the ESInet can take language and media needs into account during policy-based routing.  For example, in some European countries emergency calls placed by a speaker of language x in country y may be routed to a PSAP in a country where x is the native language.  Or, there might be regional or national text relay or sign language interpreter services as opposed to PSAP-level capabilities.
Is there a complete specification for how policy based routing is thought to work? Where?
Does it not use RFC 3840/3841?
That procedure is already supported by SIP servers. Using SDP requires new SIP server programming.
 
NENA has a document under development.  I thought it was able to take SDP into account but I'll look into it, and I'm sure Brian will have something to say.
Yes, I think I have seen that. But it needs to come into IETF to be possible to refer to.
 
 
But, on the other hand, then we need a separate specification of what modality the parameters indicate, because the language tags only distinguish between signed and other languages, and "other" seems to mean either spoken or written without any difference.
 
 
The SDP media already indicates the type (audio, video, text).
Yes, convenient. But there is no knowledge about the parameters until at call time. It could be better to know the callee capabilities in advance if available. Then middle boxes can do the routing instead of the far end. There may be many terminals competing for the call and the comparison about who to get it should be done by a sip server instead of an endpoint.
 
I think call time is the right time.  For emergency calls, it isolates the decision making about how to process calls requiring text, sign language, foreign language, etc. to the ESInet and PSAPs, which is I think the right place.  The processing rules in the ESInet can then be changed without involving any carrier.  The capabilities of an entity may vary based on dynamic factors (time of day, load, etc.) so the decision as to how to support a need may be best made by the ESInet or PSAP in the case of an emergency call, or called party for non-emergency calls.  For example, at some times or under some loads, emergency calls may be routed to a specific PSAP that is not the geographically indicated one.  Likewise, a non-emergency call to a call center may be routed to a center in a country that has support for the language or media needed.
The decision is of course made at call time. With the RFC 3840/3841 method, the different agents and services available register their availability and capabilities when they go on duty, and unregister when they stop, so that their information is available at call time.
 
 
Further, it is often the case that the cost of relay, interpretation, or translation services is affected by which entity invokes the service.
Yes, that is a complicating policy issue.
 
 
4. Problem that 3GPP specifies that it is the UAs only who specify and act on these parameters.
I think it is a problem that 3GPP inserted the restriction that the language and modality negotiation shall only bother the involved UAs.
It would be more natural that it is a service provider between them who detect the differences and make the decision to invoke a relay service for the relay case.
How do you propose to solve that? Let the service provider behave as a B2BUA, who then can behave as both a UA and a service provider?
 
What do you mean by "service provider?"  In the case of a voice service provider such as a cellular carrier or a VoIP provider, I think this should be entirely transparent.  The voice service provider knows it is an emergency call and routes to an ESInet.  It is then up to the ESInet and the PSAPs to handle the call as they wish.
It can be a service provider for just the function to make advanced call invocation based on language preferences. The same type of decisions, call connections and assisting service invocation are needed in everyday calls as in emergency calls. But it can also be a service provider for emergency services and the user is registered by that service provider. They can make decisions on the call. E.g. detect that it is an emergency call requiring interpreter, and therefore connect to both the PSAP and interpreter at the same time to save time.
 
I think it's best to make these decisions at the end, not the middle.  In the case of emergency calls, the ESInet can route to a particular PSAP, the PSAP may bridge in translation or interpretation services, etc.  In the case of non-emergency calls, the call center may support some capabilities locally at some hours but route to a different call center at other times.

The end is not decided until you have evaluated the alternative possible ends and decided who has the right capability and preference.



There is another issue with using sdp for decisions. SIP Message is included in the set of methods to handle in emergency calls in RFC 6443. It can be used within sessions to carry text messages if other media are used as well. It is no favored way to have text communication, but possible. SIP message has no sdp.  I know that the 3GPP sections  about emergency calling in TS 22.101 points towards using MSRP for text messaging, so it should not be an issue for 3GPP. Can we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media?  I do not urge for solving it for SIP Message, I just wanted to point out that result by basing the mechanism on SDP.

 




Will there be a possibility for remote participation on Thursday. I am sorry I am not there, but would like to participate if possible.
/Gunnar
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-03-11 16:57, Randall Gellens wrote:
[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:
 (It's not clear to me what the proper mailing list is to discuss this
 draft.  From the headers of the messages, it appears that the primary
 list is ietf@ietf.org, but the first message in this thread about that
 draft already has a "Re:" in the subject line, so the discussion
 started somewhere else.)

There has been some discussion among those listed in the CC header of this message.  I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft.

By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal).  Please let me know if you can make it.
 (Also, it's not clear why Randall's messages are coming through in
 HTML.)

My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well.

 But onward to questions of substance:

 - Why SDP and not SIP?

 I'd like to see a more thorough exploration of why language
 negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
 uses the Content-Language header to specify languages.)  In principle,
 specifying data that may be used in call-routing should be done in the
 SIP layer, but it's well-accepted in the SIP world that call routing
 may be affected by the SDP content as well (e.g., media types).

I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video.

 And some discussion and comparison should be done with the SIP/HTTP
 Content-Language header (used to specify the language of the
 communications) and the SIP Accept-Language header (used to specify
 the language of text components of SIP messages), particularly given
 that Accept-Language has different set of language specifiers and a
 richer syntax for specifying preferences.  In any case, preference
 should be given to reusing one of the existing syntaxes for specifying
 language preferences.

I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL.  (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.)

As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute.
 - Dependency between media descriptions?

    Another example would be a user who is able to speak but is deaf or
    hard-of-hearing and requires a voice stream plus a text stream
    (known as voice carry over).  Making language a media attribute
    allows the standard session negotiation mechanism to handle this by
    providing the information and mechanism for the endpoints to make
    appropriate decisions.

 This scenario suggests that there might be dependency or interaction
 between language specifications for different media descriptions.
 Whether this is needed should be determined and documented.

 - Specifying preference levels?

    For example, some users may be able to speak several languages, but
    have a preference.

 This might argue for describing degrees of preference using "q"
 parameters (as in the SIP Accept-Language header).

 - Expressing multiple languages in answers

    (While it is true that a conversation among multilingual people
    often involves multiple languages, it does not seem useful enough
    as a general facility to warrant complicating the desired semantics
    of the SDP attribute to allow negotiation of multiple simultaneous
    languages within an interactive media stream.)

 Why shouldn't an answer be able to indicate multiple languages?  At
 the least, this might provide the offerer with useful information.

You raise good questions that I think need more discussion.  I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately.

 - Reusing a=3Dlang

 Searching, I can only find these descriptions of the use of
 "a=3Dlang:...":

     RFC 4566
     draft-saintandre-sip-xmpp-chat
     draft-gellens-negotiating-human-language

 So it looks like "a=3Dlang:..." is entirely unused at the present and is
 safe to be redefined.




 

_______________________________________________
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: ---------------
Computers are not intelligent.  They only think they are.
From Markus.Isomaki@nokia.com Wed Mar 13 19:57:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883C11E80A3 for ; Wed, 13 Mar 2013 19:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Z0LcLgeqsKQs for ; Wed, 13 Mar 2013 19:57:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id CA6B311E809C for ; Wed, 13 Mar 2013 19:57:42 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2E2vZch007415; Thu, 14 Mar 2013 04:57:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 04:57:35 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 02:57:34 +0000 From: To: Thread-Topic: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) Thread-Index: AQHOIFobjnj4CWngkESdJ/Ha868olZikd41g Date: Thu, 14 Mar 2013 02:57:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2013 02:57:35.0538 (UTC) FILETIME=[AE1C1120:01CE205F] X-Nokia-AV: Clean Cc: mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 02:57:43 -0000 Hi, Ted Hardie wrote: > >On Wed, Mar 13, 2013 at 6:19 PM, wrote: >> A question related to legacy interop for Bundle. Bundle was originally >> motivated by RTCWeb, but since RTCWeb uses SDP, it has become a more >> generic SDP issue. However, does the legacy interop issue concern >> RTCWeb at all, or is it issue purely for SIP-based devices wanting to ap= ply >Bundle? >> > >Hi Markus, > >The rtcweb charter says "There is a desire to standardize the basis >for such communication so that interoperable communication can be >established between any compatible browsers. The goal is to enable >innovation on top of a set of basic components. One core component is to >enable real-time media like audio and video, a second is to enable data >transfer directly between clients." I believe we have generally read that= to >mean that the focus should be on browser-based clients and interop with >non-WebRTC endpoints may end up relying on gateways or other >intermediaries. > Agree.=20 That's exactly why I'm trying to understand how much the various Bundle-lik= e proposals make pure WebRTC pay for=20 a) WebRTC-to-legacy interop=20 b) SIP's internal legacy interop issues, by the fact that SIP will also wan= t to use the same bundle mechanism and that imposes restrictions to the com= monly used solution "a)" would be to some extent acceptable although I think gateways can be re= lied quite heavily in that case to do the job, while "b)" sounds a bit sill= y. But perhaps that was part of the bargain when SDP was adopted for RTCWeb= ... In additon to legacy interop there looms the requirement in general to be a= ble to negotiate non-Bundle in WebRTC (or SIP?) for certain QoS schemes to = apply. But that should be the fallback and not the default. An ideal solution would work without added penalties, and perhaps we can ge= t one. What would definitely help is an entire message-flow, including (tri= ckle-)ICE, that would show that RTCWeb call setup is not in Browser-to-Brow= ser case made slower because of (SIP's?) legacy interop issues. That could = answer for instance to Andy Hutton's TURN gathering for all offered m-lines= /ports issue.=20 Markus=20 From pkyzivat@alum.mit.edu Wed Mar 13 20:56:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745A621F8C4F for ; Wed, 13 Mar 2013 20:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.257, 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 lsRpdWu0qCoC for ; Wed, 13 Mar 2013 20:56:57 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id AE84121F8C3B for ; Wed, 13 Mar 2013 20:56:57 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta09.emeryville.ca.mail.comcast.net with comcast id BFUk1l0020x6nqcA9FwxVr; Thu, 14 Mar 2013 03:56:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:2006:56e9:cf8b:4ea7]) by omta12.emeryville.ca.mail.comcast.net with comcast id BFww1l00U2CH3Z58YFwxRX; Thu, 14 Mar 2013 03:56:57 +0000 Message-ID: <51414A88.6040108@alum.mit.edu> Date: Thu, 14 Mar 2013 11:56:56 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: 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=1363233417; bh=bJC3/P8h0j+LaSCUhgHT1aXN35tqXE+8J5pUoVGROhk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZSG2hLnFTt/Ak4TPz86TXUMtsFe9Khuup7u2k9zANBK0vVDD3dCpw7R62RXpBDQMw kaOt46UeSX1r86VozYrdKUAUUU2iPxfQijoMZZUwCEfiX/0CVBCUxQncqbOJB+tfwm BHmrGrQxvouf7gY/sMD6FGUwlIao7bktivML+IovBufMEYRutW3n/l0eA+Vi3M1iPh YF67KFDUW6HakuiAJlM3U/0YZcLKt9vFrZPeY9kVSz0iYxnNy4ThZLKlI1mR+7NkLa Of7MDfrWp7D0JbstOq+uO/j13KwKm9HIglMbQf7l6W1FyuaxDPEr0blrhh/t2HLPb8 KGjxYWd4vZWZw== Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 03:56:58 -0000 On 3/14/13 6:19 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > A question related to legacy interop for Bundle. Bundle was originally > motivated by RTCWeb, but since RTCWeb uses SDP, it has become a more > generic SDP issue. However, does the legacy interop issue concern RTCWeb > at all, or is it issue purely for SIP-based devices wanting to apply Bundle? > > As far as I understand it, RTCWeb to Legacy interop can be accommodated > by a gateway that on one side supports all the bells and whistles of > RTCWeb such as Bundle and trickle-ICE, and to the other side uses > existing offer/answer procedures without ICE or Bundle. Right? Or is > there a particular reason why a WebRTC implementation should assume the > other end (from its perspective) won’t do Bundle? IMO there is an (at least implicit) goal that a sufficiently functional sip device be able to interoperate with an RTCWEB-based device without a media gateway. That doesn't mean all sip devices. E.g. support of DTLS/SRTP will be required. But a device that wants to make this possible should be able to. This could be important for media-intensive applications. Also, the limitations that RTCWEB has discovered, that lead to these proposals, are also limitations for classes of non-RTCWEB devices and applications. It would be unpleasant and unfortunate to make one set of extensions for RTCWEB, and then have to do a different set for other applications. > I’ve seen some drafts claiming that Bundle would be harmful in for > instance cellular networks for QoS differentiation. Is that the > motivation where the non-Bundled RTCWeb use comes from, or are there > some other good reasons? > > For SIP the legacy considerations are of course much more clear. But are > the SIP vendors interested in Bundle? Presumably the IMS SIP vendors at > least not, if it complicates their QoS setup. This mostly applies to new applications. There is definitely a large overlap of needs between RTCWEB and CLUE. Thanks, Paul > Markus > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *ext Christer Holmberg > *Sent:* 13 March, 2013 22:12 > *To:* Hutton, Andrew; mmusic_ietf.org > *Subject:* Re: [MMUSIC] Bundle, TURN and Legacy Interop > > Hi, > > Nothing prevents you from only sending host candidates in the first > offer, of you want to do. > > Regards, > > Christer > > > > Sent from */Windows/* using *TouchDown*(www.nitrodesk.com > ) > > > -----Original Message----- > *From:* Hutton, Andrew [andrew.hutton@siemens-enterprise.com] > *To:* mmusic@ietf.org [mmusic@ietf.org] > *Subject:* [MMUSIC] Bundle, TURN and Legacy Interop > > Hi, > > It seems that one of the motivations of the current bundle-03 proposal > is that the first offer is compatible with a legacy device and that a > second offer is required for bundle (See > http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf). > > One issue that I see is that if TURN is being used there could be a > significant overhead in creating the first offer is multiple TURN > allocations are needed for each m-line which will all then have to be > released if bundle is used. > > I am not sure if there is a way to avoid this other but the draft should > I think mention this issue. > > Regards > Andy > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From Simo.Veikkolainen@nokia.com Thu Mar 14 01:53:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082F721F8E74 for ; Thu, 14 Mar 2013 01:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmjiHCjUrpfZ for ; Thu, 14 Mar 2013 01:53:19 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2601A21F8D65 for ; Thu, 14 Mar 2013 01:53:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2E8qxka014997; Thu, 14 Mar 2013 10:53:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 10:53:07 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 08:53:06 +0000 From: To: , , , , Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBnO+4bHDy/obkCLXK+GBDfayZij86oAgAAHBACAAAQ5gIAA4G3Q Date: Thu, 14 Mar 2013 08:53:06 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IppgasbRSU9AfKi4A4Z0En1EmaaJqiqN+M3fbtNlK/r5xEKsAQFa39xZroGJK1IXEB0SCh3ILQcPQZ+fUamiXvgDTiGKJKbD9buSoGnzvMMK6Dq4m5tDzgO6velQV6tPxowt0R52eaxh7cLC3S5yrmrU8Bo3a95vsNX7XU2jw71lHnmwuVWXgsqbH7Zfb3QtIxIG/0dl2zQeWssdpe3JLEF7Q453Ie+fJg4JnviNwD06Z+Sx2JHIs8I0jBLZUYjW78g3mjTF8X3M5jCFPYJTAs9IMedz2oHsOLNURDCr2F3P x-originating-ip: [62.78.254.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2013 08:53:07.0600 (UTC) FILETIME=[59026900:01CE2091] X-Nokia-AV: Clean Subject: Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 08:53:21 -0000 There is no change in the consensus, which is that ICE is used to negotiati= ng alternative IP addresses. I'm also fine with Thomas's proposed text, but just to highlight that ICE i= s used for IP addresses I would modify a bit: --- If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent IP addresses (e.g. "IP4" and "IP6" or different IP addresses within th= e same IP address family).=20 --- Regards, Simo -----Original Message----- From: ext mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ]=20 Sent: 13. maaliskuuta 2013 21:19 To: Andrew Allen; thomas.stach@siemens-enterprise.com; Veikkolainen Simo (N= okia-CTO/Espoo); mmusic@ietf.org; jonathan@vidyo.com Subject: RE : RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscella= neous-caps-04.txt Re-, The point is that if the attribute is extended to be able to convey an IPv4= and an alternate IPv6@, then your statement " and is not intended for IPv= 4 vs IPv6 for which ICE is the IETF defined mechanism." is not valid anymo= re...If that consensus changed then I'm puzzled why that argument was raise= d against altc and not ccap?!! OTOH, if the attribute is extended to cover IPv4/IPv6 then it should be cl= early specified. The current text does not say much for that case.=20 Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2= 013 20:03 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise= .com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org; jonathan@vidyo.com Obje= t : Re: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-= caps-04.txt The text in the draft was worked out with Jonathan Lennox who raised the in= itial concen about conflict with ICE. If Jonathan is ok with the revised pr= oposal from Thomas then I am OK with it. Andrew ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com = ; mmusic@ietf.org Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous= -caps-04.txt Hi Andrew, This was also my understanding but it seems the current text opens the door= to signal an IPv4 and IPv6 address. If it is not allowed, then the text should be clear. Cheers, Med ________________________________________ De : Andrew Allen [aallen@blackberry.com] Date d'envoi : mercredi 13 mars 2= 013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise= .com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: [MMUSIC] RE = : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt The main use of the CCAP parameter is to indicate the capability to use CS = SDP and E.164 numbers as a connection address and is not intended for IPv4 = vs IPv6 for which ICE is the IETF defined mechanism. ----- Original Message ----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time To: Stach, Thomas ; Simo.Veikkolainen@= nokia.com ; mmusic@ietf.org Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps= -04.txt Re-, The wording you propose is better as it explicits this behavior is about IC= E and not something else. So, I'm fine with that wording if this is the int= ent of the authors. BTW, the altc draft already mentions that if altc and c= cap are both supported, then both are offered. In fact, I stopped to track this draft since the Anaheim meeting when it se= ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I= Pv6 address. The misc draft should specify ccap when distinct nettypes are = in use. It seems that consensus is not anymore valid. The current text of ccap is under-specified if it is to be used to convey a= n IPv4 and IPv6 address. Cheers, Med ________________________________________ De : Stach, Thomas [thomas.stach@siemens-enterprise.com] Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed OLNC/OLN= ; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: [MMUSIC] I-D Act= ion: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Mohammed, I think it is not acceptable to mention altc in the example. If I recollect correctly, the intention of the text is to specify that ICE = MUST be preferred over 'ccap' for IPv4/v6 address negotiation. If we add 'altc' as another example it basically means that the proprietary= 'altc' is preferred over 'ccap'. I don't think that a standards track RFC should give the message that propr= ietary is preferred. Based on this issue I think the current text in the draft does not work. I would explicitly mention the relation of ICE and 'ccap'. The relation to other mechanism such as 'altc' needs to be treated in hte s= pecification of that mechanism. Thus I propose to rephrase to: If an offerer has implemented Interactive Connectivity Establishment (ICE) = [RFC5245] and the 'ccap' attribute it MUST use ICE to select between differ= ent connection addresses (e.g. "IP4" and "IP6" or different IP addresses w= ithin the same IP address family). Regards Thomas > -----Urspr=FCngliche Nachricht----- > Von: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 > An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Betreff: RE : [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Dear Thomas, > > I'm not proposing to change the existing behavior; I'm just asking=20 > whether it is acceptable to add an additional example to the one=20 > already cited in the text. > Wouldn't that be acceptable? > > You can propose to add another example if you have any in mind. > > Cheers, > Med > > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed=20 > OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW:=20 > [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Mohammed, > > I think you have draft-boucadair-mmusic-altc in mind. > This is an individual submission intended to document some=20 > proporietary mechanism. > I don't think we should make restrictions in a standards track=20 > document in support of proprietary mechanisms. > Otherwise I could also think of additional proprietary stuff that=20 > could be mentioned as well. > > > Regards > Thomas > > > -----Urspr=FCngliche Nachricht----- > > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im=20 > > Auftrag von mohamed.boucadair@orange.com > > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 > > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > > Betreff: Re: [MMUSIC] I-D Action: > > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > Hi Simo, > > > > The document says: > > > > The 'ccap' attribute MUST NOT be used in > > situations where an existing mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245]) can be used to select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > Would it be possible to change it to the following: > > > > NEW: > > > > The 'ccap' attribute MUST NOT be used in > > situations where a mechanism (such as Interactive > > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is used to=20 > > select > > between different connection addresses (e.g. "IP4" and "IP6" or > > different IP addresses within the same IP address family). > > > > > > Thanks. > > Cheers, > > Med > > > > > > >-----Message d'origine----- > > >De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la=20 > > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 mars 2013=20 > > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > >Hello, > > > > > >We just submitted a new version of the miscellaneous-caps draft,=20 > > >with text that states that if the connection data capability=20 > > >attribute (a=3Dccap) is used the port number in the resulting SDP=20 > > >MUST be the same as in the original "m=3D" line, except for PSTN type= =20 > > >bearers (when the port number used is 9). > > > > > >Regards, > > >Simo > > > > > >-----Original Message----- > > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > >Behalf Of ext internet-drafts@ietf.org > > >Sent: 13. maaliskuuta 2013 15:39 > > >To: i-d-announce@ietf.org > > >Cc: mmusic@ietf.org > > >Subject: [MMUSIC] I-D Action: > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > > >directories. > > > This draft is a work item of the Multiparty Multimedia Session=20 > > >Control Working Group of the IETF. > > > > > > Title : Miscellaneous Capabilities > > >Negotiation in the Session Description Protocol (SDP) > > > Author(s) : Miguel A. Garcia-Martin > > > Simo Veikkolainen > > > Robert R. Gilman > > > Filename : > > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > Pages : 21 > > > Date : 2013-03-13 > > > > > >Abstract: > > > SDP has been extended with a capability negotiation mechanism > > > framework that allows the endpoints to negotiate > > transport protocols > > > and attributes. This framework has been extended with a media > > > capabilities negotiation mechanism that allows endpoints to=20 > > >negotiate > > > additional media-related capabilities. This negotiation > > is embedded > > > into the widely-used SDP offer/answer procedures. > > > > > > This memo extends the SDP capability negotiation > > framework to allow > > > endpoints to negotiate three additional SDP capabilities. In > > > particular, this memo provides a mechanism to negotiate > bandwidth > > > ('b=3D' line), connection data ('c=3D' line), and titles > > ('i=3D' line for > > > each session or media). > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella > > >neous-caps > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > >-04 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella > > >neous-caps-04 > > > > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From mohamed.boucadair@orange.com Thu Mar 14 02:05:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5121F8E71 for ; Thu, 14 Mar 2013 02:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 PeZJCHTcnKeA for ; Thu, 14 Mar 2013 02:05:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7833921F8CB9 for ; Thu, 14 Mar 2013 02:05:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3A03222CDE8; Thu, 14 Mar 2013 10:05:04 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id EF63C35C065; Thu, 14 Mar 2013 10:05:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 14 Mar 2013 10:05:03 +0100 From: To: "Simo.Veikkolainen@nokia.com" , "aallen@blackberry.com" , "thomas.stach@siemens-enterprise.com" , "mmusic@ietf.org" , "jonathan@vidyo.com" Date: Thu, 14 Mar 2013 10:05:02 +0100 Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBnO+4bHDy/obkCLXK+GBDfayZij86oAgAAHBACAAAQ5gIAA4G3QgAADdsA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EB7356635@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.14.83315 Subject: Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 09:05:07 -0000 Hi Simo, The proposed change is not sufficient. If you want ccap to be used to sign= al an IPv4 address and an IPv6 alternate one, the current text is underspec= ified (e.g, it does not specify how to signal an alternate port for a disti= nct AF, how to detect a ccap-unaware midllebox, whether multiple sessions a= re established or only one is allowed, how many ccap lines are allowed, whe= ther ccap line can be present in both O/A, etc.). But as I understood there is no consensus change then the text should be ex= plicit and say ccap MUST NOT be used to signal an IPv4 address and an IPv6 = alternate one. Cheers, Med >-----Message d'origine----- >De : Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] >Envoy=E9 : jeudi 14 mars 2013 09:53 >=C0 : BOUCADAIR Mohamed OLNC/OLN; aallen@blackberry.com; >thomas.stach@siemens-enterprise.com; mmusic@ietf.org; >jonathan@vidyo.com >Objet : RE: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >There is no change in the consensus, which is that ICE is used >to negotiating alternative IP addresses. > >I'm also fine with Thomas's proposed text, but just to >highlight that ICE is used for IP addresses I would modify a bit: > >--- >If an offerer has implemented Interactive Connectivity >Establishment (ICE) [RFC5245] and the 'ccap' attribute it MUST >use ICE to select between different IP addresses (e.g. "IP4" >and "IP6" or different IP addresses within the same IP address >family). >--- > >Regards, >Simo > >-----Original Message----- >From: ext mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: 13. maaliskuuta 2013 21:19 >To: Andrew Allen; thomas.stach@siemens-enterprise.com; >Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org; >jonathan@vidyo.com >Subject: RE : RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The point is that if the attribute is extended to be able to >convey an IPv4 and an alternate IPv6@, then your statement " >and is not intended for IPv4 vs IPv6 for which ICE is the IETF >defined mechanism." is not valid anymore...If that consensus >changed then I'm puzzled why that argument was raised against >altc and not ccap?!! > >OTOH, if the attribute is extended to cover IPv4/IPv6 then it >should be clearly specified. The current text does not say >much for that case. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 20:03 =C0 : BOUCADAIR Mohamed OLNC/OLN; >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org; >jonathan@vidyo.com Objet : Re: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The text in the draft was worked out with Jonathan Lennox who >raised the initial concen about conflict with ICE. If Jonathan >is ok with the revised proposal from Thomas then I am OK with it. > >Andrew > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >To: Andrew Allen; thomas.stach@siemens-enterprise.com >; >Simo.Veikkolainen@nokia.com ; >mmusic@ietf.org >Subject: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Hi Andrew, > >This was also my understanding but it seems the current text >opens the door to signal an IPv4 and IPv6 address. > >If it is not allowed, then the text should be clear. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: >[MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The main use of the CCAP parameter is to indicate the >capability to use CS SDP and E.164 numbers as a connection >address and is not intended for IPv4 vs IPv6 for which ICE is >the IETF defined mechanism. > > > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >To: Stach, Thomas ; >Simo.Veikkolainen@nokia.com ; >mmusic@ietf.org >Subject: [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The wording you propose is better as it explicits this >behavior is about ICE and not something else. So, I'm fine >with that wording if this is the intent of the authors. BTW, >the altc draft already mentions that if altc and ccap are both >supported, then both are offered. > >In fact, I stopped to track this draft since the Anaheim >meeting when it seems the consensus of the wg was: ICE is to >solution to signal an IPv4 and IPv6 address. The misc draft >should specify ccap when distinct nettypes are in use. It >seems that consensus is not anymore valid. > >The current text of ccap is under-specified if it is to be >used to convey an IPv4 and IPv6 address. > >Cheers, >Med > >________________________________________ >De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR >Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >Objet : AW: [MMUSIC] I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Mohammed, > >I think it is not acceptable to mention altc in the example. >If I recollect correctly, the intention of the text is to >specify that ICE MUST be preferred over 'ccap' for IPv4/v6 >address negotiation. > >If we add 'altc' as another example it basically means that >the proprietary 'altc' is preferred over 'ccap'. >I don't think that a standards track RFC should give the >message that proprietary is preferred. >Based on this issue I think the current text in the draft does >not work. >I would explicitly mention the relation of ICE and 'ccap'. >The relation to other mechanism such as 'altc' needs to be >treated in hte specification of that mechanism. > >Thus I propose to rephrase to: > >If an offerer has implemented Interactive Connectivity >Establishment (ICE) [RFC5245] and the 'ccap' attribute it MUST >use ICE to select between different connection addresses (e.g. > "IP4" and "IP6" or different IP addresses within the same IP >address family). > > >Regards >Thomas > >> -----Urspr=FCngliche Nachricht----- >> Von: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 >> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Betreff: RE : [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Dear Thomas, >> >> I'm not proposing to change the existing behavior; I'm just asking >> whether it is acceptable to add an additional example to the one >> already cited in the text. >> Wouldn't that be acceptable? >> >> You can propose to add another example if you have any in mind. >> >> Cheers, >> Med >> >> ________________________________________ >> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >> Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed >> OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: >> [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Mohammed, >> >> I think you have draft-boucadair-mmusic-altc in mind. >> This is an individual submission intended to document some >> proporietary mechanism. >> I don't think we should make restrictions in a standards track >> document in support of proprietary mechanisms. >> Otherwise I could also think of additional proprietary stuff that >> could be mentioned as well. >> >> >> Regards >> Thomas >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im >> > Auftrag von mohamed.boucadair@orange.com >> > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 >> > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> > Betreff: Re: [MMUSIC] I-D Action: >> > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > >> > Hi Simo, >> > >> > The document says: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where an existing mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245]) can be used >to select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > Would it be possible to change it to the following: >> > >> > NEW: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where a mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) >is used to >> > select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > >> > Thanks. >> > Cheers, >> > Med >> > >> > >> > >-----Message d'origine----- >> > >De : mmusic-bounces@ietf.org >[mailto:mmusic-bounces@ietf.org] De la >> > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 >mars 2013 >> > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > >Hello, >> > > >> > >We just submitted a new version of the miscellaneous-caps draft, >> > >with text that states that if the connection data capability >> > >attribute (a=3Dccap) is used the port number in the resulting SDP >> > >MUST be the same as in the original "m=3D" line, except for >PSTN type >> > >bearers (when the port number used is 9). >> > > >> > >Regards, >> > >Simo >> > > >> > >-----Original Message----- >> > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> > >Behalf Of ext internet-drafts@ietf.org >> > >Sent: 13. maaliskuuta 2013 15:39 >> > >To: i-d-announce@ietf.org >> > >Cc: mmusic@ietf.org >> > >Subject: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > > >> > >A New Internet-Draft is available from the on-line >Internet-Drafts >> > >directories. >> > > This draft is a work item of the Multiparty Multimedia Session >> > >Control Working Group of the IETF. >> > > >> > > Title : Miscellaneous Capabilities >> > >Negotiation in the Session Description Protocol (SDP) >> > > Author(s) : Miguel A. Garcia-Martin >> > > Simo Veikkolainen >> > > Robert R. Gilman >> > > Filename : >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > Pages : 21 >> > > Date : 2013-03-13 >> > > >> > >Abstract: >> > > SDP has been extended with a capability negotiation mechanism >> > > framework that allows the endpoints to negotiate >> > transport protocols >> > > and attributes. This framework has been extended with a media >> > > capabilities negotiation mechanism that allows endpoints to >> > >negotiate >> > > additional media-related capabilities. This negotiation >> > is embedded >> > > into the widely-used SDP offer/answer procedures. >> > > >> > > This memo extends the SDP capability negotiation >> > framework to allow >> > > endpoints to negotiate three additional SDP capabilities. In >> > > particular, this memo provides a mechanism to negotiate >> bandwidth >> > > ('b=3D' line), connection data ('c=3D' line), and titles >> > ('i=3D' line for >> > > each session or media). >> > > >> > > >> > >The IETF datatracker status page for this draft is: >> > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >> > >neous-caps >> > > >> > >There's also a htmlized version available at: >> > >>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps >> > >-04 >> > > >> > >A diff from the previous version is available at: >> > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella >> > >neous-caps-04 >> > > >> > > >> > >Internet-Drafts are also available by anonymous FTP at: >> > >ftp://ftp.ietf.org/internet-drafts/ >> > > >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain >confidential information, privileged material (including >material protected by the solicitor-client or other applicable >privileges), or constitute non-public information. Any use of >this information by anyone other than the intended recipient >is prohibited. If you have received this transmission in >error, please immediately reply to the sender and delete this >information from your system. Use, dissemination, >distribution, or reproduction of this transmission by >unintended recipients is not authorized and may be unlawful. > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain >confidential information, privileged material (including >material protected by the solicitor-client or other applicable >privileges), or constitute non-public information. Any use of >this information by anyone other than the intended recipient >is prohibited. If you have received this transmission in >error, please immediately reply to the sender and delete this >information from your system. Use, dissemination, >distribution, or reproduction of this transmission by >unintended recipients is not authorized and may be unlawful. > From ted.ietf@gmail.com Thu Mar 14 05:22:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC921F8FCB for ; Thu, 14 Mar 2013 05:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 CHmZF1Hs++e8 for ; Thu, 14 Mar 2013 05:22:08 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB58621F8FC5 for ; Thu, 14 Mar 2013 05:22:03 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 13so2898016iea.14 for ; Thu, 14 Mar 2013 05:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=720DXUAWNmx7hbIbhIVDj2Bde1RU31L5YEuzs7YmvBQ=; b=vWTJ4+Ag9FWutmGNrSGz7L4PmXxkCqewY9nlIHExguTgvj4Nrxd2+GcmX4KZnsq3oN /PluJ/rSqiGs0lq4ogRsacH9ScPQamzhRyiPcsJSd8PvLq+U0GBxzpPRC4ayK8FUDdF1 fEO0kVlzCF9WnZjwOpynkcpxtZsuJUuBzjAbF1m2xMxWootTLCzP9IURaWy5PUd/vb/y 6zkUCrH/uo7H8Y2p0rR9XcXkzbYBfB7GJvwJgkpFiu3ArPP5yDHFcculFcGTQ2L2xbnd XzltvLSFDZh0v0h0SXFkL7V5g9g7AR3tR7ss0MuA6qBSF0FWStU9JbcfYrgUmrapGfjd XG6A== MIME-Version: 1.0 X-Received: by 10.50.87.196 with SMTP id ba4mr2123759igb.20.1363263723066; Thu, 14 Mar 2013 05:22:03 -0700 (PDT) Received: by 10.43.135.202 with HTTP; Thu, 14 Mar 2013 05:22:02 -0700 (PDT) In-Reply-To: <51414A88.6040108@alum.mit.edu> References: <51414A88.6040108@alum.mit.edu> Date: Thu, 14 Mar 2013 08:22:02 -0400 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:22:13 -0000 On Wed, Mar 13, 2013 at 11:56 PM, Paul Kyzivat wrote:>> As far as I understand it, RTCWeb to Legacy interop can be accommodated >> by a gateway that on one side supports all the bells and whistles of >> RTCWeb such as Bundle and trickle-ICE, and to the other side uses >> existing offer/answer procedures without ICE or Bundle. Right? Or is >> there a particular reason why a WebRTC implementation should assume the >> other end (from its perspective) won=92t do Bundle? > > > IMO there is an (at least implicit) goal that a sufficiently functional s= ip > device be able to interoperate with an RTCWEB-based device without a medi= a > gateway. > *If* the javascript application downloaded into the browser was written to use SIP as its signalling protocol and if the web server had a method of rendezvous with the SIP endpoints proxy, this might be possible. But there is no requirement that the applications make this choice; the system is design so that this is a supported option, not a requirement. regards, Ted > That doesn't mean all sip devices. E.g. support of DTLS/SRTP will be > required. But a device that wants to make this possible should be able to= . > This could be important for media-intensive applications. > > Also, the limitations that RTCWEB has discovered, that lead to these > proposals, are also limitations for classes of non-RTCWEB devices and > applications. It would be unpleasant and unfortunate to make one set of > extensions for RTCWEB, and then have to do a different set for other > applications. > > >> I=92ve seen some drafts claiming that Bundle would be harmful in for >> instance cellular networks for QoS differentiation. Is that the >> motivation where the non-Bundled RTCWeb use comes from, or are there >> some other good reasons? >> >> For SIP the legacy considerations are of course much more clear. But are >> the SIP vendors interested in Bundle? Presumably the IMS SIP vendors at >> least not, if it complicates their QoS setup. > > > This mostly applies to new applications. There is definitely a large over= lap > of needs between RTCWEB and CLUE. > > Thanks, > Paul > >> Markus >> >> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On >> Behalf Of *ext Christer Holmberg >> *Sent:* 13 March, 2013 22:12 >> *To:* Hutton, Andrew; mmusic_ietf.org >> *Subject:* Re: [MMUSIC] Bundle, TURN and Legacy Interop >> >> >> Hi, >> >> Nothing prevents you from only sending host candidates in the first >> offer, of you want to do. >> >> Regards, >> >> Christer >> >> >> >> Sent from */Windows/* using *TouchDown*(www.nitrodesk.com >> ) >> >> >> -----Original Message----- >> *From:* Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >> *To:* mmusic@ietf.org [mmusic@ietf.org] >> *Subject:* [MMUSIC] Bundle, TURN and Legacy Interop >> >> >> Hi, >> >> It seems that one of the motivations of the current bundle-03 proposal >> is that the first offer is compatible with a legacy device and that a >> second offer is required for bundle (See >> http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf). >> >> One issue that I see is that if TURN is being used there could be a >> significant overhead in creating the first offer is multiple TURN >> allocations are needed for each m-line which will all then have to be >> released if bundle is used. >> >> I am not sure if there is a way to avoid this other but the draft should >> I think mention this issue. >> >> Regards >> Andy >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Mar 14 05:46:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34F811E8100 for ; Thu, 14 Mar 2013 05:46:19 -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 DlEdSoCDu52x for ; Thu, 14 Mar 2013 05:46:15 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3337611E80FA for ; Thu, 14 Mar 2013 05:46:15 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta13.emeryville.ca.mail.comcast.net with comcast id BQFx1l0021bwxycADQmEB3; Thu, 14 Mar 2013 12:46:14 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:7149:4d93:3520:8f76]) by omta18.emeryville.ca.mail.comcast.net with comcast id BQmD1l00R4ckypT8eQmEBo; Thu, 14 Mar 2013 12:46:14 +0000 Message-ID: <5141C695.9030107@alum.mit.edu> Date: Thu, 14 Mar 2013 20:46:13 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ted Hardie References: <51414A88.6040108@alum.mit.edu> In-Reply-To: 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=1363265174; bh=mhVYXKpr6JstB24yjn/vfos8M2Q68bcvJB//W/KtsFM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nUrv5mG4klqXwDGR/UbY0QaWpunKFDao1XC6YbmHn1/VRiFLMnHnsApek6DgtP8k0 Ye5awJ9G05TiUMG3Ly0ALBl5g5cKPGZeru63KAAU2j1nYkgZ0un+ZroILwI5tsYWIo Kig470fUiHi7rBzDNEDKOz6WYpuKaqOJnGmXndHcGniQ9N/6oSRK1m1SR8VMH4AIN8 6tkxshlQNBwWQTNc66yCsKyDvea5nDTwGPuCzMj9NLJdOZWuYXK6pCezUYO5fddqsq vDwKAUM7+k0mhTIYelyTXBKcy0uW5sZjkVdzGnK3rd5JRON6PKpS13O3fRM/xiQFH4 6LgU5y8AcAB6Q== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:46:20 -0000 On 3/14/13 8:22 PM, Ted Hardie wrote: > On Wed, Mar 13, 2013 at 11:56 PM, Paul Kyzivat > wrote:>> As far as I understand it, RTCWeb to Legacy interop can be > accommodated >>> by a gateway that on one side supports all the bells and whistles of >>> RTCWeb such as Bundle and trickle-ICE, and to the other side uses >>> existing offer/answer procedures without ICE or Bundle. Right? Or is >>> there a particular reason why a WebRTC implementation should assume the >>> other end (from its perspective) won’t do Bundle? >> >> >> IMO there is an (at least implicit) goal that a sufficiently functional sip >> device be able to interoperate with an RTCWEB-based device without a media >> gateway. >> > > *If* the javascript application downloaded into the browser was > written to use SIP as its signalling protocol and if the web server > had a method of rendezvous with the SIP endpoints proxy, this might be > possible. But there is no requirement that the applications make this > choice; the system is design so that this is a supported option, not a > requirement. Yes, I agree. But it must be possible. In particular, I don't want to get into a situation where RTP multiplexing in RTCWEB is incompatible with RTP multiplexing in CLUE, requiring a media gateway, or the foregoing of multiplexing, to resolve. Thanks, Paul > regards, > > Ted > >> That doesn't mean all sip devices. E.g. support of DTLS/SRTP will be >> required. But a device that wants to make this possible should be able to. >> This could be important for media-intensive applications. >> >> Also, the limitations that RTCWEB has discovered, that lead to these >> proposals, are also limitations for classes of non-RTCWEB devices and >> applications. It would be unpleasant and unfortunate to make one set of >> extensions for RTCWEB, and then have to do a different set for other >> applications. >> >> >>> I’ve seen some drafts claiming that Bundle would be harmful in for >>> instance cellular networks for QoS differentiation. Is that the >>> motivation where the non-Bundled RTCWeb use comes from, or are there >>> some other good reasons? >>> >>> For SIP the legacy considerations are of course much more clear. But are >>> the SIP vendors interested in Bundle? Presumably the IMS SIP vendors at >>> least not, if it complicates their QoS setup. >> >> >> This mostly applies to new applications. There is definitely a large overlap >> of needs between RTCWEB and CLUE. >> >> Thanks, >> Paul >> >>> Markus >>> >>> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On >>> Behalf Of *ext Christer Holmberg >>> *Sent:* 13 March, 2013 22:12 >>> *To:* Hutton, Andrew; mmusic_ietf.org >>> *Subject:* Re: [MMUSIC] Bundle, TURN and Legacy Interop >>> >>> >>> Hi, >>> >>> Nothing prevents you from only sending host candidates in the first >>> offer, of you want to do. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> Sent from */Windows/* using *TouchDown*(www.nitrodesk.com >>> ) >>> >>> >>> -----Original Message----- >>> *From:* Hutton, Andrew [andrew.hutton@siemens-enterprise.com] >>> *To:* mmusic@ietf.org [mmusic@ietf.org] >>> *Subject:* [MMUSIC] Bundle, TURN and Legacy Interop >>> >>> >>> Hi, >>> >>> It seems that one of the motivations of the current bundle-03 proposal >>> is that the first offer is compatible with a legacy device and that a >>> second offer is required for bundle (See >>> http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf). >>> >>> One issue that I see is that if TURN is being used there could be a >>> significant overhead in creating the first offer is multiple TURN >>> allocations are needed for each m-line which will all then have to be >>> released if bundle is used. >>> >>> I am not sure if there is a way to avoid this other but the draft should >>> I think mention this issue. >>> >>> Regards >>> Andy >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From Simo.Veikkolainen@nokia.com Thu Mar 14 05:57:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72621F905C for ; Thu, 14 Mar 2013 05:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 gP-toz+O5LVe for ; Thu, 14 Mar 2013 05:57:28 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6056521F905A for ; Thu, 14 Mar 2013 05:57:26 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2ECv3u5012738; Thu, 14 Mar 2013 14:57:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 14:57:03 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 12:57:02 +0000 From: To: , , , , Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBnO+4bHDy/obkCLXK+GBDfayZij86oAgAAHBACAAAQ5gIAA4G3QgAADdsCAAEOSsA== Date: Thu, 14 Mar 2013 12:57:00 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EB7356635@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB7356635@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IppgasbRSU9AfKi4A4Z0En1EmaaJqiqN+M3fbtNlK/r5xEKsAQFa39xZroGJK1IXEB0SCh3ILQcPQZ+fUamiXvgDTiGKJKbD9buSoGnzvMMK6Dq4m5tDzgO6velQV6tPxowt0R52eaxh7cLC3S5yrmrU8Bo3a95vsNX7XU2jw71lHnmwuVWXgsqbH7Zfb3QtIxIG/0dl2zQeWssdpe3JLEF7Q453Ie+fJg4JnviNwD06Z+Sx2JHIs8I0jBLZUYjW78g3mjTF8X3M5jCFPYJTAs9IMedz2oHsOLNURDCr2F3P x-originating-ip: [62.78.254.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2013 12:57:03.0132 (UTC) FILETIME=[6C775DC0:01CE20B3] X-Nokia-AV: Clean Subject: Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:57:29 -0000 See below [SV] -----Original Message----- From: ext mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ]=20 Sent: 14. maaliskuuta 2013 11:05 To: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com; thomas.stac= h@siemens-enterprise.com; mmusic@ietf.org; jonathan@vidyo.com Subject: RE: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellan= eous-caps-04.txt Hi Simo, The proposed change is not sufficient. If you want ccap to be used to sign= al an IPv4 address and an IPv6 alternate one, [SV] That's not what I want. the current text is underspecified (e.g, it does not specify how to signal= an alternate port for a distinct AF, how to detect a ccap-unaware midllebo= x, whether multiple sessions are established or only one is allowed, how ma= ny ccap lines are allowed, whether ccap line can be present in both O/A, et= c.). But as I understood there is no consensus change then the text should be ex= plicit and say ccap MUST NOT be used to signal an IPv4 address and an IPv6 = alternate one. [SV] The same effect can be achieved by saying that ICE MUST be used, right= ? Simo Cheers, Med >-----Message d'origine----- >De : Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] >Envoy=E9 : jeudi 14 mars 2013 09:53 >=C0 : BOUCADAIR Mohamed OLNC/OLN; aallen@blackberry.com;=20 >thomas.stach@siemens-enterprise.com; mmusic@ietf.org;=20 >jonathan@vidyo.com Objet : RE: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >There is no change in the consensus, which is that ICE is used to=20 >negotiating alternative IP addresses. > >I'm also fine with Thomas's proposed text, but just to highlight that=20 >ICE is used for IP addresses I would modify a bit: > >--- >If an offerer has implemented Interactive Connectivity Establishment=20 >(ICE) [RFC5245] and the 'ccap' attribute it MUST use ICE to select=20 >between different IP addresses (e.g. "IP4" >and "IP6" or different IP addresses within the same IP address family). >--- > >Regards, >Simo > >-----Original Message----- >From: ext mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: 13. maaliskuuta 2013 21:19 >To: Andrew Allen; thomas.stach@siemens-enterprise.com; >Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org;=20 >jonathan@vidyo.com >Subject: RE : RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The point is that if the attribute is extended to be able to convey an=20 >IPv4 and an alternate IPv6@, then your statement " >and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined =20 >mechanism." is not valid anymore...If that consensus changed then I'm=20 >puzzled why that argument was raised against altc and not ccap?!! > >OTOH, if the attribute is extended to cover IPv4/IPv6 then it should=20 >be clearly specified. The current text does not say much for that case. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 20:03 =C0 : BOUCADAIR Mohamed OLNC/OLN;=20 >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org; jonathan@vidyo.com Objet=20 >: Re: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The text in the draft was worked out with Jonathan Lennox who raised=20 >the initial concen about conflict with ICE. If Jonathan is ok with the=20 >revised proposal from Thomas then I am OK with it. > >Andrew > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >To: Andrew Allen; thomas.stach@siemens-enterprise.com >; >Simo.Veikkolainen@nokia.com ;=20 >mmusic@ietf.org >Subject: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Hi Andrew, > >This was also my understanding but it seems the current text opens the=20 >door to signal an IPv4 and IPv6 address. > >If it is not allowed, then the text should be clear. > >Cheers, >Med > >________________________________________ >De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN;=20 >thomas.stach@siemens-enterprise.com; >Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: >[MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >The main use of the CCAP parameter is to indicate the capability to use=20 >CS SDP and E.164 numbers as a connection address and is not intended=20 >for IPv4 vs IPv6 for which ICE is the IETF defined mechanism. > > > >----- Original Message ----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >To: Stach, Thomas ; >Simo.Veikkolainen@nokia.com ;=20 >mmusic@ietf.org >Subject: [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Re-, > >The wording you propose is better as it explicits this behavior is=20 >about ICE and not something else. So, I'm fine with that wording if=20 >this is the intent of the authors. BTW, the altc draft already mentions=20 >that if altc and ccap are both supported, then both are offered. > >In fact, I stopped to track this draft since the Anaheim meeting when=20 >it seems the consensus of the wg was: ICE is to solution to signal an=20 >IPv4 and IPv6 address. The misc draft should specify ccap when distinct=20 >nettypes are in use. It seems that consensus is not anymore valid. > >The current text of ccap is under-specified if it is to be used to=20 >convey an IPv4 and IPv6 address. > >Cheers, >Med > >________________________________________ >De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed=20 >OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW:=20 >[MMUSIC] I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Mohammed, > >I think it is not acceptable to mention altc in the example. >If I recollect correctly, the intention of the text is to specify that=20 >ICE MUST be preferred over 'ccap' for IPv4/v6 address negotiation. > >If we add 'altc' as another example it basically means that the=20 >proprietary 'altc' is preferred over 'ccap'. >I don't think that a standards track RFC should give the message that=20 >proprietary is preferred. >Based on this issue I think the current text in the draft does not=20 >work. >I would explicitly mention the relation of ICE and 'ccap'. >The relation to other mechanism such as 'altc' needs to be treated in=20 >hte specification of that mechanism. > >Thus I propose to rephrase to: > >If an offerer has implemented Interactive Connectivity Establishment=20 >(ICE) [RFC5245] and the 'ccap' attribute it MUST use ICE to select=20 >between different connection addresses (e.g. > "IP4" and "IP6" or different IP addresses within the same IP address=20 >family). > > >Regards >Thomas > >> -----Urspr=FCngliche Nachricht----- >> Von: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 >> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Betreff: RE : [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Dear Thomas, >> >> I'm not proposing to change the existing behavior; I'm just asking=20 >> whether it is acceptable to add an additional example to the one=20 >> already cited in the text. >> Wouldn't that be acceptable? >> >> You can propose to add another example if you have any in mind. >> >> Cheers, >> Med >> >> ________________________________________ >> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >> Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed=20 >> OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: >> [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Mohammed, >> >> I think you have draft-boucadair-mmusic-altc in mind. >> This is an individual submission intended to document some=20 >> proporietary mechanism. >> I don't think we should make restrictions in a standards track=20 >> document in support of proprietary mechanisms. >> Otherwise I could also think of additional proprietary stuff that=20 >> could be mentioned as well. >> >> >> Regards >> Thomas >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im=20 >> > Auftrag von mohamed.boucadair@orange.com >> > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 >> > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> > Betreff: Re: [MMUSIC] I-D Action: >> > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > >> > Hi Simo, >> > >> > The document says: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where an existing mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245]) can be used >to select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > Would it be possible to change it to the following: >> > >> > NEW: >> > >> > The 'ccap' attribute MUST NOT be used in >> > situations where a mechanism (such as Interactive >> > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) >is used to >> > select >> > between different connection addresses (e.g. "IP4" and "IP6" or >> > different IP addresses within the same IP address family). >> > >> > >> > Thanks. >> > Cheers, >> > Med >> > >> > >> > >-----Message d'origine----- >> > >De : mmusic-bounces@ietf.org >[mailto:mmusic-bounces@ietf.org] De la >> > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 >mars 2013 >> > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > >Hello, >> > > >> > >We just submitted a new version of the miscellaneous-caps draft,=20 >> > >with text that states that if the connection data capability=20 >> > >attribute (a=3Dccap) is used the port number in the resulting SDP=20 >> > >MUST be the same as in the original "m=3D" line, except for >PSTN type >> > >bearers (when the port number used is 9). >> > > >> > >Regards, >> > >Simo >> > > >> > >-----Original Message----- >> > >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >> > >Behalf Of ext internet-drafts@ietf.org >> > >Sent: 13. maaliskuuta 2013 15:39 >> > >To: i-d-announce@ietf.org >> > >Cc: mmusic@ietf.org >> > >Subject: [MMUSIC] I-D Action: >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > >> > > >> > >A New Internet-Draft is available from the on-line >Internet-Drafts >> > >directories. >> > > This draft is a work item of the Multiparty Multimedia Session=20 >> > >Control Working Group of the IETF. >> > > >> > > Title : Miscellaneous Capabilities >> > >Negotiation in the Session Description Protocol (SDP) >> > > Author(s) : Miguel A. Garcia-Martin >> > > Simo Veikkolainen >> > > Robert R. Gilman >> > > Filename : >> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> > > Pages : 21 >> > > Date : 2013-03-13 >> > > >> > >Abstract: >> > > SDP has been extended with a capability negotiation mechanism >> > > framework that allows the endpoints to negotiate >> > transport protocols >> > > and attributes. This framework has been extended with a media >> > > capabilities negotiation mechanism that allows endpoints to=20 >> > >negotiate >> > > additional media-related capabilities. This negotiation >> > is embedded >> > > into the widely-used SDP offer/answer procedures. >> > > >> > > This memo extends the SDP capability negotiation >> > framework to allow >> > > endpoints to negotiate three additional SDP capabilities. In >> > > particular, this memo provides a mechanism to negotiate >> bandwidth >> > > ('b=3D' line), connection data ('c=3D' line), and titles >> > ('i=3D' line for >> > > each session or media). >> > > >> > > >> > >The IETF datatracker status page for this draft is: >> > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >> > >neous-caps >> > > >> > >There's also a htmlized version available at: >> > >>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps >> > >-04 >> > > >> > >A diff from the previous version is available at: >> > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella >> > >neous-caps-04 >> > > >> > > >> > >Internet-Drafts are also available by anonymous FTP at: >> > >ftp://ftp.ietf.org/internet-drafts/ >> > > >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > >_______________________________________________ >> > >mmusic mailing list >> > >mmusic@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mmusic >> > > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain confidential=20 >information, privileged material (including material protected by the=20 >solicitor-client or other applicable privileges), or constitute=20 >non-public information. Any use of this information by anyone other=20 >than the intended recipient is prohibited. If you have received this=20 >transmission in error, please immediately reply to the sender and=20 >delete this information from your system. Use, dissemination,=20 >distribution, or reproduction of this transmission by unintended=20 >recipients is not authorized and may be unlawful. > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain confidential=20 >information, privileged material (including material protected by the=20 >solicitor-client or other applicable privileges), or constitute=20 >non-public information. Any use of this information by anyone other=20 >than the intended recipient is prohibited. If you have received this=20 >transmission in error, please immediately reply to the sender and=20 >delete this information from your system. Use, dissemination,=20 >distribution, or reproduction of this transmission by unintended=20 >recipients is not authorized and may be unlawful. > From jonathan@vidyo.com Thu Mar 14 06:04:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9093621F8E7D for ; Thu, 14 Mar 2013 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksx2x08sGXkZ for ; Thu, 14 Mar 2013 06:04:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 8E89921F8E94 for ; Thu, 14 Mar 2013 06:04:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EF6BE416B1B; Thu, 14 Mar 2013 03:10:30 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 513C441692E; Thu, 14 Mar 2013 03:10:03 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Thu, 14 Mar 2013 09:03:50 -0400 From: Jonathan Lennox To: Andrew Allen Date: Thu, 14 Mar 2013 09:04:01 -0400 Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: Ac4gtGUZreizkUq8TTyKgyH0VXBgOA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:04:33 -0000 I suggest being more concrete about ccap's restrictions, that it can't be u= sed to negotiate alternative IP addresses. We can then discuss only ICE, w= ithout precluding altc for the proprietary systems which want to use it. Thus, I suggest something like this (wordsmithing requested): The 'ccap' attribute MUST NOT be used to offer multiple addresses with the = "IN" (i.e., multiple Internet protocol addresses) in the same med= ia stream. Interactive Connectivity Establishment (ICE) [RFC5245] can be u= sed to allow a choice among multiple Internet addresses. The use of ICE wi= th capability negotiation is described in section 3.7 of [RFC5939]. This text might also be useful (though it definitely needs editorial improv= ement): In principle, the attributes associated with ICE ought to be included only = in configurations where each media stream has a connection address which ma= tches one of the ICE candidates (i.e, for currently-defined candidate types= , a configuration whose connection address has the "IN"); otherwi= se, under the rules of ICE, an ICE mismatch will result. However, this ICE= mismatch will in fact induce the desired behavior, causing the answerer to= abort ICE processing and use the connection address; so this ICE mismatch = is harmless, other than the inclusion of an "ice-mismatch" attribute in the= SDP answer. On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote: >=20 > The text in the draft was worked out with Jonathan Lennox who raised the = initial concen about conflict with ICE. If Jonathan is ok with the revised = proposal from Thomas then I am OK with it. >=20 > Andrew >=20 > ----- Original Message ----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time > To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org > Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneo= us-caps-04.txt >=20 > Hi Andrew, >=20 > This was also my understanding but it seems the current text opens the do= or to signal an IPv4 and IPv6 address. >=20 > If it is not allowed, then the text should be clear. >=20 > Cheers, > Med >=20 > ________________________________________ > De : Andrew Allen [aallen@blackberry.com] > Date d'envoi : mercredi 13 mars 2013 19:37 > =C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Si= mo.Veikkolainen@nokia.com; mmusic@ietf.org > Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous= -caps-04.txt >=20 > The main use of the CCAP parameter is to indicate the capability to use C= S SDP and E.164 numbers as a connection address and is not intended for IPv= 4 vs IPv6 for which ICE is the IETF defined mechanism. >=20 >=20 >=20 > ----- Original Message ----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time > To: Stach, Thomas ; Simo.Veikkolaine= n@nokia.com ; mmusic@ietf.org > Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-ca= ps-04.txt >=20 > Re-, >=20 > The wording you propose is better as it explicits this behavior is about = ICE and not something else. So, I'm fine with that wording if this is the i= ntent of the authors. BTW, the altc draft already mentions that if altc and= ccap are both supported, then both are offered. >=20 > In fact, I stopped to track this draft since the Anaheim meeting when it = seems the consensus of the wg was: ICE is to solution to signal an IPv4 and= IPv6 address. The misc draft should specify ccap when distinct nettypes ar= e in use. It seems that consensus is not anymore valid. >=20 > The current text of ccap is under-specified if it is to be used to convey= an IPv4 and IPv6 address. >=20 > Cheers, > Med >=20 > ________________________________________ > De : Stach, Thomas [thomas.stach@siemens-enterprise.com] > Date d'envoi : mercredi 13 mars 2013 19:17 > =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@iet= f.org > Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps= -04.txt >=20 > Mohammed, >=20 > I think it is not acceptable to mention altc in the example. > If I recollect correctly, the intention of the text is to specify that IC= E MUST be > preferred over 'ccap' for IPv4/v6 address negotiation. >=20 > If we add 'altc' as another example it basically means that the proprieta= ry 'altc' is preferred over 'ccap'. > I don't think that a standards track RFC should give the message that pro= prietary is preferred. > Based on this issue I think the current text in the draft does not work. > I would explicitly mention the relation of ICE and 'ccap'. > The relation to other mechanism such as 'altc' needs to be treated in hte= specification of that mechanism. >=20 > Thus I propose to rephrase to: >=20 > If an offerer has implemented Interactive Connectivity Establishment (ICE= ) [RFC5245] and > the 'ccap' attribute it MUST use ICE to select between different connecti= on addresses > (e.g. "IP4" and "IP6" or different IP addresses within the same IP addre= ss family). >=20 >=20 > Regards > Thomas >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 >> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Betreff: RE : [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>=20 >> Dear Thomas, >>=20 >> I'm not proposing to change the existing behavior; I'm just >> asking whether it is acceptable to add an additional example >> to the one already cited in the text. >> Wouldn't that be acceptable? >>=20 >> You can propose to add another example if you have any in mind. >>=20 >> Cheers, >> Med >>=20 >> ________________________________________ >> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >> Date d'envoi : mercredi 13 mars 2013 17:57 >> =C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; >> mmusic@ietf.org >> Objet : AW: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>=20 >> Mohammed, >>=20 >> I think you have draft-boucadair-mmusic-altc in mind. >> This is an individual submission intended to document some >> proporietary mechanism. >> I don't think we should make restrictions in a standards >> track document in support of proprietary mechanisms. >> Otherwise I could also think of additional proprietary stuff >> that could be mentioned as well. >>=20 >>=20 >> Regards >> Thomas >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>> Im Auftrag von mohamed.boucadair@orange.com >>> Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 >>> An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >>> Betreff: Re: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>=20 >>> Hi Simo, >>>=20 >>> The document says: >>>=20 >>> The 'ccap' attribute MUST NOT be used in >>> situations where an existing mechanism (such as Interactive >>> Connectivity Establishment (ICE) [RFC5245]) can be used to select >>> between different connection addresses (e.g. "IP4" and "IP6" or >>> different IP addresses within the same IP address family). >>>=20 >>> Would it be possible to change it to the following: >>>=20 >>> NEW: >>>=20 >>> The 'ccap' attribute MUST NOT be used in >>> situations where a mechanism (such as Interactive >>> Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is >>> used to select >>> between different connection addresses (e.g. "IP4" and "IP6" or >>> different IP addresses within the same IP address family). >>>=20 >>>=20 >>> Thanks. >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>> De la part de Simo.Veikkolainen@nokia.com >>>> Envoy=E9 : mercredi 13 mars 2013 16:09 >>>> =C0 : mmusic@ietf.org >>>> Objet : Re: [MMUSIC] I-D Action: >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>=20 >>>> Hello, >>>>=20 >>>> We just submitted a new version of the miscellaneous-caps >>>> draft, with text that states that if the connection data >>>> capability attribute (a=3Dccap) is used the port number in the >>>> resulting SDP MUST be the same as in the original "m=3D" line, >>>> except for PSTN type bearers (when the port number used is 9). >>>>=20 >>>> Regards, >>>> Simo >>>>=20 >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>> On Behalf Of ext internet-drafts@ietf.org >>>> Sent: 13. maaliskuuta 2013 15:39 >>>> To: i-d-announce@ietf.org >>>> Cc: mmusic@ietf.org >>>> Subject: [MMUSIC] I-D Action: >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> This draft is a work item of the Multiparty Multimedia >>>> Session Control Working Group of the IETF. >>>>=20 >>>> Title : Miscellaneous Capabilities >>>> Negotiation in the Session Description Protocol (SDP) >>>> Author(s) : Miguel A. Garcia-Martin >>>> Simo Veikkolainen >>>> Robert R. Gilman >>>> Filename : >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> Pages : 21 >>>> Date : 2013-03-13 >>>>=20 >>>> Abstract: >>>> SDP has been extended with a capability negotiation mechanism >>>> framework that allows the endpoints to negotiate >>> transport protocols >>>> and attributes. This framework has been extended with a media >>>> capabilities negotiation mechanism that allows endpoints to >>>> negotiate >>>> additional media-related capabilities. This negotiation >>> is embedded >>>> into the widely-used SDP offer/answer procedures. >>>>=20 >>>> This memo extends the SDP capability negotiation >>> framework to allow >>>> endpoints to negotiate three additional SDP capabilities. In >>>> particular, this memo provides a mechanism to negotiate >> bandwidth >>>> ('b=3D' line), connection data ('c=3D' line), and titles >>> ('i=3D' line for >>>> each session or media). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >>>> neous-caps >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella >>>> neous-caps-04 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. -- Jonathan Lennox jonathan@vidyo.com From mohamed.boucadair@orange.com Thu Mar 14 06:11:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3D21F8F7B for ; Thu, 14 Mar 2013 06:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 5JVB2bwrCJ2C for ; Thu, 14 Mar 2013 06:11:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3D21F8F22 for ; Thu, 14 Mar 2013 06:11:00 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EC0243B4C46; Thu, 14 Mar 2013 14:10:57 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CB93035C055; Thu, 14 Mar 2013 14:10:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 14 Mar 2013 14:10:57 +0100 From: To: "Simo.Veikkolainen@nokia.com" , "aallen@blackberry.com" , "thomas.stach@siemens-enterprise.com" , "mmusic@ietf.org" , "jonathan@vidyo.com" Date: Thu, 14 Mar 2013 14:10:56 +0100 Thread-Topic: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt Thread-Index: AQHOIBnO+4bHDy/obkCLXK+GBDfayZij86oAgAAHBACAAAQ5gIAA4G3QgAADdsCAAEOSsIAAAuzA Message-ID: <94C682931C08B048B7A8645303FDC9F36EB735677D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB755B1AB@PUEXCB1B.nanterre.francetelecom.fr>, <94C682931C08B048B7A8645303FDC9F36EB755B1AC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EB7356635@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.14.110317 Subject: Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:11:05 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De : Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] >Envoy=E9 : jeudi 14 mars 2013 13:57 >=C0 : BOUCADAIR Mohamed OLNC/OLN; aallen@blackberry.com; >thomas.stach@siemens-enterprise.com; mmusic@ietf.org; >jonathan@vidyo.com >Objet : RE: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >See below [SV] > >-----Original Message----- >From: ext mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: 14. maaliskuuta 2013 11:05 >To: Veikkolainen Simo (Nokia-CTO/Espoo); >aallen@blackberry.com; thomas.stach@siemens-enterprise.com; >mmusic@ietf.org; jonathan@vidyo.com >Subject: RE: RE : [MMUSIC] RE : I-D Action: >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > >Hi Simo, > >The proposed change is not sufficient. If you want ccap to be >used to signal an IPv4 address and an IPv6 alternate one, >[SV] That's not what I want. > > the current text is underspecified (e.g, it does not specify >how to signal an alternate port for a distinct AF, how to >detect a ccap-unaware midllebox, whether multiple sessions are >established or only one is allowed, how many ccap lines are >allowed, whether ccap line can be present in both O/A, etc.). > > >But as I understood there is no consensus change then the text >should be explicit and say ccap MUST NOT be used to signal an >IPv4 address and an IPv6 alternate one. > >[SV] The same effect can be achieved by saying that ICE MUST >be used, right? Med: No. The text need to be clear and explicit IMHO. It should say it must= not be used for that purpose. > >Simo > >Cheers, >Med > >>-----Message d'origine----- >>De : Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] >>Envoy=E9 : jeudi 14 mars 2013 09:53 >>=C0 : BOUCADAIR Mohamed OLNC/OLN; aallen@blackberry.com; >>thomas.stach@siemens-enterprise.com; mmusic@ietf.org; >>jonathan@vidyo.com Objet : RE: RE : [MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>There is no change in the consensus, which is that ICE is used to >>negotiating alternative IP addresses. >> >>I'm also fine with Thomas's proposed text, but just to highlight that >>ICE is used for IP addresses I would modify a bit: >> >>--- >>If an offerer has implemented Interactive Connectivity Establishment >>(ICE) [RFC5245] and the 'ccap' attribute it MUST use ICE to select >>between different IP addresses (e.g. "IP4" >>and "IP6" or different IP addresses within the same IP >address family). >>--- >> >>Regards, >>Simo >> >>-----Original Message----- >>From: ext mohamed.boucadair@orange.com >>[mailto:mohamed.boucadair@orange.com] >>Sent: 13. maaliskuuta 2013 21:19 >>To: Andrew Allen; thomas.stach@siemens-enterprise.com; >>Veikkolainen Simo (Nokia-CTO/Espoo); mmusic@ietf.org; >>jonathan@vidyo.com >>Subject: RE : RE : [MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>Re-, >> >>The point is that if the attribute is extended to be able to >convey an >>IPv4 and an alternate IPv6@, then your statement " >>and is not intended for IPv4 vs IPv6 for which ICE is the >IETF defined >>mechanism." is not valid anymore...If that consensus changed then I'm >>puzzled why that argument was raised against altc and not ccap?!! >> >>OTOH, if the attribute is extended to cover IPv4/IPv6 then it should >>be clearly specified. The current text does not say much for >that case. >> >>Cheers, >>Med >> >>________________________________________ >>De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >>mercredi 13 mars 2013 20:03 =C0 : BOUCADAIR Mohamed OLNC/OLN; >>thomas.stach@siemens-enterprise.com; >>Simo.Veikkolainen@nokia.com; mmusic@ietf.org; >jonathan@vidyo.com Objet >>: Re: RE : [MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>The text in the draft was worked out with Jonathan Lennox who raised >>the initial concen about conflict with ICE. If Jonathan is ok >with the >>revised proposal from Thomas then I am OK with it. >> >>Andrew >> >>----- Original Message ----- >>From: mohamed.boucadair@orange.com >>[mailto:mohamed.boucadair@orange.com] >>Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >>To: Andrew Allen; thomas.stach@siemens-enterprise.com >>; >>Simo.Veikkolainen@nokia.com ; >>mmusic@ietf.org >>Subject: RE : [MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>Hi Andrew, >> >>This was also my understanding but it seems the current text >opens the >>door to signal an IPv4 and IPv6 address. >> >>If it is not allowed, then the text should be clear. >> >>Cheers, >>Med >> >>________________________________________ >>De : Andrew Allen [aallen@blackberry.com] Date d'envoi : >>mercredi 13 mars 2013 19:37 =C0 : BOUCADAIR Mohamed OLNC/OLN; >>thomas.stach@siemens-enterprise.com; >>Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : Re: >>[MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>The main use of the CCAP parameter is to indicate the >capability to use >>CS SDP and E.164 numbers as a connection address and is not intended >>for IPv4 vs IPv6 for which ICE is the IETF defined mechanism. >> >> >> >>----- Original Message ----- >>From: mohamed.boucadair@orange.com >>[mailto:mohamed.boucadair@orange.com] >>Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >>To: Stach, Thomas ; >>Simo.Veikkolainen@nokia.com ; >>mmusic@ietf.org >>Subject: [MMUSIC] RE : I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>Re-, >> >>The wording you propose is better as it explicits this behavior is >>about ICE and not something else. So, I'm fine with that wording if >>this is the intent of the authors. BTW, the altc draft >already mentions >>that if altc and ccap are both supported, then both are offered. >> >>In fact, I stopped to track this draft since the Anaheim meeting when >>it seems the consensus of the wg was: ICE is to solution to signal an >>IPv4 and IPv6 address. The misc draft should specify ccap >when distinct >>nettypes are in use. It seems that consensus is not anymore valid. >> >>The current text of ccap is under-specified if it is to be used to >>convey an IPv4 and IPv6 address. >> >>Cheers, >>Med >> >>________________________________________ >>De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >>Date d'envoi : mercredi 13 mars 2013 19:17 =C0 : BOUCADAIR Mohamed >>OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: >>[MMUSIC] I-D Action: >>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >>Mohammed, >> >>I think it is not acceptable to mention altc in the example. >>If I recollect correctly, the intention of the text is to >specify that >>ICE MUST be preferred over 'ccap' for IPv4/v6 address negotiation. >> >>If we add 'altc' as another example it basically means that the >>proprietary 'altc' is preferred over 'ccap'. >>I don't think that a standards track RFC should give the message that >>proprietary is preferred. >>Based on this issue I think the current text in the draft does not >>work. >>I would explicitly mention the relation of ICE and 'ccap'. >>The relation to other mechanism such as 'altc' needs to be treated in >>hte specification of that mechanism. >> >>Thus I propose to rephrase to: >> >>If an offerer has implemented Interactive Connectivity Establishment >>(ICE) [RFC5245] and the 'ccap' attribute it MUST use ICE to select >>between different connection addresses (e.g. >> "IP4" and "IP6" or different IP addresses within the same IP address >>family). >> >> >>Regards >>Thomas >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: mohamed.boucadair@orange.com >>> [mailto:mohamed.boucadair@orange.com] >>> Gesendet: Mittwoch, 13. M=E4rz 2013 13:40 >>> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >>> Betreff: RE : [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> >>> Dear Thomas, >>> >>> I'm not proposing to change the existing behavior; I'm just asking >>> whether it is acceptable to add an additional example to the one >>> already cited in the text. >>> Wouldn't that be acceptable? >>> >>> You can propose to add another example if you have any in mind. >>> >>> Cheers, >>> Med >>> >>> ________________________________________ >>> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >>> Date d'envoi : mercredi 13 mars 2013 17:57 =C0 : BOUCADAIR Mohamed >>> OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org Objet : AW: >>> [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> >>> Mohammed, >>> >>> I think you have draft-boucadair-mmusic-altc in mind. >>> This is an individual submission intended to document some >>> proporietary mechanism. >>> I don't think we should make restrictions in a standards track >>> document in support of proprietary mechanisms. >>> Otherwise I could also think of additional proprietary stuff that >>> could be mentioned as well. >>> >>> >>> Regards >>> Thomas >>> >>> > -----Urspr=FCngliche Nachricht----- >>> > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im >>> > Auftrag von mohamed.boucadair@orange.com >>> > Gesendet: Mittwoch, 13. M=E4rz 2013 11:20 >>> > An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >>> > Betreff: Re: [MMUSIC] I-D Action: >>> > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> > >>> > Hi Simo, >>> > >>> > The document says: >>> > >>> > The 'ccap' attribute MUST NOT be used in >>> > situations where an existing mechanism (such as Interactive >>> > Connectivity Establishment (ICE) [RFC5245]) can be used >>to select >>> > between different connection addresses (e.g. "IP4" >and "IP6" or >>> > different IP addresses within the same IP address family). >>> > >>> > Would it be possible to change it to the following: >>> > >>> > NEW: >>> > >>> > The 'ccap' attribute MUST NOT be used in >>> > situations where a mechanism (such as Interactive >>> > Connectivity Establishment (ICE) [RFC5245] or [ALTC]) >>is used to >>> > select >>> > between different connection addresses (e.g. "IP4" >and "IP6" or >>> > different IP addresses within the same IP address family). >>> > >>> > >>> > Thanks. >>> > Cheers, >>> > Med >>> > >>> > >>> > >-----Message d'origine----- >>> > >De : mmusic-bounces@ietf.org >>[mailto:mmusic-bounces@ietf.org] De la >>> > >part de Simo.Veikkolainen@nokia.com Envoy=E9 : mercredi 13 >>mars 2013 >>> > >16:09 =C0 : mmusic@ietf.org Objet : Re: [MMUSIC] I-D Action: >>> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> > > >>> > >Hello, >>> > > >>> > >We just submitted a new version of the miscellaneous-caps draft, >>> > >with text that states that if the connection data capability >>> > >attribute (a=3Dccap) is used the port number in the resulting SDP >>> > >MUST be the same as in the original "m=3D" line, except for >>PSTN type >>> > >bearers (when the port number used is 9). >>> > > >>> > >Regards, >>> > >Simo >>> > > >>> > >-----Original Message----- >>> > >From: mmusic-bounces@ietf.org >[mailto:mmusic-bounces@ietf.org] On >>> > >Behalf Of ext internet-drafts@ietf.org >>> > >Sent: 13. maaliskuuta 2013 15:39 >>> > >To: i-d-announce@ietf.org >>> > >Cc: mmusic@ietf.org >>> > >Subject: [MMUSIC] I-D Action: >>> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> > > >>> > > >>> > >A New Internet-Draft is available from the on-line >>Internet-Drafts >>> > >directories. >>> > > This draft is a work item of the Multiparty Multimedia Session >>> > >Control Working Group of the IETF. >>> > > >>> > > Title : Miscellaneous Capabilities >>> > >Negotiation in the Session Description Protocol (SDP) >>> > > Author(s) : Miguel A. Garcia-Martin >>> > > Simo Veikkolainen >>> > > Robert R. Gilman >>> > > Filename : >>> > >draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> > > Pages : 21 >>> > > Date : 2013-03-13 >>> > > >>> > >Abstract: >>> > > SDP has been extended with a capability negotiation mechanism >>> > > framework that allows the endpoints to negotiate >>> > transport protocols >>> > > and attributes. This framework has been extended with a media >>> > > capabilities negotiation mechanism that allows endpoints to >>> > >negotiate >>> > > additional media-related capabilities. This negotiation >>> > is embedded >>> > > into the widely-used SDP offer/answer procedures. >>> > > >>> > > This memo extends the SDP capability negotiation >>> > framework to allow >>> > > endpoints to negotiate three additional SDP capabilities. In >>> > > particular, this memo provides a mechanism to negotiate >>> bandwidth >>> > > ('b=3D' line), connection data ('c=3D' line), and titles >>> > ('i=3D' line for >>> > > each session or media). >>> > > >>> > > >>> > >The IETF datatracker status page for this draft is: >>> > >https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >>> > >neous-caps >>> > > >>> > >There's also a htmlized version available at: >>> > >>>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps >>> > >-04 >>> > > >>> > >A diff from the previous version is available at: >>> > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella >>> > >neous-caps-04 >>> > > >>> > > >>> > >Internet-Drafts are also available by anonymous FTP at: >>> > >ftp://ftp.ietf.org/internet-drafts/ >>> > > >>> > >_______________________________________________ >>> > >mmusic mailing list >>> > >mmusic@ietf.org >>> > >https://www.ietf.org/mailman/listinfo/mmusic >>> > >_______________________________________________ >>> > >mmusic mailing list >>> > >mmusic@ietf.org >>> > >https://www.ietf.org/mailman/listinfo/mmusic >>> > > >>> > _______________________________________________ >>> > mmusic mailing list >>> > mmusic@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mmusic >>> > >>> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic >> >>--------------------------------------------------------------------- >>This transmission (including any attachments) may contain >confidential >>information, privileged material (including material protected by the >>solicitor-client or other applicable privileges), or constitute >>non-public information. Any use of this information by anyone other >>than the intended recipient is prohibited. If you have received this >>transmission in error, please immediately reply to the sender and >>delete this information from your system. Use, dissemination, >>distribution, or reproduction of this transmission by unintended >>recipients is not authorized and may be unlawful. >> >>--------------------------------------------------------------------- >>This transmission (including any attachments) may contain >confidential >>information, privileged material (including material protected by the >>solicitor-client or other applicable privileges), or constitute >>non-public information. Any use of this information by anyone other >>than the intended recipient is prohibited. If you have received this >>transmission in error, please immediately reply to the sender and >>delete this information from your system. Use, dissemination, >>distribution, or reproduction of this transmission by unintended >>recipients is not authorized and may be unlawful. >> > From fandreas@cisco.com Thu Mar 14 06:57:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D8911E80DF for ; Thu, 14 Mar 2013 06:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 fQ7OTZP9x+-X for ; Thu, 14 Mar 2013 06:57:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D244221F8E5A for ; Thu, 14 Mar 2013 06:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47706; q=dns/txt; s=iport; t=1363269417; x=1364479017; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4Y52/aEkWPRKn4J6QVdHwRI6MnYrx0RJZbV+SqBDtLc=; b=Cw5UPn1qo9c7kYvVUgPmsujnEf0vICaz0Y+L4xGLogQhwRB5Jt/PpcUv EIZxpKGyLNiO1BAYCky+WHkZjtMIBAT2AUxsOtZ6YyvWD6b4XpaFhMHGH g7KVmsGGMMJUKh7uNbIj9b/Kzjr89xu0yi3t56Yz/vBP3UJUOc5ZtiNNw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEHWQVGtJV2Y/2dsb2JhbABDxHiBYRZ0giMHAQEBAwEBAQEXAUwHCgEFCwsYCQwKAQENCQMCAQIBFTAGDQEFAgEBBYVAB4I+BgywUpBOiXiFDgoHCoM2A5MTg0WRAoMmIA X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208,217";a="184446536" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 14 Mar 2013 13:56:54 +0000 Received: from dhcp-170e.meeting.ietf.org ([10.86.246.161]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EDur84032145; Thu, 14 Mar 2013 13:56:53 GMT Message-ID: <5141D725.3030706@cisco.com> Date: Thu, 14 Mar 2013 09:56:53 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Gunnar Hellstrom References: <513E504F.1010209@omnitor.se> In-Reply-To: <513E504F.1010209@omnitor.se> Content-Type: multipart/alternative; boundary="------------000801040009090103020401" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:57:12 -0000 This is a multi-part message in MIME format. --------------000801040009090103020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 3/11/13 5:44 PM, Gunnar Hellstrom wrote: > Before this discussion got its home in mmusic, we discussed quite > similar topics as you, Dale brought up now. > > It was about what was needed to be expressed by the parameters and if > SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / > 3841 could be a suitable mechanism for routing and decisions on the > parameters. > I agree more discussion is needed on this. There seems to be two problems considered in the draft: 1) Routing of a request to an answerer that has the language capabilities the caller desires. 2) Negotiation of the language properties to use on a per-stream basis once the call has been routed to a particular answerer. Problem 1 seems to fall in the RFC 3840/3841 space, whereas problem 2 is more of an SDP issue. -- Flemming > Here is part of that discussion that we need to capture. > > > I see some complication that might be needed in order to reflect > reality. At least they should be discussed. > > And I am also seeing some different ways to specify it. > > The complications to discuss are: > > *1. Level of preference.* > > There may be a need for specifying levels of preference for > languages. I might strongly prefer to talk English, but have some > useful capability in French. I want to display that preference and > that capability with that difference, so that I get English whenever > possible, but get the call connected even if English is not available > at all but French is. > > I would assume that two levels are sufficient, but that can be > discussed: Preferred and capable. >> >> The draft already proposes that languages be listed in order of >> preference, which should handle the example you mention: you list >> English first and French second. The called party selects English if >> it is capable and falls back to French if English is not and French >> is. This seems much simpler and is a common way of handling >> situations where there is a preference. It would be good to keep the >> mechanism as simple as possible. >> Yes, I am afraid of complicating this beyond the point when users do >> not manage to get their settings right. >> Still, I do not think that the order is sufficient as level of >> preference indicator. You may want to indicate capability for one >> modality but preference for another. ( as my example, capability for >> ASL, but preference for talking and reading ) > > If you have a capability for ASL but preference for talking and > reading, you could initially offer two media streams: a voice with > English and a text with English. If accepted, you have your preferred > communications. If those are rejected you could then offer video with > ASL. Would that handle the case? > No, video is still very valuable for judging the emergency case. Or > seeing a friend. So, if you support it you want to offer it. But the > decision on languages and modalities may end up in video being not > important for language communication. > > >> >> >>>>> *2. Directionality* >>>>> There is a need for a direction of the language preference. >>>>> "Transmit, receive or both". or "Produce, perceive or both". >>>>> That is easy to understand for the relay service examples. >>>>> A hard-of-hearing user may declare: >>>>> >>>>> Text, capable, produce, English >>>>> Text, prefer, perceive, English >>>>> Audio, prefer, produce, English >>>>> Audio, capable, perceive, English ( tricky, a typical >>>>> hard-of-hearing user may have benefit of receiving audio, while it >>>>> is not usable enough for reliable perception. I do not want to see >>>>> this eternally complex, but I see a need for refined expressions here) >>>>> video, capable, both, ASL >>>>> >>>>> This should be understood as that the user prefers to speak and >>>>> get text back, and has benefit of getting voice in parallel with >>>>> text. ASL signing can be an alternative if the other party has >>>>> corresponding capability or preference. >>>>> >>>> >>>> The draft does support this (and even mentions some of these >>>> specific uses) because it proposes an SDP media attribute, and >>>> media can be specified to be send, receive, or both. >>> No, that is not the same. You want the media to flow, but by the >>> parameter you want to indicate your preference for how to use it. >>> You do not want to turn off incoming audio just because you prefer >>> to talk but read text. >> >> Yes, I see, thanks for the clarification. Does this need to be part >> of the session setup? If you establish all media streams that you >> wish to use, can you then just use them as you prefer? I will >> consult with the NENA accessibility committee on this. > No, there are specific services providing service with one direction > but not the other. The information is needed for decision on what > assisting service to invoke. One such service is the captioned > telephony, that adds rapidly created speech-to-text in parallel with > the voice. They provide just that. A user will have a very strong > preference for getting just that service, but could accept with much > lower preference to get a direct conversation with the far end in > combined text and voice. >> >> >>>>> I think it would be useful to move most of the introduction to a >>>>> structured use case chapter and express the different cases >>>>> according to a template. Thast can then be used to test if >>>>> proposed approaches will work. >>>> >>>> I'm not sure I fully understand what you mean by "structured" in >>>> "structured use case" or "template." Can you be more specific? >>> I mean just a simple template for how the use case descriptions are >>> written. >>> >>> E.g. >>> A title indicating what case we have. >>> Description of the calling user and its capabilities and preferences. >>> Description of the answering user and its capabilities and preferences >>> Description of a possible assisting service and its capabilities and >>> preferences >>> Description of the calling user's indications. >>> Description of the answering user's indications. >>> The resulting decision and outcome >>>> >>>> >>>>> *3. Specify language and modality at SIP Media tag level instead. >>>>> *There could be some benfits to declare these parameters at the >>>>> SIP media tag level instead of SDP level. >>>>> A call center can then register with their capabilities already at >>>>> the SIP REGISTER time, and the caller preferences / callee >>>>> capabilities mechanism from RFC 3840/ 3841 can be used to select >>>>> modalities and languages and route the call to the best capable >>>>> person or combination of person and assisting interpreting. >>>> >>>> Maybe, but one advantage of using SDP is that the ESInet can take >>>> language and media needs into account during policy-based routing. >>>> For example, in some European countries emergency calls placed by a >>>> speaker of language x in country y may be routed to a PSAP in a >>>> country where x is the native language. Or, there might be >>>> regional or national text relay or sign language interpreter >>>> services as opposed to PSAP-level capabilities. >>> Is there a complete specification for how policy based routing is >>> thought to work? Where? >>> Does it not use RFC 3840/3841? >>> That procedure is already supported by SIP servers. Using SDP >>> requires new SIP server programming. >> >> NENA has a document under development. I thought it was able to take >> SDP into account but I'll look into it, and I'm sure Brian will have >> something to say. > Yes, I think I have seen that. But it needs to come into IETF to be > possible to refer to. >> >> >>>>> But, on the other hand, then we need a separate specification of >>>>> what modality the parameters indicate, because the language tags >>>>> only distinguish between signed and other languages, and "other" >>>>> seems to mean either spoken or written without any difference. >>>>> >>>> >>>> The SDP media already indicates the type (audio, video, text). >>> Yes, convenient. But there is no knowledge about the parameters >>> until at call time. It could be better to know the callee >>> capabilities in advance if available. Then middle boxes can do the >>> routing instead of the far end. There may be many terminals >>> competing for the call and the comparison about who to get it should >>> be done by a sip server instead of an endpoint. >> >> I think call time is the right time. For emergency calls, it >> isolates the decision making about how to process calls requiring >> text, sign language, foreign language, etc. to the ESInet and PSAPs, >> which is I think the right place. The processing rules in the ESInet >> can then be changed without involving any carrier. The capabilities >> of an entity may vary based on dynamic factors (time of day, load, >> etc.) so the decision as to how to support a need may be best made by >> the ESInet or PSAP in the case of an emergency call, or called party >> for non-emergency calls. For example, at some times or under some >> loads, emergency calls may be routed to a specific PSAP that is not >> the geographically indicated one. Likewise, a non-emergency call to >> a call center may be routed to a center in a country that has support >> for the language or media needed. > The decision is of course made at call time. With the RFC 3840/3841 > method, the different agents and services available register their > availability and capabilities when they go on duty, and unregister > when they stop, so that their information is available at call time. > >> >> Further, it is often the case that the cost of relay, interpretation, >> or translation services is affected by which entity invokes the service. > Yes, that is a complicating policy issue. >> >> >>>>> *4. Problem that 3GPP specifies that it is the UAs only who >>>>> specify and act on these parameters. >>>>> *I think it is a problem that 3GPP inserted the restriction that >>>>> the language and modality negotiation shall only bother the >>>>> involved UAs. >>>>> It would be more natural that it is a service provider between >>>>> them who detect the differences and make the decision to invoke a >>>>> relay service for the relay case. >>>>> How do you propose to solve that? Let the service provider behave >>>>> as a B2BUA, who then can behave as both a UA and a service provider? >>>> >>>> What do you mean by "service provider?" In the case of a voice >>>> service provider such as a cellular carrier or a VoIP provider, I >>>> think this should be entirely transparent. The voice service >>>> provider knows it is an emergency call and routes to an ESInet. It >>>> is then up to the ESInet and the PSAPs to handle the call as they wish. >>> It can be a service provider for just the function to make advanced >>> call invocation based on language preferences. The same type of >>> decisions, call connections and assisting service invocation are >>> needed in everyday calls as in emergency calls. But it can also be a >>> service provider for emergency services and the user is registered >>> by that service provider. They can make decisions on the call. E.g. >>> detect that it is an emergency call requiring interpreter, and >>> therefore connect to both the PSAP and interpreter at the same time >>> to save time. >> >> I think it's best to make these decisions at the end, not the >> middle. In the case of emergency calls, the ESInet can route to a >> particular PSAP, the PSAP may bridge in translation or interpretation >> services, etc. In the case of non-emergency calls, the call center >> may support some capabilities locally at some hours but route to a >> different call center at other times. > The end is not decided until you have evaluated the alternative > possible ends and decided who has the right capability and preference. > > > > There is another issue with using sdp for decisions. SIP Message is > included in the set of methods to handle in emergency calls in RFC > 6443. It can be used within sessions to carry text messages if other > media are used as well. It is no favored way to have text > communication, but possible. SIP message has no sdp. I know that the > 3GPP sections about emergency calling in TS 22.101 points towards > using MSRP for text messaging, so it should not be an issue for 3GPP. > Can we neglect SIP Message from the discussion and aim at solving it > only for real-time conversational media? I do not urge for solving it > for SIP Message, I just wanted to point out that result by basing the > mechanism on SDP. > > > > > > > Will there be a possibility for remote participation on Thursday. I am > sorry I am not there, but would like to participate if possible. > /Gunnar > > ------------------------------------------------------------------------ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > On 2013-03-11 16:57, Randall Gellens wrote: >> [[[ resending without Cc list ]]] >> >> Hi Dale, >> >> At 11:00 AM -0500 2/25/13, Dale R. Worley wrote: >> >>> (It's not clear to me what the proper mailing list is to discuss this >>> draft. From the headers of the messages, it appears that the primary >>> list is ietf@ietf.org, but the first message in this thread about that >>> draft already has a "Re:" in the subject line, so the discussion >>> started somewhere else.) >> >> There has been some discussion among those listed in the CC header of >> this message. I think the mmusic list is probably the right place to >> continue the discussion and was planning on doing so more formally >> with the next revision of the draft. >> >> By the way, the draft was updated and is now at -02: >> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt >> >> There is a face-to-face discussion Thursday 11:30-1:00 at The >> Tropicale (the cafe in the Caribe Royal). Please let me know if you >> can make it. >> >>> (Also, it's not clear why Randall's messages are coming through in >>> HTML.) >> >> My apologies; I have gotten in the habit when replying to messages >> that have style to allow Eudora to send my reply styled as well. >> >> >>> But onward to questions of substance: >>> >>> - Why SDP and not SIP? >>> >>> I'd like to see a more thorough exploration of why language >>> negotiation is to be handled in SDP rather than SIP. (SIP, like HTTP, >>> uses the Content-Language header to specify languages.) In principle, >>> specifying data that may be used in call-routing should be done in the >>> SIP layer, but it's well-accepted in the SIP world that call routing >>> may be affected by the SDP content as well (e.g., media types). >> >> I think it fits more naturally in SDP since the language is related >> to the media, e.g., English for audio and ASL for video. >> >> >>> And some discussion and comparison should be done with the SIP/HTTP >>> Content-Language header (used to specify the language of the >>> communications) and the SIP Accept-Language header (used to specify >>> the language of text components of SIP messages), particularly given >>> that Accept-Language has different set of language specifiers and a >>> richer syntax for specifying preferences. In any case, preference >>> should be given to reusing one of the existing syntaxes for specifying >>> language preferences. >> >> I think the semantics of Content-Language and Accept-Language are >> different from the semantics here, especially when setting up a >> session with, as an example, an audio stream using English and a >> video stream using ASL. (But I can see clients using a default value >> to set both the SDP language attribute and the HTTP Content-Language, >> unless configured differently.) >> >> As for reusing existing mechanisms, the draft does contain two >> alternative proposals, one to re-use the existing 'language' SDP >> attribute, and one to define a new attribute. >> >>> - Dependency between media descriptions? >>> >>> Another example would be a user who is able to speak but is deaf or >>> hard-of-hearing and requires a voice stream plus a text stream >>> (known as voice carry over). Making language a media attribute >>> allows the standard session negotiation mechanism to handle this by >>> providing the information and mechanism for the endpoints to make >>> appropriate decisions. >>> >>> This scenario suggests that there might be dependency or interaction >>> between language specifications for different media descriptions. >>> Whether this is needed should be determined and documented. >>> >>> - Specifying preference levels? >>> >>> For example, some users may be able to speak several languages, but >>> have a preference. >>> >>> This might argue for describing degrees of preference using "q" >>> parameters (as in the SIP Accept-Language header). >>> >>> - Expressing multiple languages in answers >>> >>> (While it is true that a conversation among multilingual people >>> often involves multiple languages, it does not seem useful enough >>> as a general facility to warrant complicating the desired semantics >>> of the SDP attribute to allow negotiation of multiple simultaneous >>> languages within an interactive media stream.) >>> >>> Why shouldn't an answer be able to indicate multiple languages? At >>> the least, this might provide the offerer with useful information. >> >> You raise good questions that I think need more discussion. I am >> hoping to keep the work as simple as possible and not add additional >> complexity, which argues for not solving every aspect of the problem, >> but only those that must be solved immediately. >> >>> >>> - Reusing a=lang >>> >>> Searching, I can only find these descriptions of the use of >>> "a=lang:...": >>> >>> RFC 4566 >>> draft-saintandre-sip-xmpp-chat >>> draft-gellens-negotiating-human-language >>> >>> So it looks like "a=lang:..." is entirely unused at the present and is >>> safe to be redefined. >> >> >> >> >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------000801040009090103020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/11/13 5:44 PM, Gunnar Hellstrom wrote:
Before this discussion got its home in mmusic, we discussed quite similar topics as you, Dale brought up now.

It was about what was needed to be expressed by the parameters and if SDP or SIP was the right place. And in the case of SIP, if RFC 3840 / 3841 could be a suitable mechanism for routing and decisions on the parameters.

I agree more discussion is needed on this. There seems to be two problems considered in the draft:
1) Routing of a request to an answerer that has the language capabilities the caller desires.
2) Negotiation of the language properties to use on a per-stream basis once the call has been routed to a particular answerer.

Problem 1 seems to fall in the RFC 3840/3841 space, whereas problem 2 is more of an SDP issue.

-- Flemming


Here is part of that discussion that we need to capture.


I see some complication that might be needed in order to reflect reality. At least they should be discussed.

And I am also seeing some different ways to specify it.

The complications to discuss are:

1. Level of preference.

There may be a need for specifying levels of preference for languages.  I might strongly prefer to talk English, but have some useful capability in French. I want to display that preference and that capability with that difference, so that I get English whenever possible, but get the call connected even if English is not available at all but French is.

I would assume that two levels are sufficient, but that can be discussed:  Preferred and capable.

The draft already proposes that languages be listed in order of preference, which should handle the example you mention: you list English first and French second.  The called party selects English if it is capable and falls back to French if English is not and French is.  This seems much simpler and is a common way of handling situations where there is a preference.  It would be good to keep the mechanism as simple as possible.
Yes, I am afraid of complicating this beyond the point when users do not manage to get their settings right.
Still, I do not think that the order is sufficient as level of preference indicator. You may want to indicate capability for one modality but preference for another. ( as my example, capability for ASL, but preference for talking and reading )

If you have a capability for ASL but preference for talking and reading, you could initially offer two media streams: a voice with English and a text with English.  If accepted, you have your preferred communications.  If those are rejected you could then offer video with ASL.  Would that handle the case?
No, video is still very valuable for judging the emergency case. Or seeing a friend. So, if you support it you want to offer it. But the decision on languages and modalities may end up in video being not important for language communication.




2. Directionality
There is a need for a direction of the language preference. "Transmit, receive or both". or   "Produce, perceive or both". That is easy to understand for the relay service examples.
A hard-of-hearing user may declare:

Text, capable, produce, English
Text, prefer, perceive, English
Audio, prefer, produce, English
Audio, capable, perceive, English    ( tricky, a typical hard-of-hearing user may have benefit of receiving audio, while it is not usable enough for reliable perception. I do not want to see this eternally complex, but I see a need for refined expressions here)
video, capable, both, ASL 

This should be understood as that the user prefers to speak and get text back, and has benefit of getting voice in parallel with text.  ASL signing can be an alternative if the other party has corresponding capability or preference.


The draft does support this (and even mentions some of these specific uses) because it proposes an SDP media attribute, and media can be specified to be send, receive, or both.
No, that is not the same. You want the media to flow, but by the parameter you want to indicate your preference for how to use it.  You do not want to turn off incoming audio just because you prefer to talk but read text.

Yes, I see, thanks for the clarification.  Does this need to be part of the session setup?  If you establish all media streams that you wish to use, can you then just use them as you prefer?  I will consult with the NENA accessibility committee on this.
No, there are specific services providing service with one direction but not the other. The information is needed for decision on what assisting service to invoke. One such service is the captioned telephony, that adds rapidly created speech-to-text in parallel with the voice. They provide just that. A user will have a very strong preference for getting just that service, but could accept with much lower preference to get a direct conversation with the far end in combined text and voice.


I think it would be useful  to move most of the introduction to a structured use case chapter and express the different cases according to a template. Thast can then be used to test if proposed approaches will work.

I'm not sure I fully understand what you mean by "structured" in "structured use case" or "template."  Can you be more specific?
I mean just a simple template for how the use case descriptions are written.

E.g.
A title indicating what case we have.
Description of the calling user and its capabilities and preferences.
Description of the answering user and its capabilities and preferences
Description of a possible assisting service and its capabilities and preferences
Description of the calling user's indications.
Description of the answering user's indications.
The resulting decision and outcome


3.  Specify language and modality at SIP Media tag level instead.
There could be some benfits to declare these parameters at the SIP media tag level instead of SDP level.
A call center can then register with their capabilities already at the SIP REGISTER time, and the caller preferences / callee capabilities mechanism from RFC 3840/ 3841 can be used to select modalities and languages and route the call to the best capable person or combination of person and assisting interpreting.

Maybe, but one advantage of using SDP is that the ESInet can take language and media needs into account during policy-based routing.  For example, in some European countries emergency calls placed by a speaker of language x in country y may be routed to a PSAP in a country where x is the native language.  Or, there might be regional or national text relay or sign language interpreter services as opposed to PSAP-level capabilities.
Is there a complete specification for how policy based routing is thought to work? Where?
Does it not use RFC 3840/3841?
That procedure is already supported by SIP servers. Using SDP requires new SIP server programming.

NENA has a document under development.  I thought it was able to take SDP into account but I'll look into it, and I'm sure Brian will have something to say.
Yes, I think I have seen that. But it needs to come into IETF to be possible to refer to.


But, on the other hand, then we need a separate specification of what modality the parameters indicate, because the language tags only distinguish between signed and other languages, and "other" seems to mean either spoken or written without any difference.


The SDP media already indicates the type (audio, video, text).
Yes, convenient. But there is no knowledge about the parameters until at call time. It could be better to know the callee capabilities in advance if available. Then middle boxes can do the routing instead of the far end. There may be many terminals competing for the call and the comparison about who to get it should be done by a sip server instead of an endpoint.

I think call time is the right time.  For emergency calls, it isolates the decision making about how to process calls requiring text, sign language, foreign language, etc. to the ESInet and PSAPs, which is I think the right place.  The processing rules in the ESInet can then be changed without involving any carrier.  The capabilities of an entity may vary based on dynamic factors (time of day, load, etc.) so the decision as to how to support a need may be best made by the ESInet or PSAP in the case of an emergency call, or called party for non-emergency calls.  For example, at some times or under some loads, emergency calls may be routed to a specific PSAP that is not the geographically indicated one.  Likewise, a non-emergency call to a call center may be routed to a center in a country that has support for the language or media needed.
The decision is of course made at call time. With the RFC 3840/3841 method, the different agents and services available register their availability and capabilities when they go on duty, and unregister when they stop, so that their information is available at call time.
 

Further, it is often the case that the cost of relay, interpretation, or translation services is affected by which entity invokes the service.
Yes, that is a complicating policy issue.


4. Problem that 3GPP specifies that it is the UAs only who specify and act on these parameters.
I think it is a problem that 3GPP inserted the restriction that the language and modality negotiation shall only bother the involved UAs.
It would be more natural that it is a service provider between them who detect the differences and make the decision to invoke a relay service for the relay case.
How do you propose to solve that? Let the service provider behave as a B2BUA, who then can behave as both a UA and a service provider?

What do you mean by "service provider?"  In the case of a voice service provider such as a cellular carrier or a VoIP provider, I think this should be entirely transparent.  The voice service provider knows it is an emergency call and routes to an ESInet.  It is then up to the ESInet and the PSAPs to handle the call as they wish.
It can be a service provider for just the function to make advanced call invocation based on language preferences. The same type of decisions, call connections and assisting service invocation are needed in everyday calls as in emergency calls. But it can also be a service provider for emergency services and the user is registered by that service provider. They can make decisions on the call. E.g. detect that it is an emergency call requiring interpreter, and therefore connect to both the PSAP and interpreter at the same time to save time.

I think it's best to make these decisions at the end, not the middle.  In the case of emergency calls, the ESInet can route to a particular PSAP, the PSAP may bridge in translation or interpretation services, etc.  In the case of non-emergency calls, the call center may support some capabilities locally at some hours but route to a different call center at other times.
The end is not decided until you have evaluated the alternative possible ends and decided who has the right capability and preference.



There is another issue with using sdp for decisions. SIP Message is included in the set of methods to handle in emergency calls in RFC 6443. It can be used within sessions to carry text messages if other media are used as well. It is no favored way to have text communication, but possible. SIP message has no sdp.  I know that the 3GPP sections  about emergency calling in TS 22.101 points towards using MSRP for text messaging, so it should not be an issue for 3GPP. Can we neglect SIP Message from the discussion and aim at solving it only for real-time conversational media?  I do not urge for solving it for SIP Message, I just wanted to point out that result by basing the mechanism on SDP.

 




Will there be a possibility for remote participation on Thursday. I am sorry I am not there, but would like to participate if possible.
/Gunnar

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-03-11 16:57, Randall Gellens wrote:
[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:

 (It's not clear to me what the proper mailing list is to discuss this
 draft.  From the headers of the messages, it appears that the primary
 list is ietf@ietf.org, but the first message in this thread about that
 draft already has a "Re:" in the subject line, so the discussion
 started somewhere else.)

There has been some discussion among those listed in the CC header of this message.  I think the mmusic list is probably the right place to continue the discussion and was planning on doing so more formally with the next revision of the draft.

By the way, the draft was updated and is now at -02: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The Tropicale (the cafe in the Caribe Royal).  Please let me know if you can make it.

 (Also, it's not clear why Randall's messages are coming through in
 HTML.)

My apologies; I have gotten in the habit when replying to messages that have style to allow Eudora to send my reply styled as well.


 But onward to questions of substance:

 - Why SDP and not SIP?

 I'd like to see a more thorough exploration of why language
 negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
 uses the Content-Language header to specify languages.)  In principle,
 specifying data that may be used in call-routing should be done in the
 SIP layer, but it's well-accepted in the SIP world that call routing
 may be affected by the SDP content as well (e.g., media types).

I think it fits more naturally in SDP since the language is related to the media, e.g., English for audio and ASL for video.


 And some discussion and comparison should be done with the SIP/HTTP
 Content-Language header (used to specify the language of the
 communications) and the SIP Accept-Language header (used to specify
 the language of text components of SIP messages), particularly given
 that Accept-Language has different set of language specifiers and a
 richer syntax for specifying preferences.  In any case, preference
 should be given to reusing one of the existing syntaxes for specifying
 language preferences.

I think the semantics of Content-Language and Accept-Language are different from the semantics here, especially when setting up a session with, as an example, an audio stream using English and a video stream using ASL.  (But I can see clients using a default value to set both the SDP language attribute and the HTTP Content-Language, unless configured differently.)

As for reusing existing mechanisms, the draft does contain two alternative proposals, one to re-use the existing 'language' SDP attribute, and one to define a new attribute.

 - Dependency between media descriptions?

    Another example would be a user who is able to speak but is deaf or
    hard-of-hearing and requires a voice stream plus a text stream
    (known as voice carry over).  Making language a media attribute
    allows the standard session negotiation mechanism to handle this by
    providing the information and mechanism for the endpoints to make
    appropriate decisions.

 This scenario suggests that there might be dependency or interaction
 between language specifications for different media descriptions.
 Whether this is needed should be determined and documented.

 - Specifying preference levels?

    For example, some users may be able to speak several languages, but
    have a preference.

 This might argue for describing degrees of preference using "q"
 parameters (as in the SIP Accept-Language header).

 - Expressing multiple languages in answers

    (While it is true that a conversation among multilingual people
    often involves multiple languages, it does not seem useful enough
    as a general facility to warrant complicating the desired semantics
    of the SDP attribute to allow negotiation of multiple simultaneous
    languages within an interactive media stream.)

 Why shouldn't an answer be able to indicate multiple languages?  At
 the least, this might provide the offerer with useful information.

You raise good questions that I think need more discussion.  I am hoping to keep the work as simple as possible and not add additional complexity, which argues for not solving every aspect of the problem, but only those that must be solved immediately.


 - Reusing a=lang

 Searching, I can only find these descriptions of the use of
 "a=lang:...":

     RFC 4566
     draft-saintandre-sip-xmpp-chat
     draft-gellens-negotiating-human-language

 So it looks like "a=lang:..." is entirely unused at the present and is
 safe to be redefined. 








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

--------------000801040009090103020401-- From fandreas@cisco.com Thu Mar 14 07:34:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD4D11E8126 for ; Thu, 14 Mar 2013 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 D5uR2T+tkgLk for ; Thu, 14 Mar 2013 07:34:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8321F8E76 for ; Thu, 14 Mar 2013 07:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39223; q=dns/txt; s=iport; t=1363271676; x=1364481276; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=J860RcN7rKumz5WFkHEsVev2RES1OzacMoPEZW20ysA=; b=ex86Psh6oixLFXWatHhZbnAmlbZA/FIdWU6IpJ+79yAZy/U10fmmvTo6 PoOcCTYDHRcNj0Ci2lGIVJrSV22qWGu9Z+ctk6J2BRNYhX3lknvPWQx3W 20DdIBNz4y/BrNDOH58ZkP4KL8mjQr39odFBTeZvLGY2exa6DenCVoVbk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFALTfQVGtJXG9/2dsb2JhbABEhVC/KIFiFnSCKgEBAQQBAQEXVAQGAQwECxEEAQEBCRYBAQYHCQMCAQIBFR8JCAYBDAEFAgEBBRKHeQcFwSmNX4EmCwcGgzoDlliBH49jgyYggTc X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208,217";a="184462849" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 14 Mar 2013 14:34:33 +0000 Received: from dhcp-170e.meeting.ietf.org ([10.86.246.161]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EEYWQB031095; Thu, 14 Mar 2013 14:34:32 GMT Message-ID: <5141DFF8.4050006@cisco.com> Date: Thu, 14 Mar 2013 10:34:32 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jonathan Lennox , mohamed.boucadair@orange.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020602060207060702050803" Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:34:39 -0000 This is a multi-part message in MIME format. --------------020602060207060702050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit A couple of points here related to the overall thread: 1) WGLC for this draft completed about 6 months ago with no comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html). The -01 version that was WGLC'ed stated the following: The 'ccap' capability attribute is intended to be used only when there is no other mechanism available for negotiating alternative connection address information, such as when the is different among the alternative addresses. The 'ccap' attribute MUST NOT be used in situations where an existing mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245]) can be used to select between different connection addresses. The 'ccap' capability attribute is intended to be used only when there is no other mechanism available for negotiating alternative connection address information, such as when the is different among the alternative addresses (e.g. "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in situations where an existing mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245]) can be used to select between different connection addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). The only difference is the addition of clarifying examples and hence there is no change in operation here. 2) On January 25, Simo sent an e-mail to the list pointing out the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html). To recap, the draft specifically does not define port negotiation (but simply reuses the current port in accordance with general capability negotiation operation). Since this doesn't work when changing between IN and PSTN, exception text to use port 9 for PSTN was added (again in accordance with previous discussion). One comment was received, which was in favor of the proposal. The comments brought up now are not identifying any new or severe problems, but essentially amount to word-smithing requests. As a Working Group chair, I am unsympathetic to such requests on a document that is this far along and furthermore has external dependencies. We go through a WGLC process for a reason, and people need to review and make their comments at that time. Comments on new text or changes made since the WGLC completed are of course reasonable. With that in mind, if anybody still has comments on the -04 version, please let us know. Thanks -- Flemming (MMUSIC co-chair) On 3/14/13 9:04 AM, Jonathan Lennox wrote: > I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses. We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it. > > Thus, I suggest something like this (wordsmithing requested): > > The 'ccap' attribute MUST NOT be used to offer multiple addresses with the "IN" (i.e., multiple Internet protocol addresses) in the same media stream. Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses. The use of ICE with capability negotiation is described in section 3.7 of [RFC5939]. > > > This text might also be useful (though it definitely needs editorial improvement): > > In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the "IN"); otherwise, under the rules of ICE, an ICE mismatch will result. However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer. > > > On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote: > >> The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it. >> >> Andrew >> >> ----- Original Message ----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >> Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >> To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org >> Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Hi Andrew, >> >> This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address. >> >> If it is not allowed, then the text should be clear. >> >> Cheers, >> Med >> >> ________________________________________ >> De : Andrew Allen [aallen@blackberry.com] >> Date d'envoi : mercredi 13 mars 2013 19:37 >> À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined mechanism. >> >> >> >> ----- Original Message ----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >> Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >> To: Stach, Thomas ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org >> Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Re-, >> >> The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered. >> >> In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid. >> >> The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address. >> >> Cheers, >> Med >> >> ________________________________________ >> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >> Date d'envoi : mercredi 13 mars 2013 19:17 >> À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> Mohammed, >> >> I think it is not acceptable to mention altc in the example. >> If I recollect correctly, the intention of the text is to specify that ICE MUST be >> preferred over 'ccap' for IPv4/v6 address negotiation. >> >> If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'. >> I don't think that a standards track RFC should give the message that proprietary is preferred. >> Based on this issue I think the current text in the draft does not work. >> I would explicitly mention the relation of ICE and 'ccap'. >> The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism. >> >> Thus I propose to rephrase to: >> >> If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and >> the 'ccap' attribute it MUST use ICE to select between different connection addresses >> (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). >> >> >> Regards >> Thomas >> >>> -----Ursprüngliche Nachricht----- >>> Von: mohamed.boucadair@orange.com >>> [mailto:mohamed.boucadair@orange.com] >>> Gesendet: Mittwoch, 13. März 2013 13:40 >>> An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org >>> Betreff: RE : [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> >>> Dear Thomas, >>> >>> I'm not proposing to change the existing behavior; I'm just >>> asking whether it is acceptable to add an additional example >>> to the one already cited in the text. >>> Wouldn't that be acceptable? >>> >>> You can propose to add another example if you have any in mind. >>> >>> Cheers, >>> Med >>> >>> ________________________________________ >>> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >>> Date d'envoi : mercredi 13 mars 2013 17:57 >>> À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; >>> mmusic@ietf.org >>> Objet : AW: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>> >>> Mohammed, >>> >>> I think you have draft-boucadair-mmusic-altc in mind. >>> This is an individual submission intended to document some >>> proporietary mechanism. >>> I don't think we should make restrictions in a standards >>> track document in support of proprietary mechanisms. >>> Otherwise I could also think of additional proprietary stuff >>> that could be mentioned as well. >>> >>> >>> Regards >>> Thomas >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>> Im Auftrag von mohamed.boucadair@orange.com >>>> Gesendet: Mittwoch, 13. März 2013 11:20 >>>> An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >>>> Betreff: Re: [MMUSIC] I-D Action: >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> >>>> Hi Simo, >>>> >>>> The document says: >>>> >>>> The 'ccap' attribute MUST NOT be used in >>>> situations where an existing mechanism (such as Interactive >>>> Connectivity Establishment (ICE) [RFC5245]) can be used to select >>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>> different IP addresses within the same IP address family). >>>> >>>> Would it be possible to change it to the following: >>>> >>>> NEW: >>>> >>>> The 'ccap' attribute MUST NOT be used in >>>> situations where a mechanism (such as Interactive >>>> Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is >>>> used to select >>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>> different IP addresses within the same IP address family). >>>> >>>> >>>> Thanks. >>>> Cheers, >>>> Med >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>> De la part de Simo.Veikkolainen@nokia.com >>>>> Envoyé : mercredi 13 mars 2013 16:09 >>>>> À : mmusic@ietf.org >>>>> Objet : Re: [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>> >>>>> Hello, >>>>> >>>>> We just submitted a new version of the miscellaneous-caps >>>>> draft, with text that states that if the connection data >>>>> capability attribute (a=ccap) is used the port number in the >>>>> resulting SDP MUST be the same as in the original "m=" line, >>>>> except for PSTN type bearers (when the port number used is 9). >>>>> >>>>> Regards, >>>>> Simo >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>> On Behalf Of ext internet-drafts@ietf.org >>>>> Sent: 13. maaliskuuta 2013 15:39 >>>>> To: i-d-announce@ietf.org >>>>> Cc: mmusic@ietf.org >>>>> Subject: [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>> This draft is a work item of the Multiparty Multimedia >>>>> Session Control Working Group of the IETF. >>>>> >>>>> Title : Miscellaneous Capabilities >>>>> Negotiation in the Session Description Protocol (SDP) >>>>> Author(s) : Miguel A. Garcia-Martin >>>>> Simo Veikkolainen >>>>> Robert R. Gilman >>>>> Filename : >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>> Pages : 21 >>>>> Date : 2013-03-13 >>>>> >>>>> Abstract: >>>>> SDP has been extended with a capability negotiation mechanism >>>>> framework that allows the endpoints to negotiate >>>> transport protocols >>>>> and attributes. This framework has been extended with a media >>>>> capabilities negotiation mechanism that allows endpoints to >>>>> negotiate >>>>> additional media-related capabilities. This negotiation >>>> is embedded >>>>> into the widely-used SDP offer/answer procedures. >>>>> >>>>> This memo extends the SDP capability negotiation >>>> framework to allow >>>>> endpoints to negotiate three additional SDP capabilities. In >>>>> particular, this memo provides a mechanism to negotiate >>> bandwidth >>>>> ('b=' line), connection data ('c=' line), and titles >>>> ('i=' line for >>>>> each session or media). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >>>>> neous-caps >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella >>>>> neous-caps-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > --------------020602060207060702050803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html). The -01 version that was WGLC'ed stated the following:
<quote>
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.
</quote

and there is what the current -04 states:
<quote>
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).
</quote>

The only difference is the addition of clarifying examples and hence there is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html). To recap, the draft specifically does not define port negotiation (but simply reuses the current port in accordance with general capability negotiation operation). Since this doesn't work when changing between IN and PSTN, exception text to use port 9 for PSTN was added (again in accordance with previous discussion). One comment was received, which was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems, but essentially amount to word-smithing requests. As a Working Group chair, I am unsympathetic to such requests on a document that is this far along and furthermore has external dependencies. We go through a WGLC process for a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course reasonable. With that in mind, if anybody still has comments on the -04 version, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:
I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the <nettype> "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improvement):

In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the <nettype> "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:


The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that proprietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).


Regards
Thomas


-----Ursprüngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas


-----Ursprüngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. März 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med



-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoyé : mercredi 13 mars 2013 16:09
À : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=ccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate

transport protocols

 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation

is embedded

 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation

framework to allow

 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate

bandwidth

 ('b=' line), connection data ('c=' line), and titles

('i=' line for

 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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


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



        

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


      

      
--
Jonathan Lennox
jonathan@vidyo.com


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



    

    

  


--------------020602060207060702050803--

From randy@qti.qualcomm.com  Thu Mar 14 07:41:45 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C96D11E8199 for ; Thu, 14 Mar 2013 07:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.603
X-Spam-Level: 
X-Spam-Status: No, score=-104.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, 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 zi6h0ovesS1S for ; Thu, 14 Mar 2013 07:41:43 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3911E8175 for ; Thu, 14 Mar 2013 07:41:43 -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=1363272103; x=1394808103; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=Ll+2Phker5gUZGoq2FfaiYiOuP181uus2eahhpzCtw4=; b=QaGB2x7mZwOaPSXY5SaRW1tL9aRvxHYUBgavb9sHVRQHN3zlkrkaqt7t cUptJyx6uDgHX6gCLdAq57ZwfXRcOHo4obwN1NglZuu4kb825z8NLP6jg aGFVk3+oQuv7czMcQ1i+BKVIPKYMzqEvKPQ+kDI/eQTENHaupfXnDlTb4 c=;
X-IronPort-AV: E=Sophos;i="4.84,845,1355126400"; d="scan'208";a="29436553"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 14 Mar 2013 07:41:43 -0700
X-IronPort-AV: E=Sophos;i="4.84,845,1355126400"; d="scan'208";a="505098478"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Mar 2013 07:41:43 -0700
Received: from dhcp-42ec.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Mar 2013 07:41:41 -0700
Message-ID: 
In-Reply-To: <5141D725.3030706@cisco.com>
References:  <513E504F.1010209@omnitor.se> <5141D725.3030706@cisco.com>
X-Mailer: Eudora for Mac OS X
Date: Thu, 14 Mar 2013 07:41:37 -0700
To: Flemming Andreasen , Gunnar Hellstrom 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-gellens-negotiating-human-language-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 14:41:45 -0000

At 9:56 AM -0400 3/14/13, Flemming Andreasen wrote:

>  On 3/11/13 5:44 PM, Gunnar Hellstrom wrote:
>
>>  Before this discussion got its home in mmusic,=20
>> we discussed quite similar topics as you, Dale=20
>> brought up now.
>>
>>  It was about what was needed to be expressed=20
>> by the parameters and if SDP or SIP was the=20
>> right place. And in the case of SIP, if RFC=20
>> 3840 / 3841 could be a suitable mechanism for=20
>> routing and decisions on the parameters.
>>
>  I agree more discussion is needed on this.=20
> There seems to be two problems considered in=20
> the draft:
>  1) Routing of a request to an answerer that has=20
> the language capabilities the caller desires.
>  2) Negotiation of the language properties to=20
> use on a per-stream basis once the call has=20
> been routed to a particular answerer.
>
>  Problem 1 seems to fall in the RFC 3840/3841=20
> space, whereas problem 2 is more of an SDP=20
> issue.
>
>  -- Flemming

Language and media both need to be considered=20
together when choosing how to process the call.=20
=46or example, a call with a request for video with=20
ASL, or text in English, may be handled=20
differently than a call that requests only voice=20
with English.


>>  Here is part of that discussion that we need to capture.
>>
>>
>>  I see some complication that might be needed=20
>> in order to reflect reality. At least they=20
>> should be discussed.
>>
>>  And I am also seeing some different ways to specify it.
>>
>>  The complications to discuss are:
>>
>>  1. Level of preference.
>>
>>  There may be a need for specifying levels of=20
>> preference for languages.  I might strongly=20
>> prefer to talk English, but have some useful=20
>> capability in French. I want to display that=20
>> preference and that capability with that=20
>> difference, so that I get English whenever=20
>> possible, but get the call connected even if=20
>> English is not available at all but French is.
>>
>>  I would assume that two levels are sufficient,=20
>> but that can be discussed:  Preferred and=20
>> capable.
>>
>>>
>>>  The draft already proposes that languages be=20
>>> listed in order of preference, which should=20
>>> handle the example you mention: you list=20
>>> English first and French second.  The called=20
>>> party selects English if it is capable and=20
>>> falls back to French if English is not and=20
>>> French is.  This seems much simpler and is a=20
>>> common way of handling situations where there=20
>>> is a preference.  It would be good to keep=20
>>> the mechanism as simple as possible.
>>>
>>>  Yes, I am afraid of complicating this beyond=20
>>> the point when users do not manage to get=20
>>> their settings right.
>>>
>>>  Still, I do not think that the order is=20
>>> sufficient as level of preference indicator.=20
>>> You may want to indicate capability for one=20
>>> modality but preference for another. ( as my=20
>>> example, capability for ASL, but preference=20
>>> for talking and reading )
>>>
>>
>>  If you have a capability for ASL but=20
>> preference for talking and reading, you could=20
>> initially offer two media streams: a voice=20
>> with English and a text with English.  If=20
>> accepted, you have your preferred=20
>> communications.  If those are rejected you=20
>> could then offer video with ASL.  Would that=20
>> handle the case?
>>  No, video is still very valuable for judging=20
>> the emergency case. Or seeing a friend. So, if=20
>> you support it you want to offer it. But the=20
>> decision on languages and modalities may end=20
>> up in video being not important for language=20
>> communication.
>>
>>>
>>>
>>>>>>  2. Directionality
>>>>>>  There is a need for a direction of the=20
>>>>>> language preference. "Transmit, receive or=20
>>>>>> both". or   "Produce, perceive or both".=20
>>>>>> That is easy to understand for the relay=20
>>>>>> service examples.
>>>>>>  A hard-of-hearing user may declare:
>>>>>>
>>>>>>  Text, capable, produce, English
>>>>>>  Text, prefer, perceive, English
>>>>>>  Audio, prefer, produce, English
>>>>>>  Audio, capable, perceive, English    (=20
>>>>>> tricky, a typical hard-of-hearing user may=20
>>>>>> have benefit of receiving audio, while it=20
>>>>>> is not usable enough for reliable=20
>>>>>> perception. I do not want to see this=20
>>>>>> eternally complex, but I see a need for=20
>>>>>> refined expressions here)
>>>>>>  video, capable, both, ASL 
>>>>>>
>>>>>>  This should be understood as that the user=20
>>>>>> prefers to speak and get text back, and=20
>>>>>> has benefit of getting voice in parallel=20
>>>>>> with text.  ASL signing can be an=20
>>>>>> alternative if the other party has=20
>>>>>> corresponding capability or preference.
>>>>>>
>>>>>>
>>>>>
>>>>>  The draft does support this (and even=20
>>>>> mentions some of these specific uses)=20
>>>>> because it proposes an SDP media attribute,=20
>>>>> and media can be specified to be send,=20
>>>>> receive, or both.
>>>>>
>>>>  No, that is not the same. You want the media=20
>>>> to flow, but by the parameter you want to=20
>>>> indicate your preference for how to use it.=20
>>>> You do not want to turn off incoming audio=20
>>>> just because you prefer to talk but read=20
>>>> text.
>>>>
>>>
>>>  Yes, I see, thanks for the clarification.=20
>>> Does this need to be part of the session=20
>>> setup?  If you establish all media streams=20
>>> that you wish to use, can you then just use=20
>>> them as you prefer?  I will consult with the=20
>>> NENA accessibility committee on this.
>>>
>>  No, there are specific services providing=20
>> service with one direction but not the other.=20
>> The information is needed for decision on what=20
>> assisting service to invoke. One such service=20
>> is the captioned telephony, that adds rapidly=20
>> created speech-to-text in parallel with the=20
>> voice. They provide just that. A user will=20
>> have a very strong preference for getting just=20
>> that service, but could accept with much lower=20
>> preference to get a direct conversation with=20
>> the far end in combined text and voice.
>>
>>>
>>>
>>>>>>  I think it would be useful  to move most=20
>>>>>> of the introduction to a structured use=20
>>>>>> case chapter and express the different=20
>>>>>> cases according to a template. Thast can=20
>>>>>> then be used to test if proposed=20
>>>>>> approaches will work.
>>>>>>
>>>>>
>>>>>  I'm not sure I fully understand what you=20
>>>>> mean by "structured" in "structured use=20
>>>>> case" or "template."  Can you be more=20
>>>>> specific?
>>>>>
>>>>  I mean just a simple template for how the=20
>>>> use case descriptions are written.
>>>>
>>>>  E.g.
>>>>  A title indicating what case we have.
>>>>  Description of the calling user and its capabilities and preferences.
>>>>  Description of the answering user and its capabilities and preferences
>>>>  Description of a possible assisting service=20
>>>> and its capabilities and preferences
>>>>  Description of the calling user's indications.
>>>>  Description of the answering user's indications.
>>>>  The resulting decision and outcome
>>>>
>>>>>
>>>>>
>>>>>>  3.  Specify language and modality at SIP Media tag level instead.
>>>>>>  There could be some benfits to declare=20
>>>>>> these parameters at the SIP media tag=20
>>>>>> level instead of SDP level.
>>>>>>  A call center can then register with their=20
>>>>>> capabilities already at the SIP REGISTER=20
>>>>>> time, and the caller preferences / callee=20
>>>>>> capabilities mechanism from RFC 3840/ 3841=20
>>>>>> can be used to select modalities and=20
>>>>>> languages and route the call to the best=20
>>>>>> capable person or combination of person=20
>>>>>> and assisting interpreting.
>>>>>>
>>>>>
>>>>>  Maybe, but one advantage of using SDP is=20
>>>>> that the ESInet can take language and media=20
>>>>> needs into account during policy-based=20
>>>>> routing.  For example, in some European=20
>>>>> countries emergency calls placed by a=20
>>>>> speaker of language x in country y may be=20
>>>>> routed to a PSAP in a country where x is=20
>>>>> the native language.  Or, there might be=20
>>>>> regional or national text relay or sign=20
>>>>> language interpreter services as opposed to=20
>>>>> PSAP-level capabilities.
>>>>>
>>>>  Is there a complete specification for how=20
>>>> policy based routing is thought to work?=20
>>>> Where?
>>>>  Does it not use RFC 3840/3841?
>>>>  That procedure is already supported by SIP=20
>>>> servers. Using SDP requires new SIP server=20
>>>> programming.
>>>>
>>>
>>>  NENA has a document under development.  I=20
>>> thought it was able to take SDP into account=20
>>> but I'll look into it, and I'm sure Brian=20
>>> will have something to say.
>>>
>>  Yes, I think I have seen that. But it needs to=20
>> come into IETF to be possible to refer to.
>>
>>>
>>>
>>>>>>  But, on the other hand, then we need a=20
>>>>>> separate specification of what modality=20
>>>>>> the parameters indicate, because the=20
>>>>>> language tags only distinguish between=20
>>>>>> signed and other languages, and "other"=20
>>>>>> seems to mean either spoken or written=20
>>>>>> without any difference.
>>>>>>
>>>>>>
>>>>>
>>>>>  The SDP media already indicates the type (audio, video, text).
>>>>>
>>>>  Yes, convenient. But there is no knowledge=20
>>>> about the parameters until at call time. It=20
>>>> could be better to know the callee=20
>>>> capabilities in advance if available. Then=20
>>>> middle boxes can do the routing instead of=20
>>>> the far end. There may be many terminals=20
>>>> competing for the call and the comparison=20
>>>> about who to get it should be done by a sip=20
>>>> server instead of an endpoint.
>>>>
>>>
>>>  I think call time is the right time.  For=20
>>> emergency calls, it isolates the decision=20
>>> making about how to process calls requiring=20
>>> text, sign language, foreign language, etc.=20
>>> to the ESInet and PSAPs, which is I think the=20
>>> right place.  The processing rules in the=20
>>> ESInet can then be changed without involving=20
>>> any carrier.  The capabilities of an entity=20
>>> may vary based on dynamic factors (time of=20
>>> day, load, etc.) so the decision as to how to=20
>>> support a need may be best made by the ESInet=20
>>> or PSAP in the case of an emergency call, or=20
>>> called party for non-emergency calls.  For=20
>>> example, at some times or under some loads,=20
>>> emergency calls may be routed to a specific=20
>>> PSAP that is not the geographically indicated=20
>>> one.  Likewise, a non-emergency call to a=20
>>> call center may be routed to a center in a=20
>>> country that has support for the language or=20
>>> media needed.
>>>
>>  The decision is of course made at call time.=20
>> With the RFC 3840/3841 method, the different=20
>> agents and services available register their=20
>> availability and capabilities when they go on=20
>> duty, and unregister when they stop, so that=20
>> their information is available at call time.
>>
>>
>>>
>>>  Further, it is often the case that the cost=20
>>> of relay, interpretation, or translation=20
>>> services is affected by which entity invokes=20
>>> the service.
>>>
>>  Yes, that is a complicating policy issue.
>>
>>>
>>>
>>>>>>  4. Problem that 3GPP specifies that it is=20
>>>>>> the UAs only who specify and act on these=20
>>>>>> parameters.
>>>>>>  I think it is a problem that 3GPP inserted=20
>>>>>> the restriction that the language and=20
>>>>>> modality negotiation shall only bother the=20
>>>>>> involved UAs.
>>>>>>  It would be more natural that it is a=20
>>>>>> service provider between them who detect=20
>>>>>> the differences and make the decision to=20
>>>>>> invoke a relay service for the relay case.
>>>>>>  How do you propose to solve that? Let the=20
>>>>>> service provider behave as a B2BUA, who=20
>>>>>> then can behave as both a UA and a service=20
>>>>>> provider?
>>>>>>
>>>>>
>>>>>  What do you mean by "service provider?"  In=20
>>>>> the case of a voice service provider such=20
>>>>> as a cellular carrier or a VoIP provider, I=20
>>>>> think this should be entirely transparent.=20
>>>>> The voice service provider knows it is an=20
>>>>> emergency call and routes to an ESInet.  It=20
>>>>> is then up to the ESInet and the PSAPs to=20
>>>>> handle the call as they wish.
>>>>>
>>>>  It can be a service provider for just the=20
>>>> function to make advanced call invocation=20
>>>> based on language preferences. The same type=20
>>>> of decisions, call connections and assisting=20
>>>> service invocation are needed in everyday=20
>>>> calls as in emergency calls. But it can also=20
>>>> be a service provider for emergency services=20
>>>> and the user is registered by that service=20
>>>> provider. They can make decisions on the=20
>>>> call. E.g. detect that it is an emergency=20
>>>> call requiring interpreter, and therefore=20
>>>> connect to both the PSAP and interpreter at=20
>>>> the same time to save time.
>>>>
>>>
>>>  I think it's best to make these decisions at=20
>>> the end, not the middle.  In the case of=20
>>> emergency calls, the ESInet can route to a=20
>>> particular PSAP, the PSAP may bridge in=20
>>> translation or interpretation services, etc.=20
>>> In the case of non-emergency calls, the call=20
>>> center may support some capabilities locally=20
>>> at some hours but route to a different call=20
>>> center at other times.
>>>
>>  The end is not decided until you have=20
>> evaluated the alternative possible ends and=20
>> decided who has the right capability and=20
>> preference.
>>
>>
>>
>>  There is another issue with using sdp for=20
>> decisions. SIP Message is included in the set=20
>> of methods to handle in emergency calls in RFC=20
>> 6443. It can be used within sessions to carry=20
>> text messages if other media are used as well.=20
>> It is no favored way to have text=20
>> communication, but possible. SIP message has=20
>> no sdp.  I know that the 3GPP sections  about=20
>> emergency calling in TS 22.101 points towards=20
>> using MSRP for text messaging, so it should=20
>> not be an issue for 3GPP. Can we neglect SIP=20
>> Message from the discussion and aim at solving=20
>> it only for real-time conversational media?  I=20
>> do not urge for solving it for SIP Message, I=20
>> just wanted to point out that result by basing=20
>> the mechanism on SDP.
>>
>>
>>
>>
>>
>>
>>  Will there be a possibility for remote=20
>> participation on Thursday. I am sorry I am not=20
>> there, but would like to participate if=20
>> possible.
>>  /Gunnar
>>
>>
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46708204288
>>
>>  On 2013-03-11 16:57, Randall Gellens wrote:
>>
>>>  [[[ resending without Cc list ]]]
>>>
>>>  Hi Dale,
>>>
>>>  At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:
>>>
>>>>   (It's not clear to me what the proper mailing list is to discuss this
>>>>   draft.  From the headers of the messages, it appears that the primary
>>>>   list is=20
>>>> ietf@ietf.org, but the=20
>>>> first message in this thread about that
>>>>   draft already has a "Re:" in the subject line, so the discussion
>>>>   started somewhere else.)
>>>>
>>>
>>>  There has been some discussion among those=20
>>> listed in the CC header of this message.  I=20
>>> think the mmusic list is probably the right=20
>>> place to continue the discussion and was=20
>>> planning on doing so more formally with the=20
>>> next revision of the draft.
>>>
>>>  By the way, the draft was updated and is now=20
>>> at -02:=20
>>> http://www.ietf.org/internet-drafts/draft-gellens-negotiating-h=
uman-language-02.txt
>>>
>>>  There is a face-to-face discussion Thursday=20
>>> 11:30-1:00 at The Tropicale (the cafe in the=20
>>> Caribe Royal).  Please let me know if you can=20
>>> make it.
>>>
>>>>   (Also, it's not clear why Randall's messages are coming through in
>>>>   HTML.)
>>>>
>>>
>>>  My apologies; I have gotten in the habit when=20
>>> replying to messages that have style to allow=20
>>> Eudora to send my reply styled as well.
>>>
>>>>   But onward to questions of substance:
>>>>
>>>>   - Why SDP and not SIP?
>>>>
>>>>   I'd like to see a more thorough exploration of why language
>>>>   negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP=
,
>>>>   uses the Content-Language header to specify languages.)  In principle=
,
>>>>   specifying data that may be used in call-routing should be done in th=
e
>>>>   SIP layer, but it's well-accepted in the SIP world that call routing
>>>>   may be affected by the SDP content as well (e.g., media types).
>>>>
>>>
>>>  I think it fits more naturally in SDP since=20
>>> the language is related to the media, e.g.,=20
>>> English for audio and ASL for video.
>>>
>>>>   And some discussion and comparison should be done with the SIP/HTTP
>>>>   Content-Language header (used to specify the language of the
>>>>   communications) and the SIP Accept-Language header (used to specify
>>>>   the language of text components of SIP messages), particularly given
>>>>   that Accept-Language has different set of language specifiers and a
>>>>   richer syntax for specifying preferences.  In any case, preference
>>>>   should be given to reusing one of the existing syntaxes for specifyin=
g
>>>>   language preferences.
>>>>
>>>
>>>  I think the semantics of Content-Language and=20
>>> Accept-Language are different from the=20
>>> semantics here, especially when setting up a=20
>>> session with, as an example, an audio stream=20
>>> using English and a video stream using ASL.=20
>>> (But I can see clients using a default value=20
>>> to set both the SDP language attribute and=20
>>> the HTTP Content-Language, unless configured=20
>>> differently.)
>>>
>>>  As for reusing existing mechanisms, the draft=20
>>> does contain two alternative proposals, one=20
>>> to re-use the existing 'language' SDP=20
>>> attribute, and one to define a new attribute.
>>>
>>>>   - Dependency between media descriptions?
>>>>
>>>>      Another example would be a user who is able to speak but is deaf o=
r
>>>>      hard-of-hearing and requires a voice stream plus a text stream
>>>>      (known as voice carry over).  Making language a media attribute
>>>>      allows the standard session negotiation mechanism to handle this b=
y
>>>>      providing the information and mechanism for the endpoints to make
>>>>      appropriate decisions.
>>>>
>>>>   This scenario suggests that there might be dependency or interaction
>>>>   between language specifications for different media descriptions.
>>>>   Whether this is needed should be determined and documented.
>>>>
>>>>   - Specifying preference levels?
>>>>
>>>>      For example, some users may be able to speak several languages, bu=
t
>>>>      have a preference.
>>>>
>>>>   This might argue for describing degrees of preference using "q"
>>>>   parameters (as in the SIP Accept-Language header).
>>>>
>>>>   - Expressing multiple languages in answers
>>>>
>>>>      (While it is true that a conversation among multilingual people
>>>>      often involves multiple languages, it does not seem useful enough
>>>>      as a general facility to warrant complicating the desired semantic=
s
>>>>      of the SDP attribute to allow negotiation of multiple simultaneous
>>>>      languages within an interactive media stream.)
>>>>
>>>>   Why shouldn't an answer be able to indicate multiple languages?  At
>>>>   the least, this might provide the offerer with useful information.
>>>>
>>>
>>>  You raise good questions that I think need=20
>>> more discussion.  I am hoping to keep the=20
>>> work as simple as possible and not add=20
>>> additional complexity, which argues for not=20
>>> solving every aspect of the problem, but only=20
>>> those that must be solved immediately.
>>>
>>>>
>>>>   - Reusing a=3Dlang
>>>>
>>>>   Searching, I can only find these descriptions of the use of
>>>>   "a=3Dlang:...":
>>>>
>>>>       RFC 4566
>>>>       draft-saintandre-sip-xmpp-chat
>>>>       draft-gellens-negotiating-human-language
>>>>
>>>>   So it looks like "a=3Dlang:..." is entirely unused at the present and=
 is
>>>>   safe to be redefined.
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>  _______________________________________________
>>  mmusic mailing list
>>  mmusic@ietf.org
>>=20
>> https://www.ietf.org/mailma=
n/listinfo/mmusic
>>
>
>
>  _______________________________________________
>  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: ---------------
A diva who specializes in risque arias is an off-coloratura soprano...

From mohamed.boucadair@orange.com  Thu Mar 14 08:19:59 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAAE11E823C for ; Thu, 14 Mar 2013 08:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=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 jtBItt6P1nhB for ; Thu, 14 Mar 2013 08:19:57 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 899D211E822A for ; Thu, 14 Mar 2013 08:19:56 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8E5022DC1A1; Thu, 14 Mar 2013 16:19:55 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3DF4B238071; Thu, 14 Mar 2013 16:19:55 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 14 Mar 2013 16:19:55 +0100
From: 
To: Flemming Andreasen , Jonathan Lennox 
Date: Thu, 14 Mar 2013 16:19:53 +0100
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4gwQ3kL3UTcqSGTEaMgAnSjUyfvgABUK7A
Message-ID: <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr>
References:   <5141DFF8.4050006@cisco.com>
In-Reply-To: <5141DFF8.4050006@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB7356863PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 15:19:59 -0000

--_000_94C682931C08B048B7A8645303FDC9F36EB7356863PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Flemming,

Apologies for not sending my comment earlier. I should read the draft befor=
e but I didn't read it since a while.

It is unfair to ignore the messages exchanged in this thread which say the =
text is confusing and it should be worked better. The wording proposed by J=
onathan is much better.

Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 15:35
=C0 : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the=
 draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).=
 The -01 version that was WGLC'ed stated the following:


The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.



The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).



The only difference is the addition of clarifying examples and hence there =
is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port iss=
ue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mm=
usic/current/msg10160.html). To recap, the draft specifically does not defi=
ne port negotiation (but simply reuses the current port in accordance with =
general capability negotiation operation). Since this doesn't work when cha=
nging between IN and PSTN, exception text to use port 9 for PSTN was added =
(again in accordance with previous discussion). One comment was received, w=
hich was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems,=
 but essentially amount to word-smithing requests. As a Working Group chair=
, I am unsympathetic to such requests on a document that is this far along =
and furthermore has external dependencies. We go through a WGLC process for=
 a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course=
 reasonable. With that in mind, if anybody still has comments on the -04 ve=
rsion, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:

I suggest being more concrete about ccap's restrictions, that it can't be u=
sed to negotiate alternative IP addresses.  We can then discuss only ICE, w=
ithout precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
 "IN" (i.e., multiple Internet protocol addresses) in the same med=
ia stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be u=
sed to allow a choice among multiple Internet addresses.  The use of ICE wi=
th capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the  "IN"); otherwi=
se, under the rules of ICE, an ICE mismatch will result.  However, this ICE=
 mismatch will in fact induce the desired behavior, causing the answerer to=
 abort ICE processing and use the connection address; so this ICE mismatch =
is harmless, other than the inclusion of an "ice-mismatch" attribute in the=
 SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



The text in the draft was worked out with Jonathan Lennox who raised the in=
itial concen about conflict with ICE. If Jonathan is ok with the revised pr=
oposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic=
@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


transport protocols


 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


is embedded


 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


framework to allow


 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


bandwidth


 ('b=3D' line), connection data ('c=3D' line), and titles


('i=3D' line for


 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



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



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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--
Jonathan Lennox
jonathan@vidyo.com


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




--_000_94C682931C08B048B7A8645303FDC9F36EB7356863PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Dear Flemming,


 




Apologies for not sending my comment earlier.=
 I should=20
read the draft before but I didn't read it since a=20
while.


 


It is unfair to ignore the messages exchanged=
 in this=20
thread which say the text is confusing and it should be worked better.=20
The wording proposed by Jonathan is much better.=20



 


Cheers,


Med



  

  

  De : Flemming Andreasen=20
  [mailto:fandreas@cisco.com] 
Envoy=E9 : jeudi 14 mars 2013=
=20
  15:35
=C0 : Jonathan Lennox; BOUCADAIR Mohamed=20
  OLNC/OLN
Cc : Andrew Allen;=20
  mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action:=20
  draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


  
A couple of points here related to the overall thread:

=
1)=20
  WGLC for this draft completed about 6 months ago with no comments on the =
draft=20
  (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).=20
  The -01 version that was WGLC'ed stated the following:
<quote>
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.
</quote

and there is what the current -04=20
  states:
<quote>
The 'ccap' capability attribute is =
intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).
</quo=
te>

The=20
  only difference is the addition of clarifying examples and hence there is=
 no=20
  change in operation here. 

2) On January 25, Simo sent an e-mail t=
o the=20
  list pointing out the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).=20
  To recap, the draft specifically does not define port negotiation (but si=
mply=20
  reuses the current port in accordance with general capability negotiation=
=20
  operation). Since this doesn't work when changing between IN and PSTN,=20
  exception text to use port 9 for PSTN was added (again in accordance with=
=20
  previous discussion). One comment was received, which was in favor of the=
=20
  proposal. 


The comments brought up now are not identifying any=
 new=20
  or severe problems, but essentially amount to word-smithing requests. As =
a=20
  Working Group chair, I am unsympathetic to such requests on a document th=
at is=20
  this far along and furthermore has external dependencies. We go through a=
 WGLC=20
  process for a reason, and people need to review and make their comments a=
t=20
  that time. 

Comments on new text or changes made since the WGLC=20
  completed are of course reasonable. With that in mind, if anybody still h=
as=20
  comments on the -04 version, please let us know. 

Thanks 

-=
-=20
  Flemming (MMUSIC co-chair)





  
On 3/14/13 9:04 AM, Jonathan Lennox=20
wrote:

  
I suggest being more concrete about ccap's r=
estrictions, that it can't be used to negotiate alternative IP addresses.  =
We can then discuss only ICE, without precluding altc for the proprietary s=
ystems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
<nettype> "IN" (i.e., multiple Internet protocol addresses) in the sa=
me media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] ca=
n be used to allow a choice among multiple Internet addresses.  The use of =
ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the <nettype> "IN"); o=
therwise, under the rules of ICE, an ICE mismatch will result.  However, th=
is ICE mismatch will in fact induce the desired behavior, causing the answe=
rer to abort ICE processing and use the connection address; so this ICE mis=
match is harmless, other than the inclusion of an "ice-mismatch" attribute =
in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



    
The text in the draft was work=
ed out with Jonathan Lennox who raised the initial concen about conflict wi=
th ICE. If Jonathan is ok with the revised proposal from Thomas then I am O=
K with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@o=
range.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolain=
en@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@i=
etf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterp=
rise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@o=
range.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>=
; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>=
;; =
mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ie=
tf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



      
-----Urspr=FCngliche Nachric=
ht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@=
ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



        
-----Urspr=FCngliche Nachr=
icht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




          
-----Message d'origine--=
---
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : m=
music@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmu=
sic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate

transport protocols


          
 and attributes.  This f=
ramework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation

is embedded


          
 into the widely-used SD=
P offer/answer procedures.

 This memo extends the SDP capability negotiation

framework to allow


          
 endpoints to negotiate =
three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate

bandwidth


        

          
 ('b=3D' line), connecti=
on data ('c=3D' line), and titles

('i=3D' line for


          
 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-=
mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf=
-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft=
-ietf-mmusic-sdp-miscella
neous-caps-04


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

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


_________________________________________=
______
mmusic mailing list
mmusic@=
ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______=
________________________________________
mmusic mailing list
mmusic@=
ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--
Jonathan Lennox
jona=
than@vidyo.com


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





--_000_94C682931C08B048B7A8645303FDC9F36EB7356863PUEXCB1Bnante_--

From fandreas@cisco.com  Thu Mar 14 08:23:10 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2050811E82AA for ; Thu, 14 Mar 2013 08:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.114
X-Spam-Level: 
X-Spam-Status: No, score=-9.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 sfHx9UpnDq95 for ; Thu, 14 Mar 2013 08:23:06 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE311E823C for ; Thu, 14 Mar 2013 08:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47079; q=dns/txt; s=iport; t=1363274586; x=1364484186; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bvPaGzD0oUy9x4uSw5MzFxMOB1BKPqJuHzUlxJRRst8=; b=EkCfLF4zzeCJ96H33At227XSExPtCTP18EL1aBtnpp8NSHcxuDKNk8NB ElLZmQ7HbtECy3aVUdMI7HsEbZn8lFX1zfFLD1gBXlBwXYz9bXbnTefz4 soW2ZCXCM6PLH45XADIAybxWBlzuTRYXCeLSlYPtwryKMMgPaElaUvEux I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoAJAF7qQVGrRDoG/2dsb2JhbABDhVC/IwQBgWIWdIIqAQEBAwEBAQEXAVMEBgEFBwQLEQQBAQEJFgEBBgcJAwIBAgEVHwkIEwEFAgEBBRKHcwUIBcE0jV8rdAcBCgYBBoM6A5ZYgR+PY4MmIIE3
X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208,217";a="72904210"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2013 15:23:05 +0000
Received: from dhcp-170e.meeting.ietf.org ([10.86.246.161]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EFN3B6021337; Thu, 14 Mar 2013 15:23:03 GMT
Message-ID: <5141EB56.9090103@cisco.com>
Date: Thu, 14 Mar 2013 11:23:02 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------080201090504040807070805"
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 15:23:10 -0000

This is a multi-part message in MIME format.
--------------080201090504040807070805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
> Dear Flemming,
> Apologies for not sending my comment earlier. I should read the draft 
> before but I didn't read it since a while.
> It is unfair to ignore the messages exchanged in this thread which say 
> the text is confusing and it should be worked better. The wording 
> proposed by Jonathan is much better.
>
I respectfully disagree. What is unfair is that people do not read 
documents when they are WGLC'ed but still expect their comments to be 
addressed ~6 months later.

As to the message below be specific please; exactly what is it that is 
unclear in the text below ?

Thanks

-- Flemming


> Cheers,
> Med
>
>     ------------------------------------------------------------------------
>     *De :* Flemming Andreasen [mailto:fandreas@cisco.com]
>     *Envoyé :* jeudi 14 mars 2013 15:35
>     *À :* Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
>     *Cc :* Andrew Allen; mmusic@ietf.org
>     *Objet :* Re: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>     A couple of points here related to the overall thread:
>
>     1) WGLC for this draft completed about 6 months ago with no
>     comments on the draft
>     (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).
>     The -01 version that was WGLC'ed stated the following:
>     
>
>     The 'ccap' capability attribute is intended to
>         be used only when there is no other mechanism available for
>         negotiating alternative connection address information, such as when
>         the  is different among the alternative addresses.  The
>         'ccap' attribute MUST NOT be used in situations where an existing
>         mechanism (such as Interactive Connectivity Establishment (ICE)
>         [RFC5245]) can be used to select between different connection
>         addresses.
>
>     
>     and there is what the current -04 states:
>     
>
>     The 'ccap' capability attribute is intended to
>         be used only when there is no other mechanism available for
>         negotiating alternative connection address information, such as when
>         the  is different among the alternative addresses (e.g.
>         "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>         situations where an existing mechanism (such as Interactive
>         Connectivity Establishment (ICE) [RFC5245]) can be used to select
>         between different connection addresses (e.g.  "IP4" and "IP6" or
>         different IP addresses within the same IP address family).
>
>     
>
>     The only difference is the addition of clarifying examples and
>     hence there is no change in operation here.
>
>     2) On January 25, Simo sent an e-mail to the list pointing out the
>     port issue and suggesting text to be added
>     (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).
>     To recap, the draft specifically does not define port negotiation
>     (but simply reuses the current port in accordance with general
>     capability negotiation operation). Since this doesn't work when
>     changing between IN and PSTN, exception text to use port 9 for
>     PSTN was added (again in accordance with previous discussion). One
>     comment was received, which was in favor of the proposal.
>
>
>     The comments brought up now are not identifying any new or severe
>     problems, but essentially amount to word-smithing requests. As a
>     Working Group chair, I am unsympathetic to such requests on a
>     document that is this far along and furthermore has external
>     dependencies. We go through a WGLC process for a reason, and
>     people need to review and make their comments at that time.
>
>     Comments on new text or changes made since the WGLC completed are
>     of course reasonable. With that in mind, if anybody still has
>     comments on the -04 version, please let us know.
>
>     Thanks
>
>     -- Flemming (MMUSIC co-chair)
>
>
>
>
>     On 3/14/13 9:04 AM, Jonathan Lennox wrote:
>>     I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.
>>
>>     Thus, I suggest something like this (wordsmithing requested):
>>
>>     The 'ccap' attribute MUST NOT be used to offer multiple addresses with the  "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].
>>
>>
>>     This text might also be useful (though it definitely needs editorial improvement):
>>
>>     In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the  "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.
>>
>>
>>     On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:
>>
>>>     The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.
>>>
>>>     Andrew
>>>
>>>     ----- Original Message -----
>>>     From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>     Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
>>>     To: Andrew Allen;thomas.stach@siemens-enterprise.com  ;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>     Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>
>>>     Hi Andrew,
>>>
>>>     This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.
>>>
>>>     If it is not allowed, then the text should be clear.
>>>
>>>     Cheers,
>>>     Med
>>>
>>>     ________________________________________
>>>     De : Andrew Allen [aallen@blackberry.com]
>>>     Date d'envoi : mercredi 13 mars 2013 19:37
>>>     À : BOUCADAIR Mohamed OLNC/OLN;thomas.stach@siemens-enterprise.com;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>     Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>
>>>     The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.
>>>
>>>
>>>
>>>     ----- Original Message -----
>>>     From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>     Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
>>>     To: Stach, Thomas;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>     Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>
>>>     Re-,
>>>
>>>     The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.
>>>
>>>     In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.
>>>
>>>     The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.
>>>
>>>     Cheers,
>>>     Med
>>>
>>>     ________________________________________
>>>     De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>     Date d'envoi : mercredi 13 mars 2013 19:17
>>>     À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>     Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>
>>>     Mohammed,
>>>
>>>     I think it is not acceptable to mention altc in the example.
>>>     If I recollect correctly, the intention of the text is to specify that ICE MUST be
>>>     preferred over 'ccap' for IPv4/v6 address negotiation.
>>>
>>>     If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
>>>     I don't think that a standards track RFC should give the message that proprietary is preferred.
>>>     Based on this issue I think the current text in the draft does not work.
>>>     I would explicitly mention the relation of ICE and 'ccap'.
>>>     The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.
>>>
>>>     Thus I propose to rephrase to:
>>>
>>>     If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
>>>     the 'ccap' attribute it MUST use ICE to select between different connection addresses
>>>     (e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).
>>>
>>>
>>>     Regards
>>>     Thomas
>>>
>>>>     -----Ursprüngliche Nachricht-----
>>>>     Von:mohamed.boucadair@orange.com
>>>>     [mailto:mohamed.boucadair@orange.com]
>>>>     Gesendet: Mittwoch, 13. März 2013 13:40
>>>>     An: Stach, Thomas;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>     Betreff: RE : [MMUSIC] I-D Action:
>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>     Dear Thomas,
>>>>
>>>>     I'm not proposing to change the existing behavior; I'm just
>>>>     asking whether it is acceptable to add an additional example
>>>>     to the one already cited in the text.
>>>>     Wouldn't that be acceptable?
>>>>
>>>>     You can propose to add another example if you have any in mind.
>>>>
>>>>     Cheers,
>>>>     Med
>>>>
>>>>     ________________________________________
>>>>     De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>>     Date d'envoi : mercredi 13 mars 2013 17:57
>>>>     À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;
>>>>     mmusic@ietf.org
>>>>     Objet : AW: [MMUSIC] I-D Action:
>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>     Mohammed,
>>>>
>>>>     I think you have draft-boucadair-mmusic-altc in mind.
>>>>     This is an individual submission intended to document some
>>>>     proporietary mechanism.
>>>>     I don't think we should make restrictions in a standards
>>>>     track document in support of proprietary mechanisms.
>>>>     Otherwise I could also think of additional proprietary stuff
>>>>     that could be mentioned as well.
>>>>
>>>>
>>>>     Regards
>>>>     Thomas
>>>>
>>>>>     -----Ursprüngliche Nachricht-----
>>>>>     Von:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>     Im Auftrag vonmohamed.boucadair@orange.com
>>>>>     Gesendet: Mittwoch, 13. März 2013 11:20
>>>>>     An:Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>     Betreff: Re: [MMUSIC] I-D Action:
>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>     Hi Simo,
>>>>>
>>>>>     The document says:
>>>>>
>>>>>     The 'ccap' attribute MUST NOT be used in
>>>>>        situations where an existing mechanism (such as Interactive
>>>>>        Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>>>        between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>        different IP addresses within the same IP address family).
>>>>>
>>>>>     Would it be possible to change it to the following:
>>>>>
>>>>>     NEW:
>>>>>
>>>>>     The 'ccap' attribute MUST NOT be used in
>>>>>        situations where a mechanism (such as Interactive
>>>>>        Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
>>>>>     used to select
>>>>>        between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>        different IP addresses within the same IP address family).
>>>>>
>>>>>
>>>>>     Thanks.
>>>>>     Cheers,
>>>>>     Med
>>>>>
>>>>>
>>>>>>     -----Message d'origine-----
>>>>>>     De :mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>     De la part deSimo.Veikkolainen@nokia.com
>>>>>>     Envoyé : mercredi 13 mars 2013 16:09
>>>>>>     À :mmusic@ietf.org
>>>>>>     Objet : Re: [MMUSIC] I-D Action:
>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>
>>>>>>     Hello,
>>>>>>
>>>>>>     We just submitted a new version of the miscellaneous-caps
>>>>>>     draft, with text that states that if the connection data
>>>>>>     capability attribute (a=ccap) is used the port number in the
>>>>>>     resulting SDP MUST be the same as in the original "m=" line,
>>>>>>     except for PSTN type bearers (when the port number used is 9).
>>>>>>
>>>>>>     Regards,
>>>>>>     Simo
>>>>>>
>>>>>>     -----Original Message-----
>>>>>>     From:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>     On Behalf Of extinternet-drafts@ietf.org
>>>>>>     Sent: 13. maaliskuuta 2013 15:39
>>>>>>     To:i-d-announce@ietf.org
>>>>>>     Cc:mmusic@ietf.org
>>>>>>     Subject: [MMUSIC] I-D Action:
>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>
>>>>>>
>>>>>>     A New Internet-Draft is available from the on-line
>>>>>>     Internet-Drafts directories.
>>>>>>     This draft is a work item of the Multiparty Multimedia
>>>>>>     Session Control Working Group of the IETF.
>>>>>>
>>>>>>         Title           : Miscellaneous Capabilities
>>>>>>     Negotiation in the Session Description Protocol (SDP)
>>>>>>         Author(s)       : Miguel A. Garcia-Martin
>>>>>>                              Simo Veikkolainen
>>>>>>                              Robert R. Gilman
>>>>>>         Filename        :
>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>         Pages           : 21
>>>>>>         Date            : 2013-03-13
>>>>>>
>>>>>>     Abstract:
>>>>>>       SDP has been extended with a capability negotiation mechanism
>>>>>>       framework that allows the endpoints to negotiate
>>>>>     transport protocols
>>>>>>       and attributes.  This framework has been extended with a media
>>>>>>       capabilities negotiation mechanism that allows endpoints to
>>>>>>     negotiate
>>>>>>       additional media-related capabilities.  This negotiation
>>>>>     is embedded
>>>>>>       into the widely-used SDP offer/answer procedures.
>>>>>>
>>>>>>       This memo extends the SDP capability negotiation
>>>>>     framework to allow
>>>>>>       endpoints to negotiate three additional SDP capabilities.  In
>>>>>>       particular, this memo provides a mechanism to negotiate
>>>>     bandwidth
>>>>>>       ('b=' line), connection data ('c=' line), and titles
>>>>>     ('i=' line for
>>>>>>       each session or media).
>>>>>>
>>>>>>
>>>>>>     The IETF datatracker status page for this draft is:
>>>>>>     https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
>>>>>>     neous-caps
>>>>>>
>>>>>>     There's also a htmlized version available at:
>>>>>>     http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04
>>>>>>
>>>>>>     A diff from the previous version is available at:
>>>>>>     http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
>>>>>>     neous-caps-04
>>>>>>
>>>>>>
>>>>>>     Internet-Drafts are also available by anonymous FTP at:
>>>>>>     ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     mmusic mailing list
>>>>>>     mmusic@ietf.org
>>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>     _______________________________________________
>>>>>>     mmusic mailing list
>>>>>>     mmusic@ietf.org
>>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>     _______________________________________________
>>>>>     mmusic mailing list
>>>>>     mmusic@ietf.org
>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>     _______________________________________________
>>>     mmusic mailing list
>>>     mmusic@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>     ---------------------------------------------------------------------
>>>     This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>     ---------------------------------------------------------------------
>>>     This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>     --
>>     Jonathan Lennox
>>     jonathan@vidyo.com
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     .
>>
>


--------------080201090504040807070805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 3/14/13 11:19 AM,
      mohamed.boucadair@orange.com wrote:

    

    

      
      
      
Dear Flemming,

      
 

      

            
Apologies
                  for not sending my comment earlier. I should read the
                  draft before but I didn't read it since a while.

          

      
 

      
It is unfair to
            ignore the messages exchanged in this thread which say the
            text is confusing and it should be worked better. The wording proposed by Jonathan is much
            better. 

      
 

      

    

    I respectfully disagree. What is unfair is that people do not read
    documents when they are WGLC'ed but still expect their comments to
    be addressed ~6 months later. 

    

    As to the message below be specific please; exactly what is it that
    is unclear in the text below ? 

    

    Thanks 

    

    -- Flemming 

    

    

    

      
Cheers,

      
Med

      

      

        

          
 De :
            Flemming Andreasen [mailto:fandreas@cisco.com] 

            Envoyé : jeudi 14 mars 2013 15:35

            À : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN

            Cc : Andrew Allen; mmusic@ietf.org

            Objet : Re: [MMUSIC] RE : I-D Action:
            draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          

        

        A couple of points here related to the overall thread:

        

        1) WGLC for this draft completed about 6 months ago with no
        comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).
        The -01 version that was WGLC'ed stated the following:

        <quote>

        
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.

        </quote

        

        and there is what the current -04 states:

        <quote>

        
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).

        </quote>

        

        The only difference is the addition of clarifying examples and
        hence there is no change in operation here. 

        

        2) On January 25, Simo sent an e-mail to the list pointing out
        the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).
        To recap, the draft specifically does not define port
        negotiation (but simply reuses the current port in accordance
        with general capability negotiation operation). Since this
        doesn't work when changing between IN and PSTN, exception text
        to use port 9 for PSTN was added (again in accordance with
        previous discussion). One comment was received, which was in
        favor of the proposal. 

        

        

        The comments brought up now are not identifying any new or
        severe problems, but essentially amount to word-smithing
        requests. As a Working Group chair, I am unsympathetic to such
        requests on a document that is this far along and furthermore
        has external dependencies. We go through a WGLC process for a
        reason, and people need to review and make their comments at
        that time. 

        

        Comments on new text or changes made since the WGLC completed
        are of course reasonable. With that in mind, if anybody still
        has comments on the -04 version, please let us know. 

        

        Thanks 

        

        -- Flemming (MMUSIC co-chair)

        

        

        

        

        
On 3/14/13 9:04 AM, Jonathan Lennox
          wrote:

        

        

          
I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the <nettype> "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improvement):

In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the <nettype> "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



          

            
The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that proprietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).


Regards
Thomas



            

              
-----Ursprüngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



              

                
-----Ursprüngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. März 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




                

                  
-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoyé : mercredi 13 mars 2013 16:09
À : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=ccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


                

                
transport protocols


                

                  
 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


                

                
is embedded


                

                  
 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


                

                
framework to allow


                

                  
 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


                

              

              
bandwidth


              

                

                  
 ('b=' line), connection data ('c=' line), and titles


                

                
('i=' line for


                

                  
 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



                

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



              

            

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


          

          
--
Jonathan Lennox
jonathan@vidyo.com


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



        

        

      

    

    

  


--------------080201090504040807070805--

From jonathan@vidyo.com  Thu Mar 14 08:34:38 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22A11E821B for ; Thu, 14 Mar 2013 08:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.557
X-Spam-Level: 
X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=0.557,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001,  J_CHICKENPOX_42=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 hsEnJ8-Ajzb2 for ; Thu, 14 Mar 2013 08:34:36 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63011E8188 for ; Thu, 14 Mar 2013 08:34:35 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 09503557582; Thu, 14 Mar 2013 11:34:35 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 28034557067; Thu, 14 Mar 2013 11:33:57 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 14 Mar 2013 11:32:44 -0400
From: Jonathan Lennox 
To: Flemming Andreasen 
Date: Thu, 14 Mar 2013 11:33:18 -0400
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4gyT/HORByu2/ER/C+o/QjDN9kuw==
Message-ID: 
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com>
In-Reply-To: <5141EB56.9090103@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D70EBE0548B145DBA358FD8293479C72vidyocom_"
MIME-Version: 1.0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 15:34:38 -0000

--_000_D70EBE0548B145DBA358FD8293479C72vidyocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My apologies; I was responding to Andrew's request that I review the new te=
xt, and I'd lost track of where this draft was in the process.

I have no problem with the original text that was in the WGLC.  I believe t=
hat, as written, it doesn't preclude the use of altc.

On Mar 14, 2013, at 11:23 AM, Flemming Andreasen wrote:


On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
Dear Flemming,

Apologies for not sending my comment earlier. I should read the draft befor=
e but I didn't read it since a while.

It is unfair to ignore the messages exchanged in this thread which say the =
text is confusing and it should be worked better. The wording proposed by J=
onathan is much better.

I respectfully disagree. What is unfair is that people do not read document=
s when they are WGLC'ed but still expect their comments to be addressed ~6 =
months later.

As to the message below be specific please; exactly what is it that is uncl=
ear in the text below ?

Thanks

-- Flemming


Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 15:35
=C0 : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the=
 draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).=
 The -01 version that was WGLC'ed stated the following:


The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.



The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).



The only difference is the addition of clarifying examples and hence there =
is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port iss=
ue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mm=
usic/current/msg10160.html). To recap, the draft specifically does not defi=
ne port negotiation (but simply reuses the current port in accordance with =
general capability negotiation operation). Since this doesn't work when cha=
nging between IN and PSTN, exception text to use port 9 for PSTN was added =
(again in accordance with previous discussion). One comment was received, w=
hich was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems,=
 but essentially amount to word-smithing requests. As a Working Group chair=
, I am unsympathetic to such requests on a document that is this far along =
and furthermore has external dependencies. We go through a WGLC process for=
 a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course=
 reasonable. With that in mind, if anybody still has comments on the -04 ve=
rsion, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:

I suggest being more concrete about ccap's restrictions, that it can't be u=
sed to negotiate alternative IP addresses.  We can then discuss only ICE, w=
ithout precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
 "IN" (i.e., multiple Internet protocol addresses) in the same med=
ia stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be u=
sed to allow a choice among multiple Internet addresses.  The use of ICE wi=
th capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the  "IN"); otherwi=
se, under the rules of ICE, an ICE mismatch will result.  However, this ICE=
 mismatch will in fact induce the desired behavior, causing the answerer to=
 abort ICE processing and use the connection address; so this ICE mismatch =
is harmless, other than the inclusion of an "ice-mismatch" attribute in the=
 SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



The text in the draft was worked out with Jonathan Lennox who raised the in=
itial concen about conflict with ICE. If Jonathan is ok with the revised pr=
oposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic=
@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


transport protocols


 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


is embedded


 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


framework to allow


 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


bandwidth


 ('b=3D' line), connection data ('c=3D' line), and titles


('i=3D' line for


 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



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



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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--
Jonathan Lennox
jonathan@vidyo.com


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





--
Jonathan Lennox
jonathan@vidyo.com



--_000_D70EBE0548B145DBA358FD8293479C72vidyocom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


My apologies; I was r=
esponding to Andrew's request that I review the new text, and I'd lost trac=
k of where this draft was in the process.

I have n=
o problem with the original text that was in the WGLC.  I believe that=
, as written, it doesn't preclude the use of altc.

On Ma=
r 14, 2013, at 11:23 AM, Flemming Andreasen wrote:


 =20
   =20
 =20
  

    

    
On 3/14/13 11:19 AM,
      mohamed.boucadair@orange.com wrote:

    

    

     =20
     =20
      
Dear Flemming,=


      
 

      

            
Apologies
                  for not sending my comment earlier. I should read the
                  draft before but I didn't read it since a while.

          

      
 

      
It is unfair to
            ignore the messages exchanged in this thread which say the
            text is confusing and it should be worked better. The wording proposed by Jonathan is much
            better. 

      
 

      

    

    I respectfully disagree. What is unfair is that people do not read
    documents when they are WGLC'ed but still expect their comments to
    be addressed ~6 months later. 

    

    As to the message below be specific please; exactly what is it that
    is unclear in the text below ? 

    

    Thanks 

    

    -- Flemming 

    

    

    

      
Cheers,=


      
Med
      

      

        

          
 De =
:
            Flemming Andreasen [mailto:fandreas@cisco.com] 

            Envoy=E9 : jeudi 14 mars 2013 15:35

            =C0 : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
            Cc : Andrew Allen; mmusic@ietf.org

            Objet : Re: [MMUSIC] RE : I-D Action:
            draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          

        

        A couple of points here related to the overall thread:

        

        1) WGLC for this draft completed about 6 months ago with no
        comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg0959=
4.html).
        The -01 version that was WGLC'ed stated the following:

        <quote>

        
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.

        </quote

        

        and there is what the current -04 states:

        <quote>

        
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).

        </quote>

        

        The only difference is the addition of clarifying examples and
        hence there is no change in operation here. 

        

        2) On January 25, Simo sent an e-mail to the list pointing out
        the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/=
web/mmusic/current/msg10160.html).
        To recap, the draft specifically does not define port
        negotiation (but simply reuses the current port in accordance
        with general capability negotiation operation). Since this
        doesn't work when changing between IN and PSTN, exception text
        to use port 9 for PSTN was added (again in accordance with
        previous discussion). One comment was received, which was in
        favor of the proposal. 

        

        

        The comments brought up now are not identifying any new or
        severe problems, but essentially amount to word-smithing
        requests. As a Working Group chair, I am unsympathetic to such
        requests on a document that is this far along and furthermore
        has external dependencies. We go through a WGLC process for a
        reason, and people need to review and make their comments at
        that time. 

        

        Comments on new text or changes made since the WGLC completed
        are of course reasonable. With that in mind, if anybody still
        has comments on the -04 version, please let us know. 

        

        Thanks 

        

        -- Flemming (MMUSIC co-chair)

        

        

        

        

        
On 3/14/13 9:04 AM, Jonathan Lennox
          wrote:

        

        

          
I suggest being more concrete about ccap's restric=
tions, that it can't be used to negotiate alternative IP addresses.  We can=
 then discuss only ICE, without precluding altc for the proprietary systems=
 which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
<nettype> "IN" (i.e., multiple Internet protocol addresses) in the sa=
me media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] ca=
n be used to allow a choice among multiple Internet addresses.  The use of =
ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the <nettype> "IN"); o=
therwise, under the rules of ICE, an ICE mismatch will result.  However, th=
is ICE mismatch will in fact induce the desired behavior, causing the answe=
rer to abort ICE processing and use the connection address; so this ICE mis=
match is harmless, other than the inclusion of an "ice-mismatch" attribute =
in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



          

            
The text in the draft was worked out with Jonath=
an Lennox who raised the initial concen about conflict with ICE. If Jonatha=
n is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [=
mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siem=
ens-enterprise.com <thomas.stac=
h@siemens-enterprise.com>; Simo.Veik=
kolainen@nokia.com <Simo.Veikkolainen@n=
okia.com>; mmusic@ietf.org =
<mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; t=
homas.stach@siemens-enterprise.com; S=
imo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [=
mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@sie=
mens-enterprise.com>; Simo.Veikkolai=
nen@nokia.com <Simo.Veikkolainen@nokia.=
com>; mmusic@ietf.org <m=
music@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@si=
emens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veik=
kolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



            

              
-----Urspr=FCngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.=
com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@si=
emens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veik=
kolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



              

                
-----Urspr=FCngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.co=
m
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




                

                  
-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


                

                
transport protocols


                

                  
 and attributes.  This framework has been =
extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


                

                
is embedded


                

                  
 into the widely-used SDP offer/answer pro=
cedures.

 This memo extends the SDP capability negotiation


                

                
framework to allow


                

                  
 endpoints to negotiate three additional S=
DP capabilities.  In
 particular, this memo provides a mechanism to negotiate


                

              

              
bandwidth


              

                

                  
 ('b=3D' line), connection data ('c=3D' li=
ne), and titles


                

                
('i=3D' line for


                

                  
 each session or media).


The IETF datatracker status page for this draft is:
https://datatrack=
er.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://too=
ls.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf=
.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinf=
o/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinf=
o/mmusic



                

                
____________________________________________=
___
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinf=
o/mmusic



              

            

            
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinf=
o/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


          

          
--
Jonathan Lennox
jonathan@vidyo.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinf=
o/mmusic
.



        

        

      

    

    

  






--
Jonathan Lennox
jonathan@vidyo.com





=

--_000_D70EBE0548B145DBA358FD8293479C72vidyocom_--


From mohamed.boucadair@orange.com  Thu Mar 14 08:40:20 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC50C11E81AA for ; Thu, 14 Mar 2013 08:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.355
X-Spam-Level: 
X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=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 400Y8Rxu3e34 for ; Thu, 14 Mar 2013 08:40:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1A11E81A4 for ; Thu, 14 Mar 2013 08:40:17 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D6F7E324182; Thu, 14 Mar 2013 16:40:16 +0100 (CET)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BBF6F4C05D; Thu, 14 Mar 2013 16:40:16 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 14 Mar 2013 16:40:16 +0100
From: 
To: Flemming Andreasen 
Date: Thu, 14 Mar 2013 16:40:15 +0100
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4gx9aTBo9nkO1ZRPCSo8+CGgV9MwAAdA/A
Message-ID: <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr>
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com>
In-Reply-To: <5141EB56.9090103@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB7356880PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 15:40:20 -0000

--_000_94C682931C08B048B7A8645303FDC9F36EB7356880PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

Simo said: "That's not what I want." and it seems you disagree with him.

This illustrates there is a confusion in the current wording and the intent=
 of that text is not clear.

Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 16:23
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc : Jonathan Lennox; Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt


On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
Dear Flemming,

Apologies for not sending my comment earlier. I should read the draft befor=
e but I didn't read it since a while.

It is unfair to ignore the messages exchanged in this thread which say the =
text is confusing and it should be worked better. The wording proposed by J=
onathan is much better.

I respectfully disagree. What is unfair is that people do not read document=
s when they are WGLC'ed but still expect their comments to be addressed ~6 =
months later.

As to the message below be specific please; exactly what is it that is uncl=
ear in the text below ?

Thanks

-- Flemming


Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 15:35
=C0 : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the=
 draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).=
 The -01 version that was WGLC'ed stated the following:


The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.



The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).



The only difference is the addition of clarifying examples and hence there =
is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port iss=
ue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mm=
usic/current/msg10160.html). To recap, the draft specifically does not defi=
ne port negotiation (but simply reuses the current port in accordance with =
general capability negotiation operation). Since this doesn't work when cha=
nging between IN and PSTN, exception text to use port 9 for PSTN was added =
(again in accordance with previous discussion). One comment was received, w=
hich was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems,=
 but essentially amount to word-smithing requests. As a Working Group chair=
, I am unsympathetic to such requests on a document that is this far along =
and furthermore has external dependencies. We go through a WGLC process for=
 a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course=
 reasonable. With that in mind, if anybody still has comments on the -04 ve=
rsion, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:

I suggest being more concrete about ccap's restrictions, that it can't be u=
sed to negotiate alternative IP addresses.  We can then discuss only ICE, w=
ithout precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
 "IN" (i.e., multiple Internet protocol addresses) in the same med=
ia stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be u=
sed to allow a choice among multiple Internet addresses.  The use of ICE wi=
th capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the  "IN"); otherwi=
se, under the rules of ICE, an ICE mismatch will result.  However, this ICE=
 mismatch will in fact induce the desired behavior, causing the answerer to=
 abort ICE processing and use the connection address; so this ICE mismatch =
is harmless, other than the inclusion of an "ice-mismatch" attribute in the=
 SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



The text in the draft was worked out with Jonathan Lennox who raised the in=
itial concen about conflict with ICE. If Jonathan is ok with the revised pr=
oposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic=
@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


transport protocols


 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


is embedded


 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


framework to allow


 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


bandwidth


 ('b=3D' line), connection data ('c=3D' line), and titles


('i=3D' line for


 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



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



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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--
Jonathan Lennox
jonathan@vidyo.com


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





--_000_94C682931C08B048B7A8645303FDC9F36EB7356880PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Re-,


 


What is important is the quality of produced=
=20
documents. The content of the document is not frozen and unless I'm mistake=
n=20
there is not IETF LC.


 


What I understand from the text in the draft =
is: ccap=20
is allowed to signal an IPv4@ and IPv6@ if ICE is not=20
supported.


 


Simo said: "That's not what I=
=20
want." and it seems you disagree with him.


 


This illustrates there is a confusion in the =
current=20
wording and the intent of that text is not clear.


 


Cheers,


Med



  

  

  De : Flemming Andreasen=20
  [mailto:fandreas@cisco.com] 
Envoy=E9 : jeudi 14 mars 2013=
=20
  16:23
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc :=
=20
  Jonathan Lennox; Andrew Allen; mmusic@ietf.org
Objet : Re:=
=20
  [MMUSIC] RE : I-D Action:=20
  draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


  


  
On 3/14/13 11:19 AM, mohamed.boucadair@orange.com=
=20
  wrote:

  
    
    
Dear Flemming,

    
&nb=
sp;

    

    
Apologies for not sending my comment earl=
ier. I=20
    should read the draft before but I didn't read it since a=20
    while.

    
&nb=
sp;

    
It is unfair to ignore the messages excha=
nged in=20
    this thread which say the text is confusing and it should be worked bet=
ter.=20
    The wording proposed by Jonat=
han is=20
    much better. 

    

I respectfully=
=20
  disagree. What is unfair is that people do not read documents when they a=
re=20
  WGLC'ed but still expect their comments to be addressed ~6 months later.=
=20
  

As to the message below be specific please; exactly what is it th=
at is=20
  unclear in the text below ? 

Thanks 

-- Flemming 


  
    
Cheers,

    
Med


    
      

      

      De : Flemming Andreasen [mailto:fandreas@cisco.com]=20
      
Envoy=E9 : jeudi 14 mars 2013 15:35
=C0 :<=
/B>=20
      Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andre=
w=20
      Allen; mmusic@ietf.org
Objet =
:=20
      Re: [MMUSIC] RE : I-D Action:=20
      draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

A=
=20
      couple of points here related to the overall thread:

1) WGLC f=
or=20
      this draft completed about 6 months ago with no comments on the draft=
 (http://www.ietf.org/mail-archive/web/mmusic/=
current/msg09594.html).=20
      The -01 version that was WGLC'ed stated the=20
following:
<quote>
The 'ccap' capability attribute is=
 intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.
</quote

and there is what the current -04=20
      states:
<quote>
The 'ccap' capability attribute=
 is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).
</quo=
te>

The=20
      only difference is the addition of clarifying examples and hence ther=
e is=20
      no change in operation here. 

2) On January 25, Simo sent an e=
-mail=20
      to the list pointing out the port issue and suggesting text to be add=
ed=20
      (http://www.ietf.org/mail-archive/web/mmusic/=
current/msg10160.html).=20
      To recap, the draft specifically does not define port negotiation (bu=
t=20
      simply reuses the current port in accordance with general capability=
=20
      negotiation operation). Since this doesn't work when changing between=
 IN=20
      and PSTN, exception text to use port 9 for PSTN was added (again in=20
      accordance with previous discussion). One comment was received, which=
 was=20
      in favor of the proposal. 


The comments brought up now are=
 not=20
      identifying any new or severe problems, but essentially amount to=20
      word-smithing requests. As a Working Group chair, I am unsympathetic =
to=20
      such requests on a document that is this far along and furthermore ha=
s=20
      external dependencies. We go through a WGLC process for a reason, and=
=20
      people need to review and make their comments at that time.=20
      

Comments on new text or changes made since the WGLC completed=
 are=20
      of course reasonable. With that in mind, if anybody still has comment=
s on=20
      the -04 version, please let us know. 

Thanks 

-- Flemmi=
ng=20
      (MMUSIC co-chair)





      
On 3/14/13 9:04 AM, Jonathan Lennox=20
      wrote:

      
I suggest being more concrete about ccap=
's restrictions, that it can't be used to negotiate alternative IP addresse=
s.  We can then discuss only ICE, without precluding altc for the proprieta=
ry systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
<nettype> "IN" (i.e., multiple Internet protocol addresses) in the sa=
me media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] ca=
n be used to allow a choice among multiple Internet addresses.  The use of =
ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the <nettype> "IN"); o=
therwise, under the rules of ICE, an ICE mismatch will result.  However, th=
is ICE mismatch will in fact induce the desired behavior, causing the answe=
rer to abort ICE processing and use the connection address; so this ICE mis=
match is harmless, other than the inclusion of an "ice-mismatch" attribute =
in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



        
The text in the draft was =
worked out with Jonathan Lennox who raised the initial concen about conflic=
t with ICE. If Jonathan is ok with the revised proposal from Thomas then I =
am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemen=
s-enterprise.com <thomas.stach@si=
emens-enterprise.com>; Simo.Veikkolain=
en@nokia.com <Simo.Veikkolainen@nokia.com=
>; mmusic@ietf.org <mmusic@i=
etf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; th=
omas.stach@siemens-enterprise.com; Simo.V=
eikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@sieme=
ns-enterprise.com>; Simo.Veikkolainen@=
nokia.com <Simo.Veikkolainen@nokia.com>=
;; mmusic@ietf.org <mmusic@ietf=
.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siem=
ens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikk=
olainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



          
-----Urspr=FCngliche Nac=
hricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.co=
m; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siem=
ens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikk=
olainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



            
-----Urspr=FCngliche N=
achricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com<=
/A>
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




              
-----Message d'origi=
ne-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate

transport protocols


              
 and attributes.  Th=
is framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation

is embedded


              
 into the widely-use=
d SDP offer/answer procedures.

 This memo extends the SDP capability negotiation

framework to allow


              
 endpoints to negoti=
ate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate

bandwidth


            

              
 ('b=3D' line), conn=
ection data ('c=3D' line), and titles

('i=3D' line for


              
 each session or med=
ia).


The IETF datatracker status page for this draft is:
https://datatracker=
.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools=
.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf=
.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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


_________________________________________=
______
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/=
mmusic


____________________________=
___________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/=
mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--
Jonathan Lennox
jonathan@vidyo.com


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






--_000_94C682931C08B048B7A8645303FDC9F36EB7356880PUEXCB1Bnante_--

From sean.sheedy@arrisi.com  Thu Mar 14 10:21:25 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734AA11E8138 for ; Thu, 14 Mar 2013 10:21:25 -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 xii-coLcSzJo for ; Thu, 14 Mar 2013 10:21:24 -0700 (PDT)
Received: from arrisi.com (ironmail2.arrisi.com [216.234.147.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9593121F8EA7 for ; Thu, 14 Mar 2013 10:21:20 -0700 (PDT)
Received: from ([10.2.131.252]) by ironmail2.arrisi.com with ESMTP with TLS id CNFSXF1.55655737; Thu, 14 Mar 2013 13:21:09 -0400
Received: from CHIEXCAS3.ARRS.ARRISI.com (10.6.200.13) by ATLOWA1.ARRS.ARRISI.com (10.2.131.252) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Mar 2013 13:21:09 -0400
Received: from sean-netbook.osioda.org (10.6.159.6) by CHIEXCAS3.ARRS.ARRISI.com (10.6.200.13) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Mar 2013 12:21:08 -0500
Message-ID: <514206FF.3060407@arrisi.com>
Date: Thu, 14 Mar 2013 13:21:03 -0400
From: Sean Sheedy 
Organization: ARRIS, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: 
References:  <50CEE45A.3000502@alvestrand.no> <50CEE66F.8020902@ericsson.com>  <5140F428.2040101@ericsson.com>
In-Reply-To: <5140F428.2040101@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.6.159.6]
Subject: Re: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:21:25 -0000

I agree with this solution.  A couple of wording nits (interspersed):

On 03/13/2013 05:48 PM, Magnus Westerlund wrote:
> WG,
>
> I hereby proposes the following text
>
> In addition to the registered default ports, i.e. 554 (rtsp) and 322
> (rtsps), there are an alternative port 8554 registered. This port may
   (rtsps), an alternate port 8554 is registered.  Using this registered 
port

> provide some benefits from non-registered ports if a RTSP server is
provides some benefits over non-registered ...

> unable to use the default port. The benefits may include pre-configured
> security policies as well as classifiers in network monitoring tools.
>
> to be added in Section 10.2 after the first paragraph. Please comment if
> you see issues with this or thinks it is fine.
>
> Cheers
>
> Magnus
>
> On 2012-12-17 22:17, Ross Finlayson wrote:
>> (Grumple... I wish this mailing list were set up so that replies went to
>> the mailing list by default.  Resending to the whole mailing list
>> instead of just Magnus.)
>>
>>> The question is if this port number has any benefit at all.
>> Yes it does.  If a RTSP server cannot use port 554 (most likely because
>> it is running on a Unix system, but not as 'root'), then it can try
>> using port 8554 instead.  (FWIW, our RTSP server implementation - widely
>> used on the Internet - does this.)  As you noted, if a server uses port
>> 8554 (or any port other than 554), then this port number will need to be
>> included in the"rtsp://"  URLs that clients use.  But it's beneficial to
>> know - e.g., if you're managing a network's 'security' policy - that
>> RTSP will likely be used on either port 554 or port 8554 (rather than
>> either port 554 or some unspecified other port number).  Similarly, it's
>> useful for network monitoring tools to know that traffic on port 8554 is
>> likely to be RTSP.
>>
>


-- 
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--
Sean Sheedy
Staff System Software Engineer, Media and Communications Systems
Sean.Sheedy@arrisi.com  | 503-495-9454 (Phone)
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--


From worley@shell01.TheWorld.com  Thu Mar 14 10:54:04 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC321F8CD7 for ; Thu, 14 Mar 2013 10:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 6eZmhijR-pnm for ; Thu, 14 Mar 2013 10:54:02 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5D21F8995 for ; Thu, 14 Mar 2013 10:54:01 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2EHrQgG017729 for ; Thu, 14 Mar 2013 13:53:28 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2EHrQOm420753 for ; Thu, 14 Mar 2013 12:53:26 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2EHrQlP428972; Thu, 14 Mar 2013 13:53:26 -0400 (EDT)
Date: Thu, 14 Mar 2013 13:53:26 -0400 (EDT)
Message-Id: <201303141753.r2EHrQlP428972@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
In-reply-to: <51414A88.6040108@alum.mit.edu> (pkyzivat@alum.mit.edu)
References:  <51414A88.6040108@alum.mit.edu>
Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE:  Bundle, TURN and Legacy Interop)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:54:04 -0000

> From: Paul Kyzivat 
> 
> IMO there is an (at least implicit) goal that a sufficiently functional 
> sip device be able to interoperate with an RTCWEB-based device without a 
> media gateway.

As Jonathan Rosenberg said
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg06856.html)
> For many application developers, what is interesting about webRTC is
> NOT just browser to browser communications, but connecting users in
> a browser to users elsewhere - on other devices, in other
> networks. After all, the vast majority of web application developers
> do not have the luxury of a massive social graph, or the luxury of
> their users being parked persistently on their website and thus able
> to receive an incoming call. Many websites that have customer
> support or service needs would love to be able to allow their users
> to have a video call with an agent. However, those agents are
> probably sitting on existing agent systems which are not web based,
> and itbTo: 
Subject: 
--text follows this line--
s almost certainly true that they do not today support VP8,
> but rather H.264.

What he didn't say explicitly is that the existing agent systems use
SIP.  So there is a large market to be tapped if WebRTC connects
smoothly to SIP.  And when I say "smoothly", I mean that the web
server/SIP gateway only has to handle "signaling", that it can hand
the SDP across with little or no modification, and doesn't have to
touch the media packets at all.

Of course, WebRTC shouldn't be made less efficient or effective just
to interoperate with SIP, but I don't see that there's any necessity
to do that.  (As long as we remember EKR's dictum that in the context
of negotiating video media, an extra few hundred bytes added to an SDP
description is not significant!)

Dale

From worley@shell01.TheWorld.com  Thu Mar 14 10:54:04 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1094321F8CD0 for ; Thu, 14 Mar 2013 10:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZgDVp-6FsVqZ for ; Thu, 14 Mar 2013 10:54:02 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A021F8976 for ; Thu, 14 Mar 2013 10:54:01 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2EHqqL9031769 for ; Thu, 14 Mar 2013 13:52:54 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2EHqqgX427252 for ; Thu, 14 Mar 2013 12:52:52 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2EHqqYZ436030; Thu, 14 Mar 2013 13:52:52 -0400 (EDT)
Date: Thu, 14 Mar 2013 13:52:52 -0400 (EDT)
Message-Id: <201303141752.r2EHqqYZ436030@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
In-reply-to: <92B7E61ADAC1BB4F941F943788C08828047D3FC7@xmb-aln-x08.cisco.com> (eckelcu@cisco.com)
References:  <92B7E61ADAC1BB4F941F943788C08828047D3FC7@xmb-aln-x08.cisco.com>
Subject: [MMUSIC] Bundling and QoS marking (was: Question about Bundle and Legacy Interop)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:54:04 -0000

> From: "Charles Eckel (eckelcu)" 
> 
> > From: Markus.Isomaki@nokia.com
> > 
> > I've seen some drafts claiming that Bundle would be harmful in for instance
> > cellular networks for QoS differentiation. Is that the motivation where the
> > non-Bundled RTCWeb use comes from, or are there some other good
> > reasons?
> 
> Not just for cellular but for any scenario in which QoS is based on
> using different 5-tuples for media flows for which different
> treatment is desired.

The question of QoS differentiation is interesting and probably one we
have to address, as mobile devices have bandwidth limitations.

If it's possible to mark individual packets within a transport flow
for different QoS treatments, then we need to define QoS markings as
an "application level" attribute rather than a "transport level"
attirbute.

If QoS differentiation is done entirely based on transport
associations (5-tuples), then the strategy would be to have several
bundles of m= lines, one for each QoS type.

The naive way to do this, that is, just offering two different
bundles, is suboptimal if the offerer doesn't know whether different
media types need to be in different transport flows or not, because it
prevents the answerer from arranging for all the media to be in one
bundle (using one transport association, i.e., port) if the answerer
knows that there is no QoS problem.

This is a situation where using hierarchical bundling would provide a
solution:  If the offerer does not have a need for different transport
flows for audio and video, but is concerned that the answerer might
have such a need, it builds an offer containing a master bundle that
contains two subordinate bundles, one containing (e.g.) the audio
streams and one containing the video streams.

If the answerer does not want to separate audio and video, it accepts
all the bundling, and then all media are in one transport flow.  If
the answerer wants to separate audio and video, it rejects the
top-level bundle, but accepts each subordinate bundle individually,
thus arranging for two transport flows, one containing audio and one
containing video.

Dale

From mohamed.boucadair@orange.com  Thu Mar 14 10:55:24 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1040411E80E9 for ; Thu, 14 Mar 2013 10:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=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 1+HkazSgMUt3 for ; Thu, 14 Mar 2013 10:55:22 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B62CC11E813F for ; Thu, 14 Mar 2013 10:55:21 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 73EF33244CA; Thu, 14 Mar 2013 18:55:20 +0100 (CET)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 54AA74C05D; Thu, 14 Mar 2013 18:55:20 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 14 Mar 2013 18:55:19 +0100
From: 
To: Flemming Andreasen 
Date: Thu, 14 Mar 2013 18:55:18 +0100
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4g23ENPcC5hTYdSiaqdsK3TVX0wQAAGkL0
Message-ID: <94C682931C08B048B7A8645303FDC9F36EB755B1B2@PUEXCB1B.nanterre.francetelecom.fr>
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr>, <51420C3A.3040807@cisco.com>
In-Reply-To: <51420C3A.3040807@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.14.151524
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:55:24 -0000

Re-,

The answer from Simo is available here: http://www.ietf.org/mail-archive/we=
b/mmusic/current/msg10504.html. It is clear.

None of the answers received in this list, including the editor, have the s=
ame interpretation of the text I quoted as you. It is clear there is only n=
o consensus on what the text should say.


Cheers,
Med

________________________________________
De : Flemming Andreasen [fandreas@cisco.com]
Date d'envoi : jeudi 14 mars 2013 18:43
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc : Jonathan Lennox; Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.
What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).


Simo said: "That's not what I want." and it seems you disagree with him.

You are quoting out of context. Other than that I will let Simo respond.

This illustrates there is a confusion in the current wording and the intent=
 of that text is not clear.

I think the wording is clear, however I understand that you do not necessar=
ily agree with it. The time to express that dissenting opinion was ~6 monht=
s ago when WGLC was issued and completed without comments. Again, as WG cha=
ir, I'm not sympathetic to re-opening the document this late in the process=
 on the grounds that you have provided.

Thanks

-- Flemming (MMUSIC co-chair)


Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 16:23
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc : Jonathan Lennox; Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt


On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
Dear Flemming,

Apologies for not sending my comment earlier. I should read the draft befor=
e but I didn't read it since a while.

It is unfair to ignore the messages exchanged in this thread which say the =
text is confusing and it should be worked better. The wording proposed by J=
onathan is much better.

I respectfully disagree. What is unfair is that people do not read document=
s when they are WGLC'ed but still expect their comments to be addressed ~6 =
months later.

As to the message below be specific please; exactly what is it that is uncl=
ear in the text below ?

Thanks

-- Flemming


Cheers,
Med

________________________________
De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoy=E9 : jeudi 14 mars 2013 15:35
=C0 : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the=
 draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).=
 The -01 version that was WGLC'ed stated the following:


The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.



The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the  is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).



The only difference is the addition of clarifying examples and hence there =
is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port iss=
ue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mm=
usic/current/msg10160.html). To recap, the draft specifically does not defi=
ne port negotiation (but simply reuses the current port in accordance with =
general capability negotiation operation). Since this doesn't work when cha=
nging between IN and PSTN, exception text to use port 9 for PSTN was added =
(again in accordance with previous discussion). One comment was received, w=
hich was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems,=
 but essentially amount to word-smithing requests. As a Working Group chair=
, I am unsympathetic to such requests on a document that is this far along =
and furthermore has external dependencies. We go through a WGLC process for=
 a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course=
 reasonable. With that in mind, if anybody still has comments on the -04 ve=
rsion, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:

I suggest being more concrete about ccap's restrictions, that it can't be u=
sed to negotiate alternative IP addresses.  We can then discuss only ICE, w=
ithout precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the =
 "IN" (i.e., multiple Internet protocol addresses) in the same med=
ia stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be u=
sed to allow a choice among multiple Internet addresses.  The use of ICE wi=
th capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improv=
ement):

In principle, the attributes associated with ICE ought to be included only =
in configurations where each media stream has a connection address which ma=
tches one of the ICE candidates (i.e, for currently-defined candidate types=
, a configuration whose connection address has the  "IN"); otherwi=
se, under the rules of ICE, an ICE mismatch will result.  However, this ICE=
 mismatch will in fact induce the desired behavior, causing the answerer to=
 abort ICE processing and use the connection address; so this ICE mismatch =
is harmless, other than the inclusion of an "ice-mismatch" attribute in the=
 SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



The text in the draft was worked out with Jonathan Lennox who raised the in=
itial concen about conflict with ICE. If Jonathan is ok with the revised pr=
oposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous=
-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door=
 to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
=C0 : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS =
SDP and E.164 numbers as a connection address and is not intended for IPv4 =
vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [ma=
ilto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas ; Simo.Veikkolainen@nokia.com ; mmusic@ietf.org 
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps=
-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about IC=
E and not something else. So, I'm fine with that wording if this is the int=
ent of the authors. BTW, the altc draft already mentions that if altc and c=
cap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it se=
ems the consensus of the wg was: ICE is to solution to signal an IPv4 and I=
Pv6 address. The misc draft should specify ccap when distinct nettypes are =
in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey a=
n IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-0=
4.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE =
MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary=
 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that propr=
ietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte s=
pecification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) =
[RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection=
 addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address=
 family).


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. M=E4rz 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
=C0 : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



-----Urspr=FCngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. M=E4rz 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic=
@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoy=E9 : mercredi 13 mars 2013 16:09
=C0 : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=3Dccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=3D" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusi=
c-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


transport protocols


 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


is embedded


 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


framework to allow


 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


bandwidth


 ('b=3D' line), connection data ('c=3D' line), and titles


('i=3D' line for


 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



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



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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--
Jonathan Lennox
jonathan@vidyo.com


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






From fandreas@cisco.com  Thu Mar 14 10:41:00 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E180521F8E0C for ; Thu, 14 Mar 2013 10:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 3+s8+cyamHzF for ; Thu, 14 Mar 2013 10:40:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AE11621F8E49 for ; Thu, 14 Mar 2013 10:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53312; q=dns/txt; s=iport; t=1363282855; x=1364492455; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=G2OXiBh/I7jLHyRdXrXm3cqBc3MOsFU5O1NBvI2ODHs=; b=D1zw1o3saEH1MSQ+FtzCZ4CF+AMK47v3f9nrvH2pUK1V6mZmKkEMCeSX r9u6GH9DYyseextLgjFO5RWlm7wTkMZ0I472ekrpcB1PhONGnw6E8ocSg UaMM3VwfWRnMuTfN8GO0upAmj3XOnXI/tfHc7nSIYFJYYuJpm+aE4VU2c s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgFANcKQlGtJV2Y/2dsb2JhbABDhVKINbZ7gWUWdIIrAQEBAwEBAQEXAVMEBgEFBwQLEQQBAQEJFgEBBgcJAwIBAgEVHwkIBg0BBQIBAQUSh3MGBwXCDI1lgR8HAQoGAQaDOgOWWIEfj2ODJiCBNw
X-IronPort-AV: E=Sophos;i="4.84,845,1355097600";  d="scan'208,217";a="187518775"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 14 Mar 2013 17:40:54 +0000
Received: from dhcp-170e.meeting.ietf.org ([10.86.245.177]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EHeqCD020366;  Thu, 14 Mar 2013 17:40:53 GMT
Message-ID: <51420BA3.1040903@cisco.com>
Date: Thu, 14 Mar 2013 13:40:51 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jonathan Lennox 
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060000000002020706090504"
X-Mailman-Approved-At: Thu, 14 Mar 2013 10:56:33 -0700
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:41:01 -0000

This is a multi-part message in MIME format.
--------------060000000002020706090504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 3/14/13 11:33 AM, Jonathan Lennox wrote:
> My apologies; I was responding to Andrew's request that I review the 
> new text, and I'd lost track of where this draft was in the process.
>
> I have no problem with the original text that was in the WGLC.
Ok - thanks for clarifying.
>  I believe that, as written, it doesn't preclude the use of altc.
>
Agreed.

Thanks

-- Flemming


> On Mar 14, 2013, at 11:23 AM, Flemming Andreasen wrote:
>
>>
>> On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
>>> Dear Flemming,
>>> Apologies for not sending my comment earlier. I should read the 
>>> draft before but I didn't read it since a while.
>>> It is unfair to ignore the messages exchanged in this thread which 
>>> say the text is confusing and it should be worked better. The 
>>> wording proposed by Jonathan is much better.
>>>
>> I respectfully disagree. What is unfair is that people do not read 
>> documents when they are WGLC'ed but still expect their comments to be 
>> addressed ~6 months later.
>>
>> As to the message below be specific please; exactly what is it that 
>> is unclear in the text below ?
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Cheers,
>>> Med
>>>
>>>     ------------------------------------------------------------------------
>>>     *De :* Flemming Andreasen [mailto:fandreas@cisco.com]
>>>     *Envoyé :* jeudi 14 mars 2013 15:35
>>>     *À :* Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
>>>     *Cc :* Andrew Allen; mmusic@ietf.org
>>>     *Objet :* Re: [MMUSIC] RE : I-D Action:
>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>
>>>     A couple of points here related to the overall thread:
>>>
>>>     1) WGLC for this draft completed about 6 months ago with no
>>>     comments on the draft
>>>     (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).
>>>     The -01 version that was WGLC'ed stated the following:
>>>     
>>>
>>>     The 'ccap' capability attribute is intended to
>>>         be used only when there is no other mechanism available for
>>>         negotiating alternative connection address information, such as when
>>>         the  is different among the alternative addresses.  The
>>>         'ccap' attribute MUST NOT be used in situations where an existing
>>>         mechanism (such as Interactive Connectivity Establishment (ICE)
>>>         [RFC5245]) can be used to select between different connection
>>>         addresses.
>>>
>>>     >>
>>>     and there is what the current -04 states:
>>>     
>>>
>>>     The 'ccap' capability attribute is intended to
>>>         be used only when there is no other mechanism available for
>>>         negotiating alternative connection address information, such as when
>>>         the  is different among the alternative addresses (e.g.
>>>         "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>>         situations where an existing mechanism (such as Interactive
>>>         Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>         between different connection addresses (e.g.  "IP4" and "IP6" or
>>>         different IP addresses within the same IP address family).
>>>
>>>     
>>>
>>>     The only difference is the addition of clarifying examples and
>>>     hence there is no change in operation here.
>>>
>>>     2) On January 25, Simo sent an e-mail to the list pointing out
>>>     the port issue and suggesting text to be added
>>>     (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).
>>>     To recap, the draft specifically does not define port
>>>     negotiation (but simply reuses the current port in accordance
>>>     with general capability negotiation operation). Since this
>>>     doesn't work when changing between IN and PSTN, exception text
>>>     to use port 9 for PSTN was added (again in accordance with
>>>     previous discussion). One comment was received, which was in
>>>     favor of the proposal.
>>>
>>>
>>>     The comments brought up now are not identifying any new or
>>>     severe problems, but essentially amount to word-smithing
>>>     requests. As a Working Group chair, I am unsympathetic to such
>>>     requests on a document that is this far along and furthermore
>>>     has external dependencies. We go through a WGLC process for a
>>>     reason, and people need to review and make their comments at
>>>     that time.
>>>
>>>     Comments on new text or changes made since the WGLC completed
>>>     are of course reasonable. With that in mind, if anybody still
>>>     has comments on the -04 version, please let us know.
>>>
>>>     Thanks
>>>
>>>     -- Flemming (MMUSIC co-chair)
>>>
>>>
>>>
>>>
>>>     On 3/14/13 9:04 AM, Jonathan Lennox wrote:
>>>>     I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.
>>>>
>>>>     Thus, I suggest something like this (wordsmithing requested):
>>>>
>>>>     The 'ccap' attribute MUST NOT be used to offer multiple addresses with the  "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].
>>>>
>>>>
>>>>     This text might also be useful (though it definitely needs editorial improvement):
>>>>
>>>>     In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the  "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.
>>>>
>>>>
>>>>     On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:
>>>>
>>>>>     The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.
>>>>>
>>>>>     Andrew
>>>>>
>>>>>     ----- Original Message -----
>>>>>     From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>>>     Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
>>>>>     To: Andrew Allen;thomas.stach@siemens-enterprise.com  ;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>>>     Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>     Hi Andrew,
>>>>>
>>>>>     This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.
>>>>>
>>>>>     If it is not allowed, then the text should be clear.
>>>>>
>>>>>     Cheers,
>>>>>     Med
>>>>>
>>>>>     ________________________________________
>>>>>     De : Andrew Allen [aallen@blackberry.com]
>>>>>     Date d'envoi : mercredi 13 mars 2013 19:37
>>>>>     À : BOUCADAIR Mohamed OLNC/OLN;thomas.stach@siemens-enterprise.com;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>     Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>     The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.
>>>>>
>>>>>
>>>>>
>>>>>     ----- Original Message -----
>>>>>     From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>>>     Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
>>>>>     To: Stach, Thomas;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>>>     Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>     Re-,
>>>>>
>>>>>     The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.
>>>>>
>>>>>     In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.
>>>>>
>>>>>     The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.
>>>>>
>>>>>     Cheers,
>>>>>     Med
>>>>>
>>>>>     ________________________________________
>>>>>     De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>>>     Date d'envoi : mercredi 13 mars 2013 19:17
>>>>>     À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>     Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>     Mohammed,
>>>>>
>>>>>     I think it is not acceptable to mention altc in the example.
>>>>>     If I recollect correctly, the intention of the text is to specify that ICE MUST be
>>>>>     preferred over 'ccap' for IPv4/v6 address negotiation.
>>>>>
>>>>>     If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
>>>>>     I don't think that a standards track RFC should give the message that proprietary is preferred.
>>>>>     Based on this issue I think the current text in the draft does not work.
>>>>>     I would explicitly mention the relation of ICE and 'ccap'.
>>>>>     The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.
>>>>>
>>>>>     Thus I propose to rephrase to:
>>>>>
>>>>>     If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
>>>>>     the 'ccap' attribute it MUST use ICE to select between different connection addresses
>>>>>     (e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).
>>>>>
>>>>>
>>>>>     Regards
>>>>>     Thomas
>>>>>
>>>>>>     -----Ursprüngliche Nachricht-----
>>>>>>     Von:mohamed.boucadair@orange.com
>>>>>>     [mailto:mohamed.boucadair@orange.com]
>>>>>>     Gesendet: Mittwoch, 13. März 2013 13:40
>>>>>>     An: Stach, Thomas;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>>     Betreff: RE : [MMUSIC] I-D Action:
>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>
>>>>>>     Dear Thomas,
>>>>>>
>>>>>>     I'm not proposing to change the existing behavior; I'm just
>>>>>>     asking whether it is acceptable to add an additional example
>>>>>>     to the one already cited in the text.
>>>>>>     Wouldn't that be acceptable?
>>>>>>
>>>>>>     You can propose to add another example if you have any in mind.
>>>>>>
>>>>>>     Cheers,
>>>>>>     Med
>>>>>>
>>>>>>     ________________________________________
>>>>>>     De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>>>>     Date d'envoi : mercredi 13 mars 2013 17:57
>>>>>>     À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;
>>>>>>     mmusic@ietf.org
>>>>>>     Objet : AW: [MMUSIC] I-D Action:
>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>
>>>>>>     Mohammed,
>>>>>>
>>>>>>     I think you have draft-boucadair-mmusic-altc in mind.
>>>>>>     This is an individual submission intended to document some
>>>>>>     proporietary mechanism.
>>>>>>     I don't think we should make restrictions in a standards
>>>>>>     track document in support of proprietary mechanisms.
>>>>>>     Otherwise I could also think of additional proprietary stuff
>>>>>>     that could be mentioned as well.
>>>>>>
>>>>>>
>>>>>>     Regards
>>>>>>     Thomas
>>>>>>
>>>>>>>     -----Ursprüngliche Nachricht-----
>>>>>>>     Von:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>>     Im Auftrag vonmohamed.boucadair@orange.com
>>>>>>>     Gesendet: Mittwoch, 13. März 2013 11:20
>>>>>>>     An:Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>>>     Betreff: Re: [MMUSIC] I-D Action:
>>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>
>>>>>>>     Hi Simo,
>>>>>>>
>>>>>>>     The document says:
>>>>>>>
>>>>>>>     The 'ccap' attribute MUST NOT be used in
>>>>>>>        situations where an existing mechanism (such as Interactive
>>>>>>>        Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>>>>>        between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>>>        different IP addresses within the same IP address family).
>>>>>>>
>>>>>>>     Would it be possible to change it to the following:
>>>>>>>
>>>>>>>     NEW:
>>>>>>>
>>>>>>>     The 'ccap' attribute MUST NOT be used in
>>>>>>>        situations where a mechanism (such as Interactive
>>>>>>>        Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
>>>>>>>     used to select
>>>>>>>        between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>>>        different IP addresses within the same IP address family).
>>>>>>>
>>>>>>>
>>>>>>>     Thanks.
>>>>>>>     Cheers,
>>>>>>>     Med
>>>>>>>
>>>>>>>
>>>>>>>>     -----Message d'origine-----
>>>>>>>>     De :mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>>>     De la part deSimo.Veikkolainen@nokia.com
>>>>>>>>     Envoyé : mercredi 13 mars 2013 16:09
>>>>>>>>     À :mmusic@ietf.org
>>>>>>>>     Objet : Re: [MMUSIC] I-D Action:
>>>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>>
>>>>>>>>     Hello,
>>>>>>>>
>>>>>>>>     We just submitted a new version of the miscellaneous-caps
>>>>>>>>     draft, with text that states that if the connection data
>>>>>>>>     capability attribute (a=ccap) is used the port number in the
>>>>>>>>     resulting SDP MUST be the same as in the original "m=" line,
>>>>>>>>     except for PSTN type bearers (when the port number used is 9).
>>>>>>>>
>>>>>>>>     Regards,
>>>>>>>>     Simo
>>>>>>>>
>>>>>>>>     -----Original Message-----
>>>>>>>>     From:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>>>     On Behalf Of extinternet-drafts@ietf.org
>>>>>>>>     Sent: 13. maaliskuuta 2013 15:39
>>>>>>>>     To:i-d-announce@ietf.org
>>>>>>>>     Cc:mmusic@ietf.org
>>>>>>>>     Subject: [MMUSIC] I-D Action:
>>>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>     A New Internet-Draft is available from the on-line
>>>>>>>>     Internet-Drafts directories.
>>>>>>>>     This draft is a work item of the Multiparty Multimedia
>>>>>>>>     Session Control Working Group of the IETF.
>>>>>>>>
>>>>>>>>         Title           : Miscellaneous Capabilities
>>>>>>>>     Negotiation in the Session Description Protocol (SDP)
>>>>>>>>         Author(s)       : Miguel A. Garcia-Martin
>>>>>>>>                              Simo Veikkolainen
>>>>>>>>                              Robert R. Gilman
>>>>>>>>         Filename        :
>>>>>>>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>>         Pages           : 21
>>>>>>>>         Date            : 2013-03-13
>>>>>>>>
>>>>>>>>     Abstract:
>>>>>>>>       SDP has been extended with a capability negotiation mechanism
>>>>>>>>       framework that allows the endpoints to negotiate
>>>>>>>     transport protocols
>>>>>>>>       and attributes.  This framework has been extended with a media
>>>>>>>>       capabilities negotiation mechanism that allows endpoints to
>>>>>>>>     negotiate
>>>>>>>>       additional media-related capabilities.  This negotiation
>>>>>>>     is embedded
>>>>>>>>       into the widely-used SDP offer/answer procedures.
>>>>>>>>
>>>>>>>>       This memo extends the SDP capability negotiation
>>>>>>>     framework to allow
>>>>>>>>       endpoints to negotiate three additional SDP capabilities.  In
>>>>>>>>       particular, this memo provides a mechanism to negotiate
>>>>>>     bandwidth
>>>>>>>>       ('b=' line), connection data ('c=' line), and titles
>>>>>>>     ('i=' line for
>>>>>>>>       each session or media).
>>>>>>>>
>>>>>>>>
>>>>>>>>     The IETF datatracker status page for this draft is:
>>>>>>>>     https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
>>>>>>>>     neous-caps
>>>>>>>>
>>>>>>>>     There's also a htmlized version available at:
>>>>>>>>     http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04
>>>>>>>>
>>>>>>>>     A diff from the previous version is available at:
>>>>>>>>     http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
>>>>>>>>     neous-caps-04
>>>>>>>>
>>>>>>>>
>>>>>>>>     Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>     ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     mmusic mailing list
>>>>>>>>     mmusic@ietf.org
>>>>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>     _______________________________________________
>>>>>>>>     mmusic mailing list
>>>>>>>>     mmusic@ietf.org
>>>>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     mmusic mailing list
>>>>>>>     mmusic@ietf.org
>>>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>     _______________________________________________
>>>>>     mmusic mailing list
>>>>>     mmusic@ietf.org
>>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>     ---------------------------------------------------------------------
>>>>>     This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>>
>>>>>     ---------------------------------------------------------------------
>>>>>     This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>     --
>>>>     Jonathan Lennox
>>>>     jonathan@vidyo.com
>>>>
>>>>
>>>>     _______________________________________________
>>>>     mmusic mailing list
>>>>     mmusic@ietf.org
>>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>>     .
>>>>
>>>
>>
>
> --
> Jonathan Lennox
> jonathan@vidyo.com 
>
>


--------------060000000002020706090504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 3/14/13 11:33 AM, Jonathan Lennox
      wrote:

    

    

      
      
My apologies; I was responding to Andrew's request that I
        review the new text, and I'd lost track of where this draft was
        in the process.

      


      

      
I have no problem with the original text that was in the
        WGLC. 

    

    Ok - thanks for clarifying. 

    

      
 I believe that, as written, it doesn't preclude the use of
        altc.

      

    

    Agreed. 

    

    Thanks 

    

    -- Flemming 

    

    

    

      

        
On Mar 14, 2013, at 11:23 AM, Flemming Andreasen wrote:

        

        

          
 

            
On 3/14/13 11:19 AM, mohamed.boucadair@orange.com
              wrote:

            

            

              
Dear Flemming,

              
 

              

                    
Apologies for not
                          sending my comment earlier. I should read the
                          draft before but I didn't read it since a
                          while.

                  

              
 

              
It is unfair to ignore
                    the messages exchanged in this thread which say the
                    text is confusing and it should be worked better. The wording proposed by
                    Jonathan is much better. 

              
 

              

            

            I respectfully disagree. What is unfair is that people do
            not read documents when they are WGLC'ed but still expect
            their comments to be addressed ~6 months later. 

            

            As to the message below be specific please; exactly what is
            it that is unclear in the text below ? 

            

            Thanks 

            

            -- Flemming 

            

            

            

              
Cheers,

              
Med

              

              

                

                  
 De :
                    Flemming Andreasen [mailto:fandreas@cisco.com]
                    

                    Envoyé : jeudi 14 mars 2013 15:35

                    À : Jonathan Lennox; BOUCADAIR Mohamed
                    OLNC/OLN

                    Cc : Andrew Allen; mmusic@ietf.org

                    Objet : Re: [MMUSIC] RE : I-D Action:
                    draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

                  

                

                A couple of points here related to the overall thread:

                

                1) WGLC for this draft completed about 6 months ago with
                no comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).

                The -01 version that was WGLC'ed stated the following:

                <quote>

                
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.

                </quote

                

                and there is what the current -04 states:

                <quote>

                
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).

                </quote>

                

                The only difference is the addition of clarifying
                examples and hence there is no change in operation here.
                

                

                2) On January 25, Simo sent an e-mail to the list
                pointing out the port issue and suggesting text to be
                added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).

                To recap, the draft specifically does not define port
                negotiation (but simply reuses the current port in
                accordance with general capability negotiation
                operation). Since this doesn't work when changing
                between IN and PSTN, exception text to use port 9 for
                PSTN was added (again in accordance with previous
                discussion). One comment was received, which was in
                favor of the proposal. 

                

                

                The comments brought up now are not identifying any new
                or severe problems, but essentially amount to
                word-smithing requests. As a Working Group chair, I am
                unsympathetic to such requests on a document that is
                this far along and furthermore has external
                dependencies. We go through a WGLC process for a reason,
                and people need to review and make their comments at
                that time. 

                

                Comments on new text or changes made since the WGLC
                completed are of course reasonable. With that in mind,
                if anybody still has comments on the -04 version, please
                let us know. 

                

                Thanks 

                

                -- Flemming (MMUSIC co-chair)

                

                

                

                

                
On 3/14/13 9:04 AM,
                  Jonathan Lennox wrote:

                

                

                  
I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the <nettype> "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improvement):

In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the <nettype> "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



                  

                    
The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that proprietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).


Regards
Thomas



                    

                      
-----Ursprüngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



                      

                        
-----Ursprüngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. März 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




                        

                          
-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoyé : mercredi 13 mars 2013 16:09
À : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=ccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


                        

                        
transport protocols


                        

                          
 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


                        

                        
is embedded


                        

                          
 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


                        

                        
framework to allow


                        

                          
 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


                        

                      

                      
bandwidth


                      

                        

                          
 ('b=' line), connection data ('c=' line), and titles


                        

                        
('i=' line for


                        

                          
 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



                        

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



                      

                    

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


                  

                  
--
Jonathan Lennox
jonathan@vidyo.com


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



                

                

              

            

            

          

        

      

      

      

        
            
--

            
Jonathan Lennox

              jonathan@vidyo.com

              

            

          
      

      

    

    

  


--------------060000000002020706090504--

From fandreas@cisco.com  Thu Mar 14 10:43:31 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135F711E8110 for ; Thu, 14 Mar 2013 10:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 f+Gs2FCgriz8 for ; Thu, 14 Mar 2013 10:43:26 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C6B8011E80E9 for ; Thu, 14 Mar 2013 10:43:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56441; q=dns/txt; s=iport; t=1363283005; x=1364492605; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jq1Zqf86xHj7bjIpeGcSjyXbjddjdPdeG7FJ5MSG1Ps=; b=NtM/vchv5nzRxUUFHmvLWDn7YsyROSc83eg2edfBe0mo0+mx3c3hEdZg njGS3H1ZBQ0pV/KRh+HxrkuV8lfUZ3+aKAmw3ylCvNvATFcaUqrbv02Ap 4BN/dsZvxoy96EOYAw+l/LdfSF2wtiMimMneIFbgOxxGd9LLrFDT8ebh5 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAKAGULQlGtJV2Z/2dsb2JhbABDhVKINbZ2BAGBZRZ0gisBAQEDAQEBARcBUwQGAQUHBAsRBAEBAQkWAQEGBwkDAgECARUfCQgTAQUCAQEFEodzBgcFwhKNZSt0BwEKBgEGgzoDlliBH49jgyYggTc
X-IronPort-AV: E=Sophos;i="4.84,845,1355097600";  d="scan'208,217";a="187586896"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 14 Mar 2013 17:43:24 +0000
Received: from dhcp-170e.meeting.ietf.org ([10.86.245.177]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EHhMm5023339;  Thu, 14 Mar 2013 17:43:23 GMT
Message-ID: <51420C3A.3040807@cisco.com>
Date: Thu, 14 Mar 2013 13:43:22 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------030001040501020008050604"
X-Mailman-Approved-At: Thu, 14 Mar 2013 10:56:33 -0700
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 17:43:31 -0000

This is a multi-part message in MIME format.
--------------030001040501020008050604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
> Re-,
> What is important is the quality of produced documents. The content of 
> the document is not frozen and unless I'm mistaken there is not IETF LC.
>
Correct.
> What I understand from the text in the draft is: ccap is allowed to 
> signal an IPv4@ and IPv6@ if ICE is not supported.
>
ccap is not prohibited from doing so in the absence of ICE, however as 
explained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST 
NOT signal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for 
negotiating alternative IP-addresses since we have a Standards Track 
mechanism for doing so (ICE).


> Simo said: "That's not what I want." and it seems you disagree with him.
>
You are quoting out of context. Other than that I will let Simo respond.

> This illustrates there is a confusion in the current wording and the 
> intent of that text is not clear.
>
I think the wording is clear, however I understand that you do not 
necessarily agree with it. The time to express that dissenting opinion 
was ~6 monhts ago when WGLC was issued and completed without comments. 
Again, as WG chair, I'm not sympathetic to re-opening the document this 
late in the process on the grounds that you have provided.

Thanks

-- Flemming (MMUSIC co-chair)


> Cheers,
> Med
>
>     ------------------------------------------------------------------------
>     *De :* Flemming Andreasen [mailto:fandreas@cisco.com]
>     *Envoyé :* jeudi 14 mars 2013 16:23
>     *À :* BOUCADAIR Mohamed OLNC/OLN
>     *Cc :* Jonathan Lennox; Andrew Allen; mmusic@ietf.org
>     *Objet :* Re: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>
>     On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
>>     Dear Flemming,
>>     Apologies for not sending my comment earlier. I should read the
>>     draft before but I didn't read it since a while.
>>     It is unfair to ignore the messages exchanged in this thread
>>     which say the text is confusing and it should be worked better.
>>     The wording proposed by Jonathan is much better.
>>
>     I respectfully disagree. What is unfair is that people do not read
>     documents when they are WGLC'ed but still expect their comments to
>     be addressed ~6 months later.
>
>     As to the message below be specific please; exactly what is it
>     that is unclear in the text below ?
>
>     Thanks
>
>     -- Flemming
>
>
>>     Cheers,
>>     Med
>>
>>         ------------------------------------------------------------------------
>>         *De :* Flemming Andreasen [mailto:fandreas@cisco.com]
>>         *Envoyé :* jeudi 14 mars 2013 15:35
>>         *À :* Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
>>         *Cc :* Andrew Allen; mmusic@ietf.org
>>         *Objet :* Re: [MMUSIC] RE : I-D Action:
>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>
>>         A couple of points here related to the overall thread:
>>
>>         1) WGLC for this draft completed about 6 months ago with no
>>         comments on the draft
>>         (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).
>>         The -01 version that was WGLC'ed stated the following:
>>         
>>
>>         The 'ccap' capability attribute is intended to
>>             be used only when there is no other mechanism available for
>>             negotiating alternative connection address information, such as when
>>             the  is different among the alternative addresses.  The
>>             'ccap' attribute MUST NOT be used in situations where an existing
>>             mechanism (such as Interactive Connectivity Establishment (ICE)
>>             [RFC5245]) can be used to select between different connection
>>             addresses.
>>
>>         >
>>         and there is what the current -04 states:
>>         
>>
>>         The 'ccap' capability attribute is intended to
>>             be used only when there is no other mechanism available for
>>             negotiating alternative connection address information, such as when
>>             the  is different among the alternative addresses (e.g.
>>             "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>             situations where an existing mechanism (such as Interactive
>>             Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>             between different connection addresses (e.g.  "IP4" and "IP6" or
>>             different IP addresses within the same IP address family).
>>
>>         
>>
>>         The only difference is the addition of clarifying examples
>>         and hence there is no change in operation here.
>>
>>         2) On January 25, Simo sent an e-mail to the list pointing
>>         out the port issue and suggesting text to be added
>>         (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).
>>         To recap, the draft specifically does not define port
>>         negotiation (but simply reuses the current port in accordance
>>         with general capability negotiation operation). Since this
>>         doesn't work when changing between IN and PSTN, exception
>>         text to use port 9 for PSTN was added (again in accordance
>>         with previous discussion). One comment was received, which
>>         was in favor of the proposal.
>>
>>
>>         The comments brought up now are not identifying any new or
>>         severe problems, but essentially amount to word-smithing
>>         requests. As a Working Group chair, I am unsympathetic to
>>         such requests on a document that is this far along and
>>         furthermore has external dependencies. We go through a WGLC
>>         process for a reason, and people need to review and make
>>         their comments at that time.
>>
>>         Comments on new text or changes made since the WGLC completed
>>         are of course reasonable. With that in mind, if anybody still
>>         has comments on the -04 version, please let us know.
>>
>>         Thanks
>>
>>         -- Flemming (MMUSIC co-chair)
>>
>>
>>
>>
>>         On 3/14/13 9:04 AM, Jonathan Lennox wrote:
>>>         I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.
>>>
>>>         Thus, I suggest something like this (wordsmithing requested):
>>>
>>>         The 'ccap' attribute MUST NOT be used to offer multiple addresses with the  "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].
>>>
>>>
>>>         This text might also be useful (though it definitely needs editorial improvement):
>>>
>>>         In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the  "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.
>>>
>>>
>>>         On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:
>>>
>>>>         The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.
>>>>
>>>>         Andrew
>>>>
>>>>         ----- Original Message -----
>>>>         From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>>         Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
>>>>         To: Andrew Allen;thomas.stach@siemens-enterprise.com  ;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>>         Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>         Hi Andrew,
>>>>
>>>>         This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.
>>>>
>>>>         If it is not allowed, then the text should be clear.
>>>>
>>>>         Cheers,
>>>>         Med
>>>>
>>>>         ________________________________________
>>>>         De : Andrew Allen [aallen@blackberry.com]
>>>>         Date d'envoi : mercredi 13 mars 2013 19:37
>>>>         À : BOUCADAIR Mohamed OLNC/OLN;thomas.stach@siemens-enterprise.com;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>         Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>         The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.
>>>>
>>>>
>>>>
>>>>         ----- Original Message -----
>>>>         From:mohamed.boucadair@orange.com  [mailto:mohamed.boucadair@orange.com]
>>>>         Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
>>>>         To: Stach, Thomas;Simo.Veikkolainen@nokia.com  ;mmusic@ietf.org  
>>>>         Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>         Re-,
>>>>
>>>>         The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.
>>>>
>>>>         In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.
>>>>
>>>>         The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.
>>>>
>>>>         Cheers,
>>>>         Med
>>>>
>>>>         ________________________________________
>>>>         De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>>         Date d'envoi : mercredi 13 mars 2013 19:17
>>>>         À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>         Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>
>>>>         Mohammed,
>>>>
>>>>         I think it is not acceptable to mention altc in the example.
>>>>         If I recollect correctly, the intention of the text is to specify that ICE MUST be
>>>>         preferred over 'ccap' for IPv4/v6 address negotiation.
>>>>
>>>>         If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
>>>>         I don't think that a standards track RFC should give the message that proprietary is preferred.
>>>>         Based on this issue I think the current text in the draft does not work.
>>>>         I would explicitly mention the relation of ICE and 'ccap'.
>>>>         The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.
>>>>
>>>>         Thus I propose to rephrase to:
>>>>
>>>>         If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
>>>>         the 'ccap' attribute it MUST use ICE to select between different connection addresses
>>>>         (e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).
>>>>
>>>>
>>>>         Regards
>>>>         Thomas
>>>>
>>>>>         -----Ursprüngliche Nachricht-----
>>>>>         Von:mohamed.boucadair@orange.com
>>>>>         [mailto:mohamed.boucadair@orange.com]
>>>>>         Gesendet: Mittwoch, 13. März 2013 13:40
>>>>>         An: Stach, Thomas;Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>         Betreff: RE : [MMUSIC] I-D Action:
>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>         Dear Thomas,
>>>>>
>>>>>         I'm not proposing to change the existing behavior; I'm just
>>>>>         asking whether it is acceptable to add an additional example
>>>>>         to the one already cited in the text.
>>>>>         Wouldn't that be acceptable?
>>>>>
>>>>>         You can propose to add another example if you have any in mind.
>>>>>
>>>>>         Cheers,
>>>>>         Med
>>>>>
>>>>>         ________________________________________
>>>>>         De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
>>>>>         Date d'envoi : mercredi 13 mars 2013 17:57
>>>>>         À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;
>>>>>         mmusic@ietf.org
>>>>>         Objet : AW: [MMUSIC] I-D Action:
>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>
>>>>>         Mohammed,
>>>>>
>>>>>         I think you have draft-boucadair-mmusic-altc in mind.
>>>>>         This is an individual submission intended to document some
>>>>>         proporietary mechanism.
>>>>>         I don't think we should make restrictions in a standards
>>>>>         track document in support of proprietary mechanisms.
>>>>>         Otherwise I could also think of additional proprietary stuff
>>>>>         that could be mentioned as well.
>>>>>
>>>>>
>>>>>         Regards
>>>>>         Thomas
>>>>>
>>>>>>         -----Ursprüngliche Nachricht-----
>>>>>>         Von:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>         Im Auftrag vonmohamed.boucadair@orange.com
>>>>>>         Gesendet: Mittwoch, 13. März 2013 11:20
>>>>>>         An:Simo.Veikkolainen@nokia.com;mmusic@ietf.org
>>>>>>         Betreff: Re: [MMUSIC] I-D Action:
>>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>
>>>>>>         Hi Simo,
>>>>>>
>>>>>>         The document says:
>>>>>>
>>>>>>         The 'ccap' attribute MUST NOT be used in
>>>>>>            situations where an existing mechanism (such as Interactive
>>>>>>            Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>>>>            between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>>            different IP addresses within the same IP address family).
>>>>>>
>>>>>>         Would it be possible to change it to the following:
>>>>>>
>>>>>>         NEW:
>>>>>>
>>>>>>         The 'ccap' attribute MUST NOT be used in
>>>>>>            situations where a mechanism (such as Interactive
>>>>>>            Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
>>>>>>         used to select
>>>>>>            between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>>>            different IP addresses within the same IP address family).
>>>>>>
>>>>>>
>>>>>>         Thanks.
>>>>>>         Cheers,
>>>>>>         Med
>>>>>>
>>>>>>
>>>>>>>         -----Message d'origine-----
>>>>>>>         De :mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>>         De la part deSimo.Veikkolainen@nokia.com
>>>>>>>         Envoyé : mercredi 13 mars 2013 16:09
>>>>>>>         À :mmusic@ietf.org
>>>>>>>         Objet : Re: [MMUSIC] I-D Action:
>>>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>
>>>>>>>         Hello,
>>>>>>>
>>>>>>>         We just submitted a new version of the miscellaneous-caps
>>>>>>>         draft, with text that states that if the connection data
>>>>>>>         capability attribute (a=ccap) is used the port number in the
>>>>>>>         resulting SDP MUST be the same as in the original "m=" line,
>>>>>>>         except for PSTN type bearers (when the port number used is 9).
>>>>>>>
>>>>>>>         Regards,
>>>>>>>         Simo
>>>>>>>
>>>>>>>         -----Original Message-----
>>>>>>>         From:mmusic-bounces@ietf.org  [mailto:mmusic-bounces@ietf.org]
>>>>>>>         On Behalf Of extinternet-drafts@ietf.org
>>>>>>>         Sent: 13. maaliskuuta 2013 15:39
>>>>>>>         To:i-d-announce@ietf.org
>>>>>>>         Cc:mmusic@ietf.org
>>>>>>>         Subject: [MMUSIC] I-D Action:
>>>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>
>>>>>>>
>>>>>>>         A New Internet-Draft is available from the on-line
>>>>>>>         Internet-Drafts directories.
>>>>>>>         This draft is a work item of the Multiparty Multimedia
>>>>>>>         Session Control Working Group of the IETF.
>>>>>>>
>>>>>>>             Title           : Miscellaneous Capabilities
>>>>>>>         Negotiation in the Session Description Protocol (SDP)
>>>>>>>             Author(s)       : Miguel A. Garcia-Martin
>>>>>>>                                  Simo Veikkolainen
>>>>>>>                                  Robert R. Gilman
>>>>>>>             Filename        :
>>>>>>>         draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>>>>>>             Pages           : 21
>>>>>>>             Date            : 2013-03-13
>>>>>>>
>>>>>>>         Abstract:
>>>>>>>           SDP has been extended with a capability negotiation mechanism
>>>>>>>           framework that allows the endpoints to negotiate
>>>>>>         transport protocols
>>>>>>>           and attributes.  This framework has been extended with a media
>>>>>>>           capabilities negotiation mechanism that allows endpoints to
>>>>>>>         negotiate
>>>>>>>           additional media-related capabilities.  This negotiation
>>>>>>         is embedded
>>>>>>>           into the widely-used SDP offer/answer procedures.
>>>>>>>
>>>>>>>           This memo extends the SDP capability negotiation
>>>>>>         framework to allow
>>>>>>>           endpoints to negotiate three additional SDP capabilities.  In
>>>>>>>           particular, this memo provides a mechanism to negotiate
>>>>>         bandwidth
>>>>>>>           ('b=' line), connection data ('c=' line), and titles
>>>>>>         ('i=' line for
>>>>>>>           each session or media).
>>>>>>>
>>>>>>>
>>>>>>>         The IETF datatracker status page for this draft is:
>>>>>>>         https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
>>>>>>>         neous-caps
>>>>>>>
>>>>>>>         There's also a htmlized version available at:
>>>>>>>         http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04
>>>>>>>
>>>>>>>         A diff from the previous version is available at:
>>>>>>>         http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
>>>>>>>         neous-caps-04
>>>>>>>
>>>>>>>
>>>>>>>         Internet-Drafts are also available by anonymous FTP at:
>>>>>>>         ftp://ftp.ietf.org/internet-drafts/
>>>>>>>
>>>>>>>         _______________________________________________
>>>>>>>         mmusic mailing list
>>>>>>>         mmusic@ietf.org
>>>>>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>         _______________________________________________
>>>>>>>         mmusic mailing list
>>>>>>>         mmusic@ietf.org
>>>>>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>>         _______________________________________________
>>>>>>         mmusic mailing list
>>>>>>         mmusic@ietf.org
>>>>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>         _______________________________________________
>>>>         mmusic mailing list
>>>>         mmusic@ietf.org
>>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>>         ---------------------------------------------------------------------
>>>>         This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>
>>>>         ---------------------------------------------------------------------
>>>>         This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>         --
>>>         Jonathan Lennox
>>>         jonathan@vidyo.com
>>>
>>>
>>>         _______________________________________________
>>>         mmusic mailing list
>>>         mmusic@ietf.org
>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>         .
>>>
>>
>


--------------030001040501020008050604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 3/14/13 11:40 AM,
      mohamed.boucadair@orange.com wrote:

    

    

      
      
      
Re-,

      
 

      
What is
            important is the quality of produced documents. The content
            of the document is not frozen and unless I'm mistaken there
            is not IETF LC.

      

        

      

    

    Correct. 

    

      
What I
            understand from the text in the draft is: ccap is allowed to
            signal an IPv4@ and IPv6@ if ICE is not supported.

      

        

      

    

    ccap is not prohibited from doing so in the absence of ICE, however
    as explained in the document

    1) When the IETF Standard Track mechanism ICE is available, ccap
    MUST NOT signal an IPv4/IPV6 address alternative.

    2) The draft does (intentionally) not provide a full solution for
    negotiating alternative IP-addresses since we have a Standards Track
    mechanism for doing so (ICE). 

    

    

    

      
Simo said: "That's not what I want." and it seems you
            disagree with him.

      

        

      

    

    You are quoting out of context. Other than that I will let Simo
    respond. 

    

    

      
This illustrates
            there is a confusion in the current wording and the intent
            of that text is not clear.

      

        

      

    

    I think the wording is clear, however I understand that you do not
    necessarily agree with it. The time to express that dissenting
    opinion was ~6 monhts ago when WGLC was issued and completed without
    comments. Again, as WG chair, I'm not sympathetic to re-opening the
    document this late in the process on the grounds that you have
    provided. 

    

    Thanks 

    

    -- Flemming (MMUSIC co-chair)

    

    

    

      
Cheers,

      
Med

      

      

        

          
 De :
            Flemming Andreasen [mailto:fandreas@cisco.com] 

            Envoyé : jeudi 14 mars 2013 16:23

            À : BOUCADAIR Mohamed OLNC/OLN

            Cc : Jonathan Lennox; Andrew Allen; mmusic@ietf.org

            Objet : Re: [MMUSIC] RE : I-D Action:
            draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          

        

        

        
On 3/14/13 11:19 AM, mohamed.boucadair@orange.com
          wrote:

        

        

          
          
Dear
                Flemming,

          
 

          

                
Apologies for not
                      sending my comment earlier. I should read the
                      draft before but I didn't read it since a while.

              

          
 

          
It is unfair
                to ignore the messages exchanged in this thread which
                say the text is confusing and it should be worked
                better. The wording
                proposed by Jonathan is much better. 

          


          

        

        I respectfully disagree. What is unfair is that people do not
        read documents when they are WGLC'ed but still expect their
        comments to be addressed ~6 months later. 

        

        As to the message below be specific please; exactly what is it
        that is unclear in the text below ? 

        

        Thanks 

        

        -- Flemming 

        

        

        

          
Cheers,

          
Med

          

          

            

              
 De :
                Flemming Andreasen [mailto:fandreas@cisco.com]
                

                Envoyé : jeudi 14 mars 2013 15:35

                À : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN

                Cc : Andrew Allen; mmusic@ietf.org

                Objet : Re: [MMUSIC] RE : I-D Action:
                draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

              

            

            A couple of points here related to the overall thread:

            

            1) WGLC for this draft completed about 6 months ago with no
            comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html).
            The -01 version that was WGLC'ed stated the following:

            <quote>

            
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.

            </quote

            

            and there is what the current -04 states:

            <quote>

            
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).

            </quote>

            

            The only difference is the addition of clarifying examples
            and hence there is no change in operation here. 

            

            2) On January 25, Simo sent an e-mail to the list pointing
            out the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html).
            To recap, the draft specifically does not define port
            negotiation (but simply reuses the current port in
            accordance with general capability negotiation operation).
            Since this doesn't work when changing between IN and PSTN,
            exception text to use port 9 for PSTN was added (again in
            accordance with previous discussion). One comment was
            received, which was in favor of the proposal. 

            

            

            The comments brought up now are not identifying any new or
            severe problems, but essentially amount to word-smithing
            requests. As a Working Group chair, I am unsympathetic to
            such requests on a document that is this far along and
            furthermore has external dependencies. We go through a WGLC
            process for a reason, and people need to review and make
            their comments at that time. 

            

            Comments on new text or changes made since the WGLC
            completed are of course reasonable. With that in mind, if
            anybody still has comments on the -04 version, please let us
            know. 

            

            Thanks 

            

            -- Flemming (MMUSIC co-chair)

            

            

            

            

            
On 3/14/13 9:04 AM, Jonathan
              Lennox wrote:

            

            

              
I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the <nettype> "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improvement):

In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the <nettype> "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:



              

                
The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that proprietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).


Regards
Thomas



                

                  
-----Ursprüngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas



                  

                    
-----Ursprüngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. März 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med




                    

                      
-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoyé : mercredi 13 mars 2013 16:09
À : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=ccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate


                    

                    
transport protocols


                    

                      
 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation


                    

                    
is embedded


                    

                      
 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation


                    

                    
framework to allow


                    

                      
 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate


                    

                  

                  
bandwidth


                  

                    

                      
 ('b=' line), connection data ('c=' line), and titles


                    

                    
('i=' line for


                    

                      
 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
neous-caps-04


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

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



                    

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



                  

                

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


              

              
--
Jonathan Lennox
jonathan@vidyo.com


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



            

            

          

        

        

      

    

    

  


--------------030001040501020008050604--

From jonathan@vidyo.com  Thu Mar 14 11:06:31 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5F11E817C for ; Thu, 14 Mar 2013 11:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.680,  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 s5e9HMtQwnOg for ; Thu, 14 Mar 2013 11:06:30 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7F611E8155 for ; Thu, 14 Mar 2013 11:06:30 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1C68B416982; Thu, 14 Mar 2013 08:12:33 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 40B92416B22; Thu, 14 Mar 2013 08:12:26 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 14 Mar 2013 14:06:23 -0400
From: Jonathan Lennox 
To: Flemming Andreasen 
Date: Thu, 14 Mar 2013 14:06:24 -0400
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4g3qMCFrP7fcmtQvavboZ7ZKvUFQ==
Message-ID: 
References:   <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr> <51420C3A.3040807@cisco.com>
In-Reply-To: <51420C3A.3040807@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_DBB452AD74434B45A706BC79442979BBvidyocom_"
MIME-Version: 1.0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 18:06:31 -0000

--_000_DBB452AD74434B45A706BC79442979BBvidyocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.
What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).

Hi, Fleming --

My understanding of the WG consensus -- and my interpretation of the text i=
n the draft -- was stronger than this: ccap MUST NOT be used for the kinds =
of alternatives ICE can express, whether or not ICE is actually being used =
in a particular offer/answer.

If we're getting divergent interpretations of this document, we probably do=
 need to update its text.

--
Jonathan Lennox
jonathan@vidyo.com



--_000_DBB452AD74434B45A706BC79442979BBvidyocom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On Mar 14, 2=
013, at 1:43 PM, Flemming Andreasen wrote:


 =20
   =20
 =20
  

   =20
    
On 3/14/13 11:40 AM,
      mohamed.boucadair@orange.com wrote:

    

    

     =20
     =20
      
Re-,
      
 

      
What is
            important is the quality of produced documents. The content
            of the document is not frozen and unless I'm mistaken there
            is not IETF LC.

      

        

      

    

    Correct. 

    

      
What I
            understand from the text in the draft is: ccap is allowed to
            signal an IPv4@ and IPv6@ if ICE is not supported.

      

        

      

    

    ccap is not prohibited from doing so in the absence of ICE, however
    as explained in the document

    1) When the IETF Standard Track mechanism ICE is available, ccap
    MUST NOT signal an IPv4/IPV6 address alternative.

    2) The draft does (intentionally) not provide a full solution for
    negotiating alternative IP-addresses since we have a Standards Track
    mechanism for doing so (ICE). 

Hi, Fleming --

My understanding of the WG consen=
sus -- and my interpretation of the text in the draft -- was stronger than =
this: ccap MUST NOT be used for the kinds of alternatives ICE can express, =
whether or not ICE is actually being used in a particular offer/answer.

If we're getting divergent interpretations of this do=
cument, we probably do need to update its text.



--
Jonathan Lennox
jonathan@vidyo.com





=

--_000_DBB452AD74434B45A706BC79442979BBvidyocom_--

From prvs=17855228f7=aallen@blackberry.com  Thu Mar 14 11:10:41 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665611E81AB for ; Thu, 14 Mar 2013 11:10:41 -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 ww1vehBV84b4 for ; Thu, 14 Mar 2013 11:10:40 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4211E8144 for ; Thu, 14 Mar 2013 11:10:40 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-51-51421295e823
Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CC.0E.13213.59212415; Thu, 14 Mar 2013 13:10:30 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 13:10:29 -0500
From: Andrew Allen 
To: "jonathan@vidyo.com" , "fandreas@cisco.com" 
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOILR4FRB+udTQGku/nF8/mU+ospillH4AgAAMq4CAAADiAIAABM+AgAAiZgCAAAZvAP//rVJA
Date: Thu, 14 Mar 2013 18:10:29 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D2AE5EXMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsXC5ZyvrTtNyCnQYMY/Lov3F3Qt9i8+z2wx dfljFovDb5+yO7B4TPm9kdVjyZKfTB4tz06yebQ9u8MewBLVwGiTlFhSFpyZnqdvZ5OYl5df kliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2Kr lFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyfvw9xVLQ41Ux e/NsxgbGFo8uRk4OCQETiZdrt7JD2GISF+6tZwOxhQTamCQudAp2MXIB2ZsZJe5NOMgIkmAT 0JLYf3g6E4gtIhAlcb3rJjOIzSyQIXG2bRYLiC0sECHxZvVFFoiaSIl772ewwtQvOLYczGYR UJXYevwfmM0r4CHx8fxDMJtTwFZi44s1YAcxCshK7D57nQlivrjErSfzmSAOFZBYsuc8M4Qt KvHyMcQcCQFFib97v7NC1OdLdGxaxwwxX1Di5MwnLBMYRWYhGTULSdksJGWzGDmA4poS63fp Q5QoSkzpfsgOYWtItM6Zy44svoCRfRWjYG5GsYGZYXJesl5RZq5eXmrJJkZQinHUMNjB+P69 xSFGAQ5GJR5ez4WOgUKsiWXFlbmHGCU4mJVEeHf9BQrxpiRWVqUW5ccXleakFh9iDAIG0ERm Ke7kfGD6yyuJNzYwIJKjJM4rEigaKCSQDkxi2ampBalFMEOZODhBlnJJiRQDU1FqUWJpSUY8 KGHGFwNTplQDozZTnu3PNL7fooG5ejPDtm69r+Tx78yMOUx18rOXF38uK3eSrNjVvj54br+a sfmcr3ovDb362PTiJs/i36mkaLovnS9vebTfnHXLZp3Sz3t4cf/TV15M8ad77jdP/1PoMftF 88SurA8uIvWO82wyy+fmhm3Ol9Dq/RCW7nStzaG8K7lg9+sOJZbijERDLeai4kQAcO5L+X8D AAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 18:10:41 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2AE5EXMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpNeSB1bmRlcnN0YW5kaW5nIGFsc28gd2FzIHRoYXQgd2UgYWdyZWVkIHRoYXQgQ0NBUCB3
YXMgbm90IGFuIGFsdGVybmF0aXZlIHRvIElDRS4NCg0KDQpGcm9tOiBKb25hdGhhbiBMZW5u
b3ggW21haWx0bzpqb25hdGhhbkB2aWR5by5jb21dDQpTZW50OiBUaHVyc2RheSwgTWFyY2gg
MTQsIDIwMTMgMDE6MDYgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lDQpUbzogRmxlbW1pbmcg
QW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb20+DQpDYzogbW9oYW1lZC5ib3VjYWRhaXJA
b3JhbmdlLmNvbSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEFuZHJldyBBbGxl
bjsgbW11c2ljQGlldGYub3JnIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01N
VVNJQ10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFu
ZW91cy1jYXBzLTA0LnR4dA0KDQoNCk9uIE1hciAxNCwgMjAxMywgYXQgMTo0MyBQTSwgRmxl
bW1pbmcgQW5kcmVhc2VuIHdyb3RlOg0KDQpPbiAzLzE0LzEzIDExOjQwIEFNLCBtb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu
Y29tPiB3cm90ZToNClJlLSwNCg0KV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhlIHF1YWxpdHkg
b2YgcHJvZHVjZWQgZG9jdW1lbnRzLiBUaGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQgaXMg
bm90IGZyb3plbiBhbmQgdW5sZXNzIEknbSBtaXN0YWtlbiB0aGVyZSBpcyBub3QgSUVURiBM
Qy4NCg0KQ29ycmVjdC4NCldoYXQgSSB1bmRlcnN0YW5kIGZyb20gdGhlIHRleHQgaW4gdGhl
IGRyYWZ0IGlzOiBjY2FwIGlzIGFsbG93ZWQgdG8gc2lnbmFsIGFuIElQdjRAIGFuZCBJUHY2
QCBpZiBJQ0UgaXMgbm90IHN1cHBvcnRlZC4NCg0KY2NhcCBpcyBub3QgcHJvaGliaXRlZCBm
cm9tIGRvaW5nIHNvIGluIHRoZSBhYnNlbmNlIG9mIElDRSwgaG93ZXZlciBhcyBleHBsYWlu
ZWQgaW4gdGhlIGRvY3VtZW50DQoxKSBXaGVuIHRoZSBJRVRGIFN0YW5kYXJkIFRyYWNrIG1l
Y2hhbmlzbSBJQ0UgaXMgYXZhaWxhYmxlLCBjY2FwIE1VU1QgTk9UIHNpZ25hbCBhbiBJUHY0
L0lQVjYgYWRkcmVzcyBhbHRlcm5hdGl2ZS4NCjIpIFRoZSBkcmFmdCBkb2VzIChpbnRlbnRp
b25hbGx5KSBub3QgcHJvdmlkZSBhIGZ1bGwgc29sdXRpb24gZm9yIG5lZ290aWF0aW5nIGFs
dGVybmF0aXZlIElQLWFkZHJlc3NlcyBzaW5jZSB3ZSBoYXZlIGEgU3RhbmRhcmRzIFRyYWNr
IG1lY2hhbmlzbSBmb3IgZG9pbmcgc28gKElDRSkuDQoNCkhpLCBGbGVtaW5nIC0tDQoNCk15
IHVuZGVyc3RhbmRpbmcgb2YgdGhlIFdHIGNvbnNlbnN1cyAtLSBhbmQgbXkgaW50ZXJwcmV0
YXRpb24gb2YgdGhlIHRleHQgaW4gdGhlIGRyYWZ0IC0tIHdhcyBzdHJvbmdlciB0aGFuIHRo
aXM6IGNjYXAgTVVTVCBOT1QgYmUgdXNlZCBmb3IgdGhlIGtpbmRzIG9mIGFsdGVybmF0aXZl
cyBJQ0UgY2FuIGV4cHJlc3MsIHdoZXRoZXIgb3Igbm90IElDRSBpcyBhY3R1YWxseSBiZWlu
ZyB1c2VkIGluIGEgcGFydGljdWxhciBvZmZlci9hbnN3ZXIuDQoNCklmIHdlJ3JlIGdldHRp
bmcgZGl2ZXJnZW50IGludGVycHJldGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50LCB3ZSBwcm9i
YWJseSBkbyBuZWVkIHRvIHVwZGF0ZSBpdHMgdGV4dC4NCg0KLS0NCkpvbmF0aGFuIExlbm5v
eA0Kam9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+DQoNCg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0
dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZp
bGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNv
bGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29u
c3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3Jt
YXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBw
cm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl
cnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0
ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlv
biwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24g
YnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUg
dW5sYXdmdWwuDQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2AE5EXMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3
b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp
dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxmb250IHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpNeSB1bmRlcnN0YW5kaW5nIGFs
c28gd2FzIHRoYXQgd2UgYWdyZWVkIHRoYXQgQ0NBUCB3YXMgbm90IGFuIGFsdGVybmF0aXZl
IHRvIElDRS48YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208
L2I+OiBKb25hdGhhbiBMZW5ub3ggW21haWx0bzpqb25hdGhhbkB2aWR5by5jb21dDQo8YnI+
DQo8Yj5TZW50PC9iPjogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDAxOjA2IFBNIENlbnRy
YWwgU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvPC9iPjogRmxlbW1pbmcgQW5kcmVhc2VuICZs
dDtmYW5kcmVhc0BjaXNjby5jb20mZ3Q7IDxicj4NCjxiPkNjPC9iPjogbW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbSAmbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDs7
IEFuZHJldyBBbGxlbjsgbW11c2ljQGlldGYub3JnICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7
DQo8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtNTVVTSUNdIFJFIDogSS1EIEFjdGlvbjog
ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50eHQNCjxicj4N
CjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE1hciAx
NCwgMjAxMywgYXQgMTo0MyBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuIHdyb3RlOjwvZGl2Pg0K
PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYi
IHRleHQ9IiMwMDAwMDAiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzE0
LzEzIDExOjQwIEFNLCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm
PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNp
dGU9Im1pZDo5NEM2ODI5MzFDMDhCMDQ4QjdBODY0NTMwM0ZEQzlGMzZFQjczNTY4ODBAUFVF
WENCMUIubmFudGVycmUuZnJhbmNldGVsZWNvbS5mciIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRp
cj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xhc3M9Ijk2NDA5MzYxNS0xNDAzMjAxMyI+
PGZvbnQgY29sb3I9IiMwMDAwZmYiIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj5SZS0s
PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bh
biBjbGFzcz0iOTY0MDkzNjE1LTE0MDMyMDEzIj48L3NwYW4+Jm5ic3A7PC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xhc3M9Ijk2NDA5MzYxNS0xNDAzMjAx
MyI+PGZvbnQgY29sb3I9IiMwMDAwZmYiIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj5X
aGF0IGlzIGltcG9ydGFudCBpcyB0aGUgcXVhbGl0eSBvZiBwcm9kdWNlZCBkb2N1bWVudHMu
IFRoZSBjb250ZW50IG9mIHRoZSBkb2N1bWVudCBpcyBub3QgZnJvemVuIGFuZCB1bmxlc3Mg
SSdtIG1pc3Rha2VuIHRoZXJlIGlzIG5vdCBJRVRGIExDLjwvZm9udD48L3NwYW4+PC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xhc3M9Ijk2NDA5MzYxNS0x
NDAzMjAxMyI+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KQ29ycmVjdC4g
PGJyPg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjk0QzY4MjkzMUMwOEIwNDhCN0E4NjQ1MzAz
RkRDOUYzNkVCNzM1Njg4MEBQVUVYQ0IxQi5uYW50ZXJyZS5mcmFuY2V0ZWxlY29tLmZyIiB0
eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0i
OTY0MDkzNjE1LTE0MDMyMDEzIj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQ291cmll
ciBOZXciIHNpemU9IjIiPldoYXQgSSB1bmRlcnN0YW5kIGZyb20gdGhlIHRleHQgaW4gdGhl
IGRyYWZ0IGlzOiBjY2FwIGlzIGFsbG93ZWQgdG8gc2lnbmFsIGFuIElQdjRAIGFuZCBJUHY2
QCBpZiBJQ0UgaXMgbm90IHN1cHBvcnRlZC48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBk
aXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuIGNsYXNzPSI5NjQwOTM2MTUtMTQwMzIwMTMi
Pjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCmNjYXAgaXMgbm90IHByb2hp
Yml0ZWQgZnJvbSBkb2luZyBzbyBpbiB0aGUgYWJzZW5jZSBvZiBJQ0UsIGhvd2V2ZXIgYXMg
ZXhwbGFpbmVkIGluIHRoZSBkb2N1bWVudDxicj4NCjEpIFdoZW4gdGhlIElFVEYgU3RhbmRh
cmQgVHJhY2sgbWVjaGFuaXNtIElDRSBpcyBhdmFpbGFibGUsIGNjYXAgTVVTVCBOT1Qgc2ln
bmFsIGFuIElQdjQvSVBWNiBhZGRyZXNzIGFsdGVybmF0aXZlLjxicj4NCjIpIFRoZSBkcmFm
dCBkb2VzIChpbnRlbnRpb25hbGx5KSBub3QgcHJvdmlkZSBhIGZ1bGwgc29sdXRpb24gZm9y
IG5lZ290aWF0aW5nIGFsdGVybmF0aXZlIElQLWFkZHJlc3NlcyBzaW5jZSB3ZSBoYXZlIGEg
U3RhbmRhcmRzIFRyYWNrIG1lY2hhbmlzbSBmb3IgZG9pbmcgc28gKElDRSkuDQo8YnI+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkhpLCBGbGVt
aW5nIC0tPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NeSB1bmRlcnN0YW5kaW5n
IG9mIHRoZSBXRyBjb25zZW5zdXMgLS0gYW5kIG15IGludGVycHJldGF0aW9uIG9mIHRoZSB0
ZXh0IGluIHRoZSBkcmFmdCAtLSB3YXMgc3Ryb25nZXIgdGhhbiB0aGlzOiBjY2FwIE1VU1Qg
Tk9UIGJlIHVzZWQgZm9yIHRoZSBraW5kcyBvZiBhbHRlcm5hdGl2ZXMgSUNFIGNhbiBleHBy
ZXNzLCB3aGV0aGVyIG9yIG5vdCBJQ0UgaXMgYWN0dWFsbHkgYmVpbmcgdXNlZCBpbiBhIHBh
cnRpY3VsYXIgb2ZmZXIvYW5zd2VyLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
SWYgd2UncmUgZ2V0dGluZyBkaXZlcmdlbnQgaW50ZXJwcmV0YXRpb25zIG9mIHRoaXMgZG9j
dW1lbnQsIHdlIHByb2JhYmx5IGRvIG5lZWQgdG8gdXBkYXRlIGl0cyB0ZXh0LjwvZGl2Pg0K
PC9kaXY+DQo8YnI+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIj48c3BhbiBj
bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJh
dGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh
bnM6IDI7IHRleHQtYWxpZ246IGF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlv
bnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1zaXplOiBtZWRpdW07ICI+PHNw
YW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNl
cGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv
cnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRp
Y2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDog
bm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPg0KPGRpdiBzdHlsZT0id29y
ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt
bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQotLTwvZGl2Pg0KPGRpdiBzdHls
ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13
ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQpKb25hdGhhbiBMZW5u
b3g8YnI+DQo8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2
aWR5by5jb208L2E+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0K
PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRp
bmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp
b24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQg
YnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2Vz
KSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRo
aXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw
aWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz
c2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIg
YW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlz
c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFu
c21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFu
ZCBtYXkgYmUgdW5sYXdmdWwuDQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2AE5EXMB104ADSrimnet_--

From thomas.stach@siemens-enterprise.com  Thu Mar 14 11:16:57 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C0511E80E9 for ; Thu, 14 Mar 2013 11:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwq9dhljpHwB for ; Thu, 14 Mar 2013 11:16:56 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E0A6E11E81C6 for ; Thu, 14 Mar 2013 11:16:55 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F13F423F04C7; Thu, 14 Mar 2013 19:16:54 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 19:16:54 +0100
From: "Stach, Thomas" 
To: Andrew Allen , "jonathan@vidyo.com" , "fandreas@cisco.com" 
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOILR4FRB+udTQGku/nF8/mU+ospillH4AgAAMq4CAAADiAIAABM+AgAAiZgCAAAZvAP//rVJAgAAA0XA=
Date: Thu, 14 Mar 2013 18:16:54 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE12067976D4MCHP04MSXglobal_"
MIME-Version: 1.0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 18:16:57 -0000

--_000_F81CEE99482EFE438DAE2A652361EE12067976D4MCHP04MSXglobal_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is also my understanding
... although my initially proposed text does not reflect this correctly.

Regards
Thomas


________________________________
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im Auftrag vo=
n Andrew Allen
Gesendet: Donnerstag, 14. M=E4rz 2013 14:10
An: jonathan@vidyo.com; fandreas@cisco.com
Cc: mmusic@ietf.org
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt


My understanding also was that we agreed that CCAP was not an alternative t=
o ICE.


From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen 
Cc: mohamed.boucadair@orange.com ; Andrew All=
en; mmusic@ietf.org 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt


On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.
What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).

Hi, Fleming --

My understanding of the WG consensus -- and my interpretation of the text i=
n the draft -- was stronger than this: ccap MUST NOT be used for the kinds =
of alternatives ICE can express, whether or not ICE is actually being used =
in a particular offer/answer.

If we're getting divergent interpretations of this document, we probably do=
 need to update its text.

--
Jonathan Lennox
jonathan@vidyo.com


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--_000_F81CEE99482EFE438DAE2A652361EE12067976D4MCHP04MSXglobal_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Thi=
s is also my understanding



...=
 although my initially proposed text does not reflect this correctly.


 


Regards

Thomas 


 









Von: mmusic-bounces@ietf.org [mailt=
o:mmusic-bounces@ietf.org]
Im Auftrag von Andrew Allen

Gesendet: Donnerstag, 14. M=E4rz 2013 14:10

An: jonathan@vidyo.com; fandreas@cisco.com

Cc: mmusic@ietf.org

Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscell=
aneous-caps-04.txt









My understanding also was that we agreed that CCAP was not an alternative t=
o ICE.



 



From=
: Jonathan Lennox [mailto:jonathan@vidyo.com]


Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time

To: Flemming Andreasen <fandreas@cisco.com> 

Cc: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>=
;; Andrew Allen; mmusic@ietf.org <mmusic@ietf.org>


Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscell=
aneous-caps-04.txt


 








On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:








On 3/14/13 11:40 AM, 
mohamed.boucadair@orange.com wrote:






Re-,


 


What is important is the qu=
ality of produced documents. The content of the document is not frozen and =
unless I'm mistaken there is not IETF LC.


<=
font color=3D"#0000ff" size=3D"2" face=3D"Arial">





Correct. 




What I understand from the =
text in the draft is: ccap is allowed to signal an IPv4@ and IPv6@ if ICE i=
s not supported.


<=
font color=3D"#0000ff" size=3D"2" face=3D"Arial">





ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document

1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.

2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).












Hi, Fleming --







My understanding of the WG consensus -- and my interpretation of the t=
ext in the draft -- was stronger than this: ccap MUST NOT be used for the k=
inds of alternatives ICE can express, whether or not ICE is actually being =
used in a particular offer/answer.







If we're getting divergent interpretations of this document, we probab=
ly do need to update its text.









--



Jonathan Lennox

jonathan@vidyo.com









--------------------------------------------------------------------- 

This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 



--_000_F81CEE99482EFE438DAE2A652361EE12067976D4MCHP04MSXglobal_--

From worley@shell01.TheWorld.com  Thu Mar 14 12:30:04 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A311E812C for ; Thu, 14 Mar 2013 12:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 u74LlXrCsPUU for ; Thu, 14 Mar 2013 12:30:03 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8481711E80BF for ; Thu, 14 Mar 2013 12:30:03 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2EJTtmR013201 for ; Thu, 14 Mar 2013 15:29:57 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2EJTtnC431040 for ; Thu, 14 Mar 2013 14:29:55 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2EJTtPH441735; Thu, 14 Mar 2013 15:29:55 -0400 (EDT)
Date: Thu, 14 Mar 2013 15:29:55 -0400 (EDT)
Message-Id: <201303141929.r2EJTtPH441735@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com)
References: <9F33F40F6F2CD847824537F3C4E37DDF06899CEF@MCHP04MSX.global-ad.net>
Subject: Re: [MMUSIC] Bundle, TURN and Legacy Interop
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 19:30:04 -0000

> From: "Hutton, Andrew" 
> 
> It seems that one of the motivations of the current bundle-03
> proposal is that the first offer is compatible with a legacy device
> and that a second offer is required for bundle (See
> http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).

It seems to me that this is suboptimal from the point of view of
connection establishment.  It's not difficult to arrange an offer that
is compatible with both a legacy endpoint (except for perhaps TURN ICE
candidates for the fallback "constituent" ports) and with a supporting
endpoint.  The essential thing is to have a separate bundle m= line so
you can in effect offer both the bundle and the constituents
simultaneously.

If the offerer discovers that it is talking to a legacy endpoint, it
can update the offer with TURN ICE candidates for the constituent
ports.  (If the offerer doesn't want to have to reoffer for legacy
endpoints, it can preallocate enough TURN candidates.)

The result is that you can establish communication with supporting
endpoints in one offer/answer cycle, and the offerer chooses between
needing a reoffer for legacy endpoints when TURN is required
vs. preallocating enough TURN relays.

I don't see a reason to optimize the offer/answer technique to slow
down connection to supporting endpoints and speed it up for legacy
endpoints.

Dale

From fandreas@cisco.com  Thu Mar 14 12:45:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0180D11E8231 for ; Thu, 14 Mar 2013 12:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.698
X-Spam-Level: 
X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, MANGLED_NOTICE=2.3, 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 bHaP9a0eRDdB for ; Thu, 14 Mar 2013 12:45:38 -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 6952E11E8166 for ; Thu, 14 Mar 2013 12:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34503; q=dns/txt; s=iport; t=1363290338; x=1364499938; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Oo9JeRvDeJsy1XTvPSN5pW6lXrAbKuXI7QbCUzCjWww=; b=mMq0Hl/r1RNSzkHnWbAQEnCsYZOyNA31xExRUxC5lzS66EGxk/Yg0MDT cqQyk00kAlwe4RssYsiO0eBfbJpPZ0YFDJIjkbQNC7odsvWC1lR6inAAe NZsNSfGCyhFUU83ktLHb29N1dhFUOibnzJhiTx+swzqg+RaIIY7cnoTbj M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAA8oQlGtJXG//2dsb2JhbABDhByJa7Z7gWUWdIIrAQEBBG4KARALEQQBAQEJFgEBBgcJAwIBAgE0CQgGDQEFAgEBBRKHeQzBaY8LAQoGAYNAA5ZYkQKBVIFSIA
X-IronPort-AV: E=Sophos;i="4.84,846,1355097600";  d="scan'208,217";a="187589386"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 19:45:37 +0000
Received: from bxb-vpn3-830.cisco.com (bxb-vpn3-830.cisco.com [10.86.251.62]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJjaMO002591; Thu, 14 Mar 2013 19:45:36 GMT
Message-ID: <514228DF.8060303@cisco.com>
Date: Thu, 14 Mar 2013 15:45:35 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Stach, Thomas" 
References:   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080902050101060401070506"
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 19:45:40 -0000

This is a multi-part message in MIME format.
--------------080902050101060401070506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As to ccap not being an alternative to ICE we are all in agreement on 
that - the lack of port negotiation alone makes that clear (it simply 
doesn't work without that).

As to ccap being explicitly forbidden to express IP4 and/or IP6 
addresses as alternatives, can somebody please point me to either 
meeting minutes or mailing list discussion to that effect ? The only 
thing I have found is the port discussion we had in Taipei, where we 
agreed not to add a port capability. From 
http://www.ietf.org/proceedings/82/minutes/mmusic.htm:


Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)

=====================================================================

draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt 


Simo presented hisslides 
.

Simo explained the need to be able to indicate alternative port numbers, 
but PSTN media, port number doesn't make sense. The CS draft says use 
port number 9 (the discard port). We have to put something there because 
required by SDP syntax. If an RTP stream is offered, then a regular port 
number should be written instead. The problem arises when both CS and 
RTP streams are offered at the same time, one as an alternative of the 
other. Then, the port number makes sense for RTP but not for CS, but 
still, there is a single place to write the port number in the SDP, so, 
has to be shared by both alternative media streams.

Possible solutions:

1. Circuit-switched media uses the same port as RTP media even though 
the port is not really used

2. Extend capneg with a port number capability attribute, restricting 
its use to cases where ICE cannot be used.

3.Select anything as a port number and say "do not care on reception".

Jonathan Lennox suggested saying that port numbers not equal 0 have to 
be ignored.

Hadriel Kaplan asked if middle boxes not supporting this stuff can be 
broken. The discussion is moved offline.

There are questions on how could be possible to indicate preference for 
one media stream above the alternative.

Miguel Garcia suggested using port 9 if it works. If not take anything 
not equal 0. Receiver has to ignore.

In general, there was pushback on the port negotiation approach. The 
authors should explore a solution along the third option: write the RTP 
port number in the "m=" line. If CS alternative is chosen, discard the 
port number on reception.



Apart from that, the only thing I'm aware of is the 4 WG versions of 
this draft which have all said the same about IP4/IP6 and ICE, and 
again, that text was both WGLC'ed and reviewed by 2 volunteers without 
any concerns. Where does the alternate understanding come from ?

Thanks

-- Flemming



On 3/14/13 2:16 PM, Stach, Thomas wrote:
> This is also my understanding
> ... although my initially proposed text does not reflect this correctly.
> Regards
> Thomas
>
>     ------------------------------------------------------------------------
>     *Von:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>     *Im Auftrag von *Andrew Allen
>     *Gesendet:* Donnerstag, 14. März 2013 14:10
>     *An:* jonathan@vidyo.com; fandreas@cisco.com
>     *Cc:* mmusic@ietf.org
>     *Betreff:* Re: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>
>     My understanding also was that we agreed that CCAP was not an
>     alternative to ICE.
>
>
>     *From*: Jonathan Lennox [mailto:jonathan@vidyo.com]
>     *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard Time
>     *To*: Flemming Andreasen 
>     *Cc*: mohamed.boucadair@orange.com ;
>     Andrew Allen; mmusic@ietf.org 
>     *Subject*: Re: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>
>     On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:
>
>>     On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
>>>     Re-,
>>>     What is important is the quality of produced documents. The
>>>     content of the document is not frozen and unless I'm mistaken
>>>     there is not IETF LC.
>>>
>>     Correct.
>>>     What I understand from the text in the draft is: ccap is allowed
>>>     to signal an IPv4@ and IPv6@ if ICE is not supported.
>>>
>>     ccap is not prohibited from doing so in the absence of ICE,
>>     however as explained in the document
>>     1) When the IETF Standard Track mechanism ICE is available, ccap
>>     MUST NOT signal an IPv4/IPV6 address alternative.
>>     2) The draft does (intentionally) not provide a full solution for
>>     negotiating alternative IP-addresses since we have a Standards
>>     Track mechanism for doing so (ICE).
>
>     Hi, Fleming --
>
>     My understanding of the WG consensus -- and my interpretation of
>     the text in the draft -- was stronger than this: ccap MUST NOT be
>     used for the kinds of alternatives ICE can express, whether or not
>     ICE is actually being used in a particular offer/answer.
>
>     If we're getting divergent interpretations of this document, we
>     probably do need to update its text.
>
>     --
>     Jonathan Lennox
>     jonathan@vidyo.com 
>
>
>     ---------------------------------------------------------------------
>     This transmission (including any attachments) may contain
>     confidential information, privileged material (including material
>     protected by the solicitor-client or other applicable privileges),
>     or constitute non-public information. Any use of this information
>     by anyone other than the intended recipient is prohibited. If you
>     have received this transmission in error, please immediately reply
>     to the sender and delete this information from your system. Use,
>     dissemination, distribution, or reproduction of this transmission
>     by unintended recipients is not authorized and may be unlawful. 
>


--------------080902050101060401070506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    As to ccap not being an alternative to ICE we are all in agreement
    on that - the lack of port negotiation alone makes that clear (it
    simply doesn't work without that). 

    

    As to ccap being explicitly forbidden to express IP4 and/or IP6
    addresses as alternatives, can somebody please point me to either
    meeting minutes or mailing list discussion to that effect ? The only
    thing I have found is the port discussion we had in Taipei, where we
    agreed not to add a port capability. From
    http://www.ietf.org/proceedings/82/minutes/mmusic.htm:

    <quote>

    
    
Miscellaneous Capabilities
        Negotiation in SDP (Simo Veikkolainen, 10)

    
=====================================================================

    
draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt

    
 

    
Simo presented his slides.

    
 

    
Simo explained the need to be
        able to indicate alternative port numbers, but PSTN media, port
        number doesn't make sense. The CS draft says use port number 9
        (the discard port). We have to put something there because
        required by SDP syntax. If an RTP stream is offered, then a
        regular port number should be written instead. The problem
        arises when both CS and RTP streams are offered at the same
        time, one as an alternative of the other. Then, the port number
        makes sense for RTP but not for CS, but still, there is a single
        place to write the port number in the SDP, so, has to be shared
        by both alternative media streams.

    
 

    
Possible solutions:

    
 

    
1. Circuit-switched media
        uses the same port as RTP media even though the port is not
        really used

    
2. Extend capneg with a port
        number capability attribute, restricting its use to cases where
        ICE cannot be used.

    
3.  Select anything
        as a port number and say "do not care on reception".

    
 

    
Jonathan Lennox
        suggested saying that port numbers not equal 0 have to be
        ignored.

    
 

    
Hadriel Kaplan
        asked if middle boxes not supporting this stuff can be broken.
        The discussion is moved offline.

    
 

    
There are
        questions on how could be possible to indicate preference for
        one media stream above the alternative.

    
 

    
Miguel Garcia
        suggested using port 9 if it works. If not take anything not
        equal 0. Receiver has to ignore.

    
 

    
In general,
        there was pushback on the port negotiation approach. The authors
        should explore a solution along the third option: write the RTP
        port number in the "m=" line. If CS alternative is chosen,
        discard the port number on reception.

        </quote>

      

    

    Apart from that, the only thing I'm aware of is the 4 WG versions of
    this draft which have all said the same about IP4/IP6 and ICE, and
    again, that text was both WGLC'ed and reviewed by 2 volunteers
    without any concerns. Where does the alternate understanding come
    from ? 

    

    Thanks 

    

    -- Flemming 

    

    

    

    
On 3/14/13 2:16 PM, Stach, Thomas
      wrote:

    

    

      
      
      
This
            is also my understanding
          

      
...
            although my initially proposed text does not reflect this
            correctly.

      
 

      
Regards

          Thomas 

      
 

      

      

        

          

          Von:
            mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
            Im Auftrag von Andrew Allen

            Gesendet: Donnerstag, 14. März 2013 14:10

            An: jonathan@vidyo.com; fandreas@cisco.com

            Cc: mmusic@ietf.org

            Betreff: Re: [MMUSIC] RE : I-D Action:
            draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          

        

        

          My understanding also was that we agreed that CCAP was not an
          alternative to ICE.

        

         

        

          From: Jonathan Lennox
            [mailto:jonathan@vidyo.com]
            

            Sent: Thursday, March 14, 2013 01:06 PM Central
            Standard Time

            To: Flemming Andreasen <fandreas@cisco.com> 

            Cc: mohamed.boucadair@orange.com
            <mohamed.boucadair@orange.com>; Andrew Allen;
            mmusic@ietf.org <mmusic@ietf.org>
            

            Subject: Re: [MMUSIC] RE : I-D Action:
            draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
            

           

        

        

        

          
On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

          

          

            

              
On 3/14/13 11:40 AM, 
                  mohamed.boucadair@orange.com wrote:

              

              

                
Re-,

                
 

                
What is important is
                      the quality of produced documents. The content of
                      the document is not frozen and unless I'm mistaken
                      there is not IETF LC.

                


                

              

              Correct. 

              

                
What I understand from
                      the text in the draft is: ccap is allowed to
                      signal an IPv4@ and IPv6@ if ICE is not supported.

                


                

              

              ccap is not prohibited from doing so in the absence of
              ICE, however as explained in the document

              1) When the IETF Standard Track mechanism ICE is
              available, ccap MUST NOT signal an IPv4/IPV6 address
              alternative.

              2) The draft does (intentionally) not provide a full
              solution for negotiating alternative IP-addresses since we
              have a Standards Track mechanism for doing so (ICE).
              

            

          

          


          

          
Hi, Fleming --

          


          

          
My understanding of the WG consensus -- and my
            interpretation of the text in the draft -- was stronger than
            this: ccap MUST NOT be used for the kinds of alternatives
            ICE can express, whether or not ICE is actually being used
            in a particular offer/answer.

          


          

          
If we're getting divergent interpretations of this
            document, we probably do need to update its text.

        

        

        

              

                --

              

                Jonathan Lennox

                jonathan@vidyo.com

                

              

            

        

        ---------------------------------------------------------------------
        

        This transmission (including any attachments) may contain
        confidential information, privileged material (including
        material protected by the solicitor-client or other applicable
        privileges), or constitute non-public information. Any use of
        this information by anyone other than the intended recipient is
        prohibited. If you have received this transmission in error,
        please immediately reply to the sender and delete this
        information from your system. Use, dissemination, distribution,
        or reproduction of this transmission by unintended recipients is
        not authorized and may be unlawful. 

    

    

  


--------------080902050101060401070506--

From prvs=27852b12f4=aallen@blackberry.com  Thu Mar 14 12:51:06 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D011E8103 for ; Thu, 14 Mar 2013 12:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.148
X-Spam-Level: 
X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 2Fjd3JLvHvnG for ; Thu, 14 Mar 2013 12:51:05 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B911E8256 for ; Thu, 14 Mar 2013 12:51:01 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-7e-51422a22cb6f
Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id 8B.50.09265.22A22415; Thu, 14 Mar 2013 14:50:58 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 14:50:57 -0500
From: Andrew Allen 
To: "fandreas@cisco.com" , "thomas.stach@siemens-enterprise.com" 
Thread-Topic: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOILR4FRB+udTQGku/nF8/mU+ospillH4AgAAMq4CAAADiAIAABM+AgAAiZgCAAAZvAP//rVJAgAAA0XCAAG2UgP//raw8
Date: Thu, 14 Mar 2013 19:50:56 +0000
Message-ID: 
In-Reply-To: <514228DF.8060303@cisco.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D2B01CXMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLKsWRmVeSWpSXmKPExsXC5Zyvrauk5RRosPOctMX7C7oW+xefZ7aY uvwxi8Wu7TUOLB5Tfm9k9Viy5CeTx43b75k92p7dYQ9giWpgtElKLCkLzkzP07ezSczLyy9J LElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknMzE0tUlLITLFVMlFSKMhJTE7NTc0rsVVK LChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6hkp2ugmdPBnvZl9kK7j2nKni 7JvJzA2MS+4xdTFyckgImEicWv2QHcIWk7hwbz1bFyMXh5DASkaJv8eWsEI4mxklbr/ZxghS xSagJbH/8HSwbhGBGomLV9+C2cwCIRKHnr8F6ubgEBaIkZj9vQSiJFZi0oweFgg7T+L61rvM IDaLgKrE9q/XwRbzCnhINLz4ywZicwpoSjRufMEKYjMKyErsPnsdary4xK0n86GOFpBYsuc8 M4QtKvHy8T9WCFtR4u/e76wQ9fkSbcf+MkLMF5Q4OfMJywRGkVlIRs1CUjYLSdksoA+Ygc5Y v0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxgFczOKDcwMkvOS9Yoyc/XyUks2MYKSjKOG/g7G t+8tDjEKcDAq8fDGqTgFCrEmlhVX5h5ilOBgVhLh3fXXMVCINyWxsiq1KD++qDQntfgQYxAw gCYyS3En5wMTYF5JvLGBAZEcJXHeMk2gJQLpwESWnZpakFoEM5SJgxNkKZeUSDEwHaUWJZaW ZMSDkmZ8MTBtSjUwekftqDHyncy8YMmxyYXnBA/v6L+2VG+r7bsaqZeNH/szlsg8F074sUwk Q3KOAcuNzUy9UvXH75b1nNfMk9/9J3CyTaGN+Ox7IT7KD1wmRu7k+npdW6yd+f966yUvDL3f J20LE1k9lduhUeLlK6unStYNng++s56N/rLeiOHtkTttU0Uf9s3MUmIpzkg01GIuKk4EAK8s 2KeAAwAA
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 19:51:06 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2B01CXMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpJIGFtIG5vdCBzdXJlIGlmIGFueXRoaW5nIGlzIHJlY29yZGVkIGluIGFueSBtaW51dGVz
IGJ1dCB3ZSBoYWQgYW4gb2ZmbGluZSBkaXNjdXNzaW9uIHRvIHJlbW92ZSB0aGUgcm9hZGJs
b2NrIG9uIHRoaXMgd2l0aCBKb25hdGhhbiB0byBhZGRyZXNzIGhpcyBjb25jZXJuIHRoYXQg
dGhpcyB3YXMgYSBwb3RlbnRpYWwgYWx0ZXJuYXRpdmUgdG8gSUNFIGFuZCBhZGRyZXNzZWQg
dGhpcyB3aXRoIHRoZSBjdXJyZW50IHRleHQuIFRoaXMgdGV4dCBhbmQgdGhlIHJlYXNvbiBi
ZWhpbmQgaXQgSSB0aGluayB3YXMgcG9pbnRlZCBvdXQgb24gdGhlIGxpc3QgZHVyaW5nIFF1
ZWJlYyBvciBzaG9ydGx5IGFmdGVyLg0KDQoNCkZyb206IEZsZW1taW5nIEFuZHJlYXNlbiBb
bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNCwg
MjAxMyAwMjo0NSBQTSBDZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBTdGFjaCwgVGhvbWFz
IDx0aG9tYXMuc3RhY2hAc2llbWVucy1lbnRlcnByaXNlLmNvbT4NCkNjOiBBbmRyZXcgQWxs
ZW47IGpvbmF0aGFuQHZpZHlvLmNvbSA8am9uYXRoYW5AdmlkeW8uY29tPjsgbW11c2ljQGll
dGYub3JnIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQVc6IFtNTVVTSUNdIFJF
IDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fw
cy0wNC50eHQNCg0KQXMgdG8gY2NhcCBub3QgYmVpbmcgYW4gYWx0ZXJuYXRpdmUgdG8gSUNF
IHdlIGFyZSBhbGwgaW4gYWdyZWVtZW50IG9uIHRoYXQgLSB0aGUgbGFjayBvZiBwb3J0IG5l
Z290aWF0aW9uIGFsb25lIG1ha2VzIHRoYXQgY2xlYXIgKGl0IHNpbXBseSBkb2Vzbid0IHdv
cmsgd2l0aG91dCB0aGF0KS4NCg0KQXMgdG8gY2NhcCBiZWluZyBleHBsaWNpdGx5IGZvcmJp
ZGRlbiB0byBleHByZXNzIElQNCBhbmQvb3IgSVA2IGFkZHJlc3NlcyBhcyBhbHRlcm5hdGl2
ZXMsIGNhbiBzb21lYm9keSBwbGVhc2UgcG9pbnQgbWUgdG8gZWl0aGVyIG1lZXRpbmcgbWlu
dXRlcyBvciBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB0byB0aGF0IGVmZmVjdCA/IFRoZSBv
bmx5IHRoaW5nIEkgaGF2ZSBmb3VuZCBpcyB0aGUgcG9ydCBkaXNjdXNzaW9uIHdlIGhhZCBp
biBUYWlwZWksIHdoZXJlIHdlIGFncmVlZCBub3QgdG8gYWRkIGEgcG9ydCBjYXBhYmlsaXR5
LiBGcm9tIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvbWludXRlcy9tbXVz
aWMuaHRtOg0KPHF1b3RlPg0KTWlzY2VsbGFuZW91cyBDYXBhYmlsaXRpZXMgTmVnb3RpYXRp
b24gaW4gU0RQIChTaW1vIFZlaWtrb2xhaW5lbiwgMTApDQo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCmRy
YWZ0LWdhcmNpYS1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wMC50eHQ8aHR0cDov
L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3Vz
LWNhcHMtMDAudHh0Pg0KDQpTaW1vIHByZXNlbnRlZCBoaXMgc2xpZGVzPGh0dHA6Ly93d3cu
aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvc2xpZGVzL21tdXNpYy04LnBwdHg+Lg0KDQpTaW1v
IGV4cGxhaW5lZCB0aGUgbmVlZCB0byBiZSBhYmxlIHRvIGluZGljYXRlIGFsdGVybmF0aXZl
IHBvcnQgbnVtYmVycywgYnV0IFBTVE4gbWVkaWEsIHBvcnQgbnVtYmVyIGRvZXNuJ3QgbWFr
ZSBzZW5zZS4gVGhlIENTIGRyYWZ0IHNheXMgdXNlIHBvcnQgbnVtYmVyIDkgKHRoZSBkaXNj
YXJkIHBvcnQpLiBXZSBoYXZlIHRvIHB1dCBzb21ldGhpbmcgdGhlcmUgYmVjYXVzZSByZXF1
aXJlZCBieSBTRFAgc3ludGF4LiBJZiBhbiBSVFAgc3RyZWFtIGlzIG9mZmVyZWQsIHRoZW4g
YSByZWd1bGFyIHBvcnQgbnVtYmVyIHNob3VsZCBiZSB3cml0dGVuIGluc3RlYWQuIFRoZSBw
cm9ibGVtIGFyaXNlcyB3aGVuIGJvdGggQ1MgYW5kIFJUUCBzdHJlYW1zIGFyZSBvZmZlcmVk
IGF0IHRoZSBzYW1lIHRpbWUsIG9uZSBhcyBhbiBhbHRlcm5hdGl2ZSBvZiB0aGUgb3RoZXIu
IFRoZW4sIHRoZSBwb3J0IG51bWJlciBtYWtlcyBzZW5zZSBmb3IgUlRQIGJ1dCBub3QgZm9y
IENTLCBidXQgc3RpbGwsIHRoZXJlIGlzIGEgc2luZ2xlIHBsYWNlIHRvIHdyaXRlIHRoZSBw
b3J0IG51bWJlciBpbiB0aGUgU0RQLCBzbywgaGFzIHRvIGJlIHNoYXJlZCBieSBib3RoIGFs
dGVybmF0aXZlIG1lZGlhIHN0cmVhbXMuDQoNClBvc3NpYmxlIHNvbHV0aW9uczoNCg0KMS4g
Q2lyY3VpdC1zd2l0Y2hlZCBtZWRpYSB1c2VzIHRoZSBzYW1lIHBvcnQgYXMgUlRQIG1lZGlh
IGV2ZW4gdGhvdWdoIHRoZSBwb3J0IGlzIG5vdCByZWFsbHkgdXNlZA0KMi4gRXh0ZW5kIGNh
cG5lZyB3aXRoIGEgcG9ydCBudW1iZXIgY2FwYWJpbGl0eSBhdHRyaWJ1dGUsIHJlc3RyaWN0
aW5nIGl0cyB1c2UgdG8gY2FzZXMgd2hlcmUgSUNFIGNhbm5vdCBiZSB1c2VkLg0KMy4gIFNl
bGVjdCBhbnl0aGluZyBhcyBhIHBvcnQgbnVtYmVyIGFuZCBzYXkgImRvIG5vdCBjYXJlIG9u
IHJlY2VwdGlvbiIuDQoNCkpvbmF0aGFuIExlbm5veCBzdWdnZXN0ZWQgc2F5aW5nIHRoYXQg
cG9ydCBudW1iZXJzIG5vdCBlcXVhbCAwIGhhdmUgdG8gYmUgaWdub3JlZC4NCg0KSGFkcmll
bCBLYXBsYW4gYXNrZWQgaWYgbWlkZGxlIGJveGVzIG5vdCBzdXBwb3J0aW5nIHRoaXMgc3R1
ZmYgY2FuIGJlIGJyb2tlbi4gVGhlIGRpc2N1c3Npb24gaXMgbW92ZWQgb2ZmbGluZS4NCg0K
VGhlcmUgYXJlIHF1ZXN0aW9ucyBvbiBob3cgY291bGQgYmUgcG9zc2libGUgdG8gaW5kaWNh
dGUgcHJlZmVyZW5jZSBmb3Igb25lIG1lZGlhIHN0cmVhbSBhYm92ZSB0aGUgYWx0ZXJuYXRp
dmUuDQoNCk1pZ3VlbCBHYXJjaWEgc3VnZ2VzdGVkIHVzaW5nIHBvcnQgOSBpZiBpdCB3b3Jr
cy4gSWYgbm90IHRha2UgYW55dGhpbmcgbm90IGVxdWFsIDAuIFJlY2VpdmVyIGhhcyB0byBp
Z25vcmUuDQoNCkluIGdlbmVyYWwsIHRoZXJlIHdhcyBwdXNoYmFjayBvbiB0aGUgcG9ydCBu
ZWdvdGlhdGlvbiBhcHByb2FjaC4gVGhlIGF1dGhvcnMgc2hvdWxkIGV4cGxvcmUgYSBzb2x1
dGlvbiBhbG9uZyB0aGUgdGhpcmQgb3B0aW9uOiB3cml0ZSB0aGUgUlRQIHBvcnQgbnVtYmVy
IGluIHRoZSAibT0iIGxpbmUuIElmIENTIGFsdGVybmF0aXZlIGlzIGNob3NlbiwgZGlzY2Fy
ZCB0aGUgcG9ydCBudW1iZXIgb24gcmVjZXB0aW9uLg0KPC9xdW90ZT4NCg0KQXBhcnQgZnJv
bSB0aGF0LCB0aGUgb25seSB0aGluZyBJJ20gYXdhcmUgb2YgaXMgdGhlIDQgV0cgdmVyc2lv
bnMgb2YgdGhpcyBkcmFmdCB3aGljaCBoYXZlIGFsbCBzYWlkIHRoZSBzYW1lIGFib3V0IElQ
NC9JUDYgYW5kIElDRSwgYW5kIGFnYWluLCB0aGF0IHRleHQgd2FzIGJvdGggV0dMQydlZCBh
bmQgcmV2aWV3ZWQgYnkgMiB2b2x1bnRlZXJzIHdpdGhvdXQgYW55IGNvbmNlcm5zLiBXaGVy
ZSBkb2VzIHRoZSBhbHRlcm5hdGUgdW5kZXJzdGFuZGluZyBjb21lIGZyb20gPw0KDQpUaGFu
a3MNCg0KLS0gRmxlbW1pbmcNCg0KDQoNCk9uIDMvMTQvMTMgMjoxNiBQTSwgU3RhY2gsIFRo
b21hcyB3cm90ZToNClRoaXMgaXMgYWxzbyBteSB1bmRlcnN0YW5kaW5nDQouLi4gYWx0aG91
Z2ggbXkgaW5pdGlhbGx5IHByb3Bvc2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGlzIGNv
cnJlY3RseS4NCg0KUmVnYXJkcw0KVGhvbWFzDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClZvbjogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp
Yy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBJ
bSBBdWZ0cmFnIHZvbiBBbmRyZXcgQWxsZW4NCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAxNC4g
TcOkcnogMjAxMyAxNDoxMA0KQW46IGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRo
YW5AdmlkeW8uY29tPjsgZmFuZHJlYXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNj
by5jb20+DQpDYzogbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpC
ZXRyZWZmOiBSZTogW01NVVNJQ10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNp
Yy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzLTA0LnR4dA0KDQoNCk15IHVuZGVyc3RhbmRpbmcg
YWxzbyB3YXMgdGhhdCB3ZSBhZ3JlZWQgdGhhdCBDQ0FQIHdhcyBub3QgYW4gYWx0ZXJuYXRp
dmUgdG8gSUNFLg0KDQoNCkZyb206IEpvbmF0aGFuIExlbm5veCBbbWFpbHRvOmpvbmF0aGFu
QHZpZHlvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNCwgMjAxMyAwMTowNiBQTSBD
ZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFz
QGNpc2NvLmNvbT48bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbT4NCkNjOiBtb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t
PiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT48bWFpbHRvOm1vaGFtZWQuYm91Y2Fk
YWlyQG9yYW5nZS5jb20+OyBBbmRyZXcgQWxsZW47IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86
bW11c2ljQGlldGYub3JnPiA8bW11c2ljQGlldGYub3JnPjxtYWlsdG86bW11c2ljQGlldGYu
b3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFJFIDogSS1EIEFjdGlvbjogZHJhZnQtaWV0
Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50eHQNCg0KDQpPbiBNYXIgMTQs
IDIwMTMsIGF0IDE6NDMgUE0sIEZsZW1taW5nIEFuZHJlYXNlbiB3cm90ZToNCg0KT24gMy8x
NC8xMyAxMTo0MCBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9o
YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpSZS0sDQoNCldoYXQgaXMgaW1w
b3J0YW50IGlzIHRoZSBxdWFsaXR5IG9mIHByb2R1Y2VkIGRvY3VtZW50cy4gVGhlIGNvbnRl
bnQgb2YgdGhlIGRvY3VtZW50IGlzIG5vdCBmcm96ZW4gYW5kIHVubGVzcyBJJ20gbWlzdGFr
ZW4gdGhlcmUgaXMgbm90IElFVEYgTEMuDQoNCkNvcnJlY3QuDQpXaGF0IEkgdW5kZXJzdGFu
ZCBmcm9tIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBpczogY2NhcCBpcyBhbGxvd2VkIHRvIHNp
Z25hbCBhbiBJUHY0QCBhbmQgSVB2NkAgaWYgSUNFIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCmNj
YXAgaXMgbm90IHByb2hpYml0ZWQgZnJvbSBkb2luZyBzbyBpbiB0aGUgYWJzZW5jZSBvZiBJ
Q0UsIGhvd2V2ZXIgYXMgZXhwbGFpbmVkIGluIHRoZSBkb2N1bWVudA0KMSkgV2hlbiB0aGUg
SUVURiBTdGFuZGFyZCBUcmFjayBtZWNoYW5pc20gSUNFIGlzIGF2YWlsYWJsZSwgY2NhcCBN
VVNUIE5PVCBzaWduYWwgYW4gSVB2NC9JUFY2IGFkZHJlc3MgYWx0ZXJuYXRpdmUuDQoyKSBU
aGUgZHJhZnQgZG9lcyAoaW50ZW50aW9uYWxseSkgbm90IHByb3ZpZGUgYSBmdWxsIHNvbHV0
aW9uIGZvciBuZWdvdGlhdGluZyBhbHRlcm5hdGl2ZSBJUC1hZGRyZXNzZXMgc2luY2Ugd2Ug
aGF2ZSBhIFN0YW5kYXJkcyBUcmFjayBtZWNoYW5pc20gZm9yIGRvaW5nIHNvIChJQ0UpLg0K
DQpIaSwgRmxlbWluZyAtLQ0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBXRyBjb25zZW5z
dXMgLS0gYW5kIG15IGludGVycHJldGF0aW9uIG9mIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCAt
LSB3YXMgc3Ryb25nZXIgdGhhbiB0aGlzOiBjY2FwIE1VU1QgTk9UIGJlIHVzZWQgZm9yIHRo
ZSBraW5kcyBvZiBhbHRlcm5hdGl2ZXMgSUNFIGNhbiBleHByZXNzLCB3aGV0aGVyIG9yIG5v
dCBJQ0UgaXMgYWN0dWFsbHkgYmVpbmcgdXNlZCBpbiBhIHBhcnRpY3VsYXIgb2ZmZXIvYW5z
d2VyLg0KDQpJZiB3ZSdyZSBnZXR0aW5nIGRpdmVyZ2VudCBpbnRlcnByZXRhdGlvbnMgb2Yg
dGhpcyBkb2N1bWVudCwgd2UgcHJvYmFibHkgZG8gbmVlZCB0byB1cGRhdGUgaXRzIHRleHQu
DQoNCi0tDQpKb25hdGhhbiBMZW5ub3gNCmpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9u
YXRoYW5AdmlkeW8uY29tPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Np
b24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFs
IHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxl
IHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFu
eSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo
aXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8g
dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3Rl
bS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBv
ZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1
dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRo
aXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFp
biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1
ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3Ro
ZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGlu
Zm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVy
IHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0
ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZy
b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy
ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGll
bnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2B01CXMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9
IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkkgYW0gbm90IHN1cmUgaWYgYW55dGhpbmcgaXMg
cmVjb3JkZWQgaW4gYW55IG1pbnV0ZXMgYnV0IHdlIGhhZCBhbiBvZmZsaW5lIGRpc2N1c3Np
b24gdG8gcmVtb3ZlIHRoZSByb2FkYmxvY2sgb24gdGhpcyB3aXRoIEpvbmF0aGFuIHRvIGFk
ZHJlc3MgaGlzIGNvbmNlcm4gdGhhdCB0aGlzIHdhcyBhIHBvdGVudGlhbCBhbHRlcm5hdGl2
ZSB0byBJQ0UgYW5kIGFkZHJlc3NlZCB0aGlzIHdpdGggdGhlIGN1cnJlbnQgdGV4dC4gVGhp
cyB0ZXh0IGFuZCB0aGUNCiByZWFzb24gYmVoaW5kIGl0IEkgdGhpbmsgd2FzIHBvaW50ZWQg
b3V0IG9uIHRoZSBsaXN0IGR1cmluZyBRdWViZWMgb3Igc2hvcnRseSBhZnRlci48YnI+DQo8
L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+OiBGbGVtbWluZyBB
bmRyZWFzZW4gW21haWx0bzpmYW5kcmVhc0BjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50PC9i
PjogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDAyOjQ1IFBNIENlbnRyYWwgU3RhbmRhcmQg
VGltZTxicj4NCjxiPlRvPC9iPjogU3RhY2gsIFRob21hcyAmbHQ7dGhvbWFzLnN0YWNoQHNp
ZW1lbnMtZW50ZXJwcmlzZS5jb20mZ3Q7IDxicj4NCjxiPkNjPC9iPjogQW5kcmV3IEFsbGVu
OyBqb25hdGhhbkB2aWR5by5jb20gJmx0O2pvbmF0aGFuQHZpZHlvLmNvbSZndDs7IG1tdXNp
Y0BpZXRmLm9yZyAmbHQ7bW11c2ljQGlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U3ViamVjdDwv
Yj46IFJlOiBBVzogW01NVVNJQ10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNp
Yy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzLTA0LnR4dA0KPGJyPg0KPC9mb250PiZuYnNwOzxi
cj4NCjwvZGl2Pg0KQXMgdG8gY2NhcCBub3QgYmVpbmcgYW4gYWx0ZXJuYXRpdmUgdG8gSUNF
IHdlIGFyZSBhbGwgaW4gYWdyZWVtZW50IG9uIHRoYXQgLSB0aGUgbGFjayBvZiBwb3J0IG5l
Z290aWF0aW9uIGFsb25lIG1ha2VzIHRoYXQgY2xlYXIgKGl0IHNpbXBseSBkb2Vzbid0IHdv
cmsgd2l0aG91dCB0aGF0KS4NCjxicj4NCjxicj4NCkFzIHRvIGNjYXAgYmVpbmcgZXhwbGlj
aXRseSBmb3JiaWRkZW4gdG8gZXhwcmVzcyBJUDQgYW5kL29yIElQNiBhZGRyZXNzZXMgYXMg
YWx0ZXJuYXRpdmVzLCBjYW4gc29tZWJvZHkgcGxlYXNlIHBvaW50IG1lIHRvIGVpdGhlciBt
ZWV0aW5nIG1pbnV0ZXMgb3IgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gdG8gdGhhdCBlZmZl
Y3QgPyBUaGUgb25seSB0aGluZyBJIGhhdmUgZm91bmQgaXMgdGhlIHBvcnQgZGlzY3Vzc2lv
biB3ZSBoYWQgaW4gVGFpcGVpLA0KIHdoZXJlIHdlIGFncmVlZCBub3QgdG8gYWRkIGEgcG9y
dCBjYXBhYmlsaXR5LiBGcm9tIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhy
ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvbWludXRlcy9tbXVzaWMu
aHRtIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvbWludXRlcy9tbXVz
aWMuaHRtPC9hPjo8YnI+DQombHQ7cXVvdGUmZ3Q7PGJyPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAg
bWVkaXVtOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGNvbG9yOiByZ2IoMCwg
MCwgMCk7DQogICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgIHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAg
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7
DQogICAgICAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsNCiAgICAgIGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1
NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgICAgICAgMTBwdDsgZm9u
dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij5NaXNjZWxsYW5lb3VzIENhcGFiaWxpdGllcyBO
ZWdvdGlhdGlvbiBpbiBTRFAgKFNpbW8gVmVpa2tvbGFpbmVuLCAxMCk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICBtZWRpdW07IGZvbnQtZmFtaWx5OiAnVGlt
ZXMgTmV3IFJvbWFuJzsgY29sb3I6IHJnYigwLCAwLCAwKTsNCiAgICAgIGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQog
ICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo
YW5zOiBhdXRvOw0KICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk
b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgIC13ZWJraXQtdGV4dC1zaXpl
LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ow0KICAgICAg
YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOg0KICAgICAgICAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsi
Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAg
ICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdi
KDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQog
ICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog
MHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1
LCAyNTUsIDI1NSk7Ij4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt
Z2FyY2lhLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzLTAwLnR4dCIgc3R5bGU9ImZv
bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6IHB1cnBsZTsNCiAgICAgICAg
dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx
MHB0Ow0KICAgICAgICAgIGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+ZHJhZnQtZ2Fy
Y2lhLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzLTAwLnR4dDwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICBtZWRpdW07IGZv
bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6IHJnYigwLCAwLCAwKTsNCiAg
ICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7DQogICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo
dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgIC13
ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4Ow0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAgICAgICAxMHB0OyBmb250LWZhbWlseTog
J0NvdXJpZXIgTmV3JzsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xv
cjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh
Y2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiBy
Z2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogICAgICAg
IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+U2ltbyBwcmVzZW50ZWQgaGlz
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh
bj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL3NsaWRlcy9t
bXVzaWMtOC5wcHR4IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBj
b2xvcjogcHVycGxlOw0KICAgICAgICB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7DQogICAgICAgICAgZm9udC1mYW1pbHk6ICdD
b3VyaWVyIE5ldyc7Ij5zbGlkZXM8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBO
ZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAg
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6
IGF1dG87DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6
IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRq
dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNr
Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250
LXNpemU6DQogICAgICAgIDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgbWVkaXVtOyBm
b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGNvbG9yOiByZ2IoMCwgMCwgMCk7DQog
ICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOw0KICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln
aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgIHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAt
d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsNCiAgICAgIGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgICAgICAgMTBwdDsgZm9udC1mYW1pbHk6
ICdDb3VyaWVyIE5ldyc7Ij5TaW1vIGV4cGxhaW5lZCB0aGUgbmVlZCB0byBiZSBhYmxlIHRv
IGluZGljYXRlIGFsdGVybmF0aXZlIHBvcnQgbnVtYmVycywgYnV0IFBTVE4gbWVkaWEsIHBv
cnQgbnVtYmVyIGRvZXNuJ3QgbWFrZSBzZW5zZS4gVGhlIENTIGRyYWZ0IHNheXMgdXNlIHBv
cnQgbnVtYmVyIDkgKHRoZSBkaXNjYXJkIHBvcnQpLiBXZSBoYXZlIHRvIHB1dA0KIHNvbWV0
aGluZyB0aGVyZSBiZWNhdXNlIHJlcXVpcmVkIGJ5IFNEUCBzeW50YXguIElmIGFuIFJUUCBz
dHJlYW0gaXMgb2ZmZXJlZCwgdGhlbiBhIHJlZ3VsYXIgcG9ydCBudW1iZXIgc2hvdWxkIGJl
IHdyaXR0ZW4gaW5zdGVhZC4gVGhlIHByb2JsZW0gYXJpc2VzIHdoZW4gYm90aCBDUyBhbmQg
UlRQIHN0cmVhbXMgYXJlIG9mZmVyZWQgYXQgdGhlIHNhbWUgdGltZSwgb25lIGFzIGFuIGFs
dGVybmF0aXZlIG9mIHRoZSBvdGhlci4gVGhlbiwgdGhlIHBvcnQNCiBudW1iZXIgbWFrZXMg
c2Vuc2UgZm9yIFJUUCBidXQgbm90IGZvciBDUywgYnV0IHN0aWxsLCB0aGVyZSBpcyBhIHNp
bmdsZSBwbGFjZSB0byB3cml0ZSB0aGUgcG9ydCBudW1iZXIgaW4gdGhlIFNEUCwgc28sIGhh
cyB0byBiZSBzaGFyZWQgYnkgYm90aCBhbHRlcm5hdGl2ZSBtZWRpYSBzdHJlYW1zLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1p
bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v
cm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10
ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6DQogICAgICAgIDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmll
ciBOZXcnOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAg
ICAgbWVkaXVtOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGNvbG9yOiByZ2Io
MCwgMCwgMCk7DQogICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgIHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAg
ICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw
cHg7DQogICAgICAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsNCiAgICAgIGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs
IDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgICAgICAgMTBwdDsg
Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij5Qb3NzaWJsZSBzb2x1dGlvbnM6PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgbWVkaXVtOyBmb250LWZhbWls
eTogJ1RpbWVzIE5ldyBSb21hbic7IGNvbG9yOiByZ2IoMCwgMCwgMCk7DQogICAgICBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOw0KICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h
bDsgb3JwaGFuczogYXV0bzsNCiAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgIHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAtd2Via2l0LXRl
eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsN
CiAgICAgIGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToNCiAgICAgICAgMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy
IE5ldyc7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6DQogICAg
ICBtZWRpdW07IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6IHJnYigw
LCAwLCAwKTsNCiAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAg
ICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsNCiAgICAgIC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4Ow0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg
MjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAgICAgICAxMHB0OyBm
b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjEuIENpcmN1aXQtc3dpdGNoZWQgbWVkaWEg
dXNlcyB0aGUgc2FtZSBwb3J0IGFzIFJUUCBtZWRpYSBldmVuIHRob3VnaCB0aGUgcG9ydCBp
cyBub3QgcmVhbGx5IHVzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6DQog
ICAgICBtZWRpdW07IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6IHJn
YigwLCAwLCAwKTsNCiAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0K
ICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6
IDBweDsNCiAgICAgIC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4Ow0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1
NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAgICAgICAxMHB0
OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjIuIEV4dGVuZCBjYXBuZWcgd2l0aCBh
IHBvcnQgbnVtYmVyIGNhcGFiaWxpdHkgYXR0cmlidXRlLCByZXN0cmljdGluZyBpdHMgdXNl
IHRvIGNhc2VzIHdoZXJlIElDRSBjYW5ub3QgYmUgdXNlZC48c3BhbiBzdHlsZT0iY29sb3I6
IGJsYWNrOyI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAg
ICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdi
KDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQog
ICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog
MHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1
LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogICAgICAgIDEwcHQ7
IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogYmxhY2s7Ij4zLjxzcGFuPiZu
YnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+U2VsZWN0IGFueXRoaW5nIGFzIGEgcG9ydCBudW1iZXIgYW5kIHNheSAmcXVvdDtk
byBub3QgY2FyZSBvbiByZWNlcHRpb24mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg
Zm9udC1zaXplOg0KICAgICAgbWVkaXVtOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h
bic7IGNvbG9yOiByZ2IoMCwgMCwgMCk7DQogICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgbGV0dGVy
LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsN
CiAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsNCiAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1
dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsNCiAgICAgIGJhY2tncm91bmQt
Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN
CiAgICAgICAgMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiBibGFj
azsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgIG1l
ZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAsIDAs
IDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp
bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFsaWduOiBz
dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0K
ICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs
IDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogICAgICAgIDEwcHQ7IGZvbnQt
ZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogYmxhY2s7Ij5Kb25hdGhhbiBMZW5ub3gg
c3VnZ2VzdGVkIHNheWluZyB0aGF0IHBvcnQgbnVtYmVycyBub3QgZXF1YWwgMCBoYXZlIHRv
IGJlIGlnbm9yZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAg
bWVkaXVtOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGNvbG9yOiByZ2IoMCwg
MCwgMCk7DQogICAgICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgIHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAg
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7
DQogICAgICAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsNCiAgICAgIGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1
NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCiAgICAgICAgMTBwdDsgZm9u
dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp
biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6
ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7
IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0
LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQog
ICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6DQogICAgICAgIDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyBjb2xvcjogYmxhY2s7Ij5IYWRyaWVsIEthcGxhbiBhc2tlZCBpZiBtaWRkbGUgYm94
ZXMgbm90IHN1cHBvcnRpbmcgdGhpcyBzdHVmZiBjYW4gYmUgYnJva2VuLiBUaGUgZGlzY3Vz
c2lvbiBpcyBtb3ZlZCBvZmZsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xv
cjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh
Y2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiBy
Z2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogICAgICAg
IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogYmxhY2s7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICBtZWRpdW07IGZv
bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6IHJnYigwLCAwLCAwKTsNCiAg
ICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7DQogICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo
dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgIC13
ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4Ow0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAgICAgICAxMHB0OyBmb250LWZhbWlseTog
J0NvdXJpZXIgTmV3JzsgY29sb3I6IGJsYWNrOyI+VGhlcmUgYXJlIHF1ZXN0aW9ucyBvbiBo
b3cgY291bGQgYmUgcG9zc2libGUgdG8gaW5kaWNhdGUgcHJlZmVyZW5jZSBmb3Igb25lIG1l
ZGlhIHN0cmVhbSBhYm92ZSB0aGUgYWx0ZXJuYXRpdmUuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOg0KICAgICAgbWVkaXVtOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS
b21hbic7IGNvbG9yOiByZ2IoMCwgMCwgMCk7DQogICAgICBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0
bzsNCiAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsNCiAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0
bzsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6
IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsNCiAgICAgIGJhY2tncm91
bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToNCiAgICAgICAgMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiBi
bGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAg
IG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAs
IDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAgICB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAg
ICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4
Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy
NTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQogICAgICAgIDEwcHQ7IGZv
bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogYmxhY2s7Ij5NaWd1ZWwgR2FyY2lh
IHN1Z2dlc3RlZCB1c2luZyBwb3J0IDkgaWYgaXQgd29ya3MuIElmIG5vdCB0YWtlIGFueXRo
aW5nIG5vdCBlcXVhbCAwLiBSZWNlaXZlciBoYXMgdG8gaWdub3JlLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgIG1lZGl1bTsgZm9udC1mYW1pbHk6ICdUaW1l
cyBOZXcgUm9tYW4nOyBjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTog
bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAg
ICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh
bnM6IGF1dG87DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv
d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXNpemUt
YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICBi
YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6DQogICAgICAgIDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBj
b2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
DQogICAgICBtZWRpdW07IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgY29sb3I6
IHJnYigwLCAwLCAwKTsNCiAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
Ow0KICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp
bmc6IDBweDsNCiAgICAgIC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ow0KICAgICAgYmFja2dyb3VuZC1jb2xvcjogcmdi
KDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KICAgICAgICAx
MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgY29sb3I6IGJsYWNrOyI+SW4gZ2Vu
ZXJhbCwgdGhlcmUgd2FzIHB1c2hiYWNrIG9uIHRoZSBwb3J0IG5lZ290aWF0aW9uIGFwcHJv
YWNoLiBUaGUgYXV0aG9ycyBzaG91bGQgZXhwbG9yZSBhIHNvbHV0aW9uIGFsb25nIHRoZSB0
aGlyZCBvcHRpb246IHdyaXRlIHRoZSBSVFAgcG9ydCBudW1iZXIgaW4gdGhlICZxdW90O209
JnF1b3Q7IGxpbmUuIElmIENTDQogYWx0ZXJuYXRpdmUgaXMgY2hvc2VuLCBkaXNjYXJkIHRo
ZSBwb3J0IG51bWJlciBvbiByZWNlcHRpb24uPGJyPg0KJmx0Oy9xdW90ZSZndDs8YnI+DQo8
L3NwYW4+PC9wPg0KPGJyPg0KQXBhcnQgZnJvbSB0aGF0LCB0aGUgb25seSB0aGluZyBJJ20g
YXdhcmUgb2YgaXMgdGhlIDQgV0cgdmVyc2lvbnMgb2YgdGhpcyBkcmFmdCB3aGljaCBoYXZl
IGFsbCBzYWlkIHRoZSBzYW1lIGFib3V0IElQNC9JUDYgYW5kIElDRSwgYW5kIGFnYWluLCB0
aGF0IHRleHQgd2FzIGJvdGggV0dMQydlZCBhbmQgcmV2aWV3ZWQgYnkgMiB2b2x1bnRlZXJz
IHdpdGhvdXQgYW55IGNvbmNlcm5zLiBXaGVyZSBkb2VzIHRoZSBhbHRlcm5hdGUgdW5kZXJz
dGFuZGluZw0KIGNvbWUgZnJvbSA/IDxicj4NCjxicj4NClRoYW5rcyA8YnI+DQo8YnI+DQot
LSBGbGVtbWluZyA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0
ZS1wcmVmaXgiPk9uIDMvMTQvMTMgMjoxNiBQTSwgU3RhY2gsIFRob21hcyB3cm90ZTo8YnI+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDpGODFDRUU5OTQ4MkVGRTQzOERBRTJB
NjUyMzYxRUUxMjA2Nzk3NkQ0QE1DSFAwNE1TWC5nbG9iYWwtYWQubmV0IiB0eXBlPSJjaXRl
Ij4NCjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4x
OTQwMCI+DQo8ZGl2PjxzcGFuIGNsYXNzPSI5OTQyMzEzMTgtMTQwMzIwMTMiPjxmb250IGZh
Y2U9IkFyaWFsIiBzaXplPSIyIj5UaGlzIGlzIGFsc28gbXkgdW5kZXJzdGFuZGluZw0KPC9m
b250Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9Ijk5NDIzMTMxOC0xNDAzMjAx
MyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPi4uLiBhbHRob3VnaCBteSBpbml0aWFs
bHkgcHJvcG9zZWQgdGV4dCBkb2VzIG5vdCByZWZsZWN0IHRoaXMgY29ycmVjdGx5LjwvZm9u
dD48L3NwYW4+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJB
cmlhbCIgc2l6ZT0iMiI+UmVnYXJkczxicj4NClRob21hcyA8L2ZvbnQ+PC9kaXY+DQo8ZGl2
PiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiAj
MDAwMGZmIDJweCBzb2xpZDsgUEFERElORy1MRUZUOg0KICAgICAgICA1cHg7IE1BUkdJTi1M
RUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJP
dXRsb29rTWVzc2FnZUhlYWRlciIgYWxpZ249ImxlZnQiIGxhbmc9ImRlIj4NCjxociB0YWJp
bmRleD0iLTEiPg0KPGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48Yj5Wb246PC9iPiA8
YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bW11c2lj
LWJvdW5jZXNAaWV0Zi5vcmciPg0KbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBj
bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5j
ZXNAaWV0Zi5vcmciPm1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5J
bSBBdWZ0cmFnIHZvbiA8L2I+QW5kcmV3IEFsbGVuPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBE
b25uZXJzdGFnLCAxNC4gTcOkcnogMjAxMyAxNDoxMDxicj4NCjxiPkFuOjwvYj4gPGEgY2xh
c3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZp
ZHlvLmNvbSI+am9uYXRoYW5AdmlkeW8uY29tPC9hPjsNCjxhIGNsYXNzPSJtb3otdHh0LWxp
bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20iPmZhbmRy
ZWFzQGNpc2NvLmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGNsYXNzPSJtb3otdHh0LWxp
bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0Bp
ZXRmLm9yZzwvYT48YnI+DQo8Yj5CZXRyZWZmOjwvYj4gUmU6IFtNTVVTSUNdIFJFIDogSS1E
IEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50
eHQ8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8Zm9udCBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOg0KICAgICAgICAgICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTFwdCI+PGJyPg0KTXkgdW5kZXJzdGFuZGluZyBhbHNvIHdhcyB0aGF0IHdl
IGFncmVlZCB0aGF0IENDQVAgd2FzIG5vdCBhbiBhbHRlcm5hdGl2ZSB0byBJQ0UuPGJyPg0K
PC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1l
ZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtDQogICAgICAgICAgbm9uZTsgUEFERElO
Ry1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6DQogICAg
ICAgICAgMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsNCiAgICAgICAgICBQQURESU5HLVRPUDogM3B0Ij4NCjxmb250IHN0
eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6DQog
ICAgICAgICAgICAxMHB0Ij48Yj5Gcm9tPC9iPjogSm9uYXRoYW4gTGVubm94IFs8YSBjbGFz
cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8u
Y29tIj5tYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ8L2I+
OiBUaHVyc2RheSwgTWFyY2ggMTQsIDIwMTMgMDE6MDYgUE0gQ2VudHJhbCBTdGFuZGFyZCBU
aW1lPGJyPg0KPGI+VG88L2I+OiBGbGVtbWluZyBBbmRyZWFzZW4gPGEgY2xhc3M9Im1vei10
eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+DQom
bHQ7ZmFuZHJlYXNAY2lzY28uY29tJmd0OzwvYT4gPGJyPg0KPGI+Q2M8L2I+OiA8YSBjbGFz
cz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiA8
YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW9oYW1lZC5i
b3VjYWRhaXJAb3JhbmdlLmNvbSI+DQombHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv
bSZndDs8L2E+OyBBbmRyZXcgQWxsZW47IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2
aWF0ZWQiIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPg0KbW11c2ljQGlldGYub3Jn
PC9hPiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW11
c2ljQGlldGYub3JnIj4NCiZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7PC9hPiA8YnI+DQo8Yj5T
dWJqZWN0PC9iPjogUmU6IFtNTVVTSUNdIFJFIDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1t
bXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50eHQNCjxicj4NCjwvZm9udD4mbmJz
cDs8YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE1hciAxNCwgMjAxMywgYXQg
MTo0MyBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuIHdyb3RlOjwvZGl2Pg0KPGJyPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZG
RkYiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzE0LzEzIDExOjQwIEFN
LCA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2
aWF0ZWQiIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1v
aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgY2l0ZT0ibWlkOjk0QzY4MjkzMUMwOEIwNDhCN0E4NjQ1MzAzRkRDOUYzNkVC
NzM1Njg4MEBQVUVYQ0IxQi5uYW50ZXJyZS5mcmFuY2V0ZWxlY29tLmZyIiB0eXBlPSJjaXRl
Ij4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0iOTY0MDkzNjE1
LTE0MDMyMDEzIj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQ291cmllciBOZXciIHNp
emU9IjIiPlJlLSw8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249
ImxlZnQiPjxzcGFuIGNsYXNzPSI5NjQwOTM2MTUtMTQwMzIwMTMiPjwvc3Bhbj4mbmJzcDs8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0iOTY0MDkz
NjE1LTE0MDMyMDEzIj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQ291cmllciBOZXci
IHNpemU9IjIiPldoYXQgaXMgaW1wb3J0YW50IGlzIHRoZSBxdWFsaXR5IG9mIHByb2R1Y2Vk
IGRvY3VtZW50cy4gVGhlIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50IGlzIG5vdCBmcm96ZW4g
YW5kIHVubGVzcyBJJ20gbWlzdGFrZW4gdGhlcmUgaXMgbm90IElFVEYgTEMuPC9mb250Pjwv
c3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0i
OTY0MDkzNjE1LTE0MDMyMDEzIj48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQpDb3JyZWN0LiA8YnI+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6OTRDNjgyOTMxQzA4QjA0
OEI3QTg2NDUzMDNGREM5RjM2RUI3MzU2ODgwQFBVRVhDQjFCLm5hbnRlcnJlLmZyYW5jZXRl
bGVjb20uZnIiIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxz
cGFuIGNsYXNzPSI5NjQwOTM2MTUtMTQwMzIwMTMiPjxmb250IGNvbG9yPSIjMDAwMGZmIiBm
YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+V2hhdCBJIHVuZGVyc3RhbmQgZnJvbSB0aGUg
dGV4dCBpbiB0aGUgZHJhZnQgaXM6IGNjYXAgaXMgYWxsb3dlZCB0byBzaWduYWwgYW4gSVB2
NEAgYW5kIElQdjZAIGlmIElDRSBpcyBub3Qgc3VwcG9ydGVkLjwvZm9udD48L3NwYW4+PC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xhc3M9Ijk2NDA5MzYx
NS0xNDAzMjAxMyI+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KY2NhcCBp
cyBub3QgcHJvaGliaXRlZCBmcm9tIGRvaW5nIHNvIGluIHRoZSBhYnNlbmNlIG9mIElDRSwg
aG93ZXZlciBhcyBleHBsYWluZWQgaW4gdGhlIGRvY3VtZW50PGJyPg0KMSkgV2hlbiB0aGUg
SUVURiBTdGFuZGFyZCBUcmFjayBtZWNoYW5pc20gSUNFIGlzIGF2YWlsYWJsZSwgY2NhcCBN
VVNUIE5PVCBzaWduYWwgYW4gSVB2NC9JUFY2IGFkZHJlc3MgYWx0ZXJuYXRpdmUuPGJyPg0K
MikgVGhlIGRyYWZ0IGRvZXMgKGludGVudGlvbmFsbHkpIG5vdCBwcm92aWRlIGEgZnVsbCBz
b2x1dGlvbiBmb3IgbmVnb3RpYXRpbmcgYWx0ZXJuYXRpdmUgSVAtYWRkcmVzc2VzIHNpbmNl
IHdlIGhhdmUgYSBTdGFuZGFyZHMgVHJhY2sgbWVjaGFuaXNtIGZvciBkb2luZyBzbyAoSUNF
KS4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+SGksIEZsZW1pbmcgLS08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk15IHVu
ZGVyc3RhbmRpbmcgb2YgdGhlIFdHIGNvbnNlbnN1cyAtLSBhbmQgbXkgaW50ZXJwcmV0YXRp
b24gb2YgdGhlIHRleHQgaW4gdGhlIGRyYWZ0IC0tIHdhcyBzdHJvbmdlciB0aGFuIHRoaXM6
IGNjYXAgTVVTVCBOT1QgYmUgdXNlZCBmb3IgdGhlIGtpbmRzIG9mIGFsdGVybmF0aXZlcyBJ
Q0UgY2FuIGV4cHJlc3MsIHdoZXRoZXIgb3Igbm90IElDRSBpcyBhY3R1YWxseSBiZWluZyB1
c2VkIGluIGEgcGFydGljdWxhciBvZmZlci9hbnN3ZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5JZiB3ZSdyZSBnZXR0aW5nIGRpdmVyZ2VudCBpbnRlcnByZXRhdGlvbnMg
b2YgdGhpcyBkb2N1bWVudCwgd2UgcHJvYmFibHkgZG8gbmVlZCB0byB1cGRhdGUgaXRzIHRl
eHQuPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRy
dWUiPjxzcGFuIHN0eWxlPSJXSURPV1M6IDI7DQogICAgICAgICAgICBURVhULVRSQU5TRk9S
TTogbm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOg0KICAgICAgICAg
ICAgc2VwYXJhdGU7IEZPTlQ6IG1lZGl1bSBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3Jt
YWw7DQogICAgICAgICAgICBPUlBIQU5TOiAyOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBD
T0xPUjogcmdiKDAsMCwwKTsNCiAgICAgICAgICAgIFdPUkQtU1BBQ0lORzogMHB4OyAtd2Vi
a2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgIC13ZWJr
aXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgIC13ZWJraXQt
dGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7DQogICAgICAgICAgICAtd2Via2l0
LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQog
ICAgICAgICAgICAwcHgiIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0i
V0lET1dTOiAyOw0KICAgICAgICAgICAgICBURVhULVRSQU5TRk9STTogbm9uZTsgVEVYVC1J
TkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOg0KICAgICAgICAgICAgICBzZXBhcmF0ZTsg
Rk9OVDogbWVkaXVtIEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsNCiAgICAgICAg
ICAgICAgT1JQSEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigw
LDAsMCk7DQogICAgICAgICAgICAgIFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRl
ci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgLXdlYmtpdC1ib3Jk
ZXItdmVydGljYWwtc3BhY2luZzogMHB4Ow0KICAgICAgICAgICAgICAtd2Via2l0LXRleHQt
ZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOw0KICAgICAgICAgICAgICAtd2Via2l0LXRl
eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAg
ICAgICAgICAgIDBweCIgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iPg0KPGRpdiBzdHlsZT0i
V09SRC1XUkFQOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZToNCiAgICAgICAgICAg
ICAgICBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+DQot
LTwvZGl2Pg0KPGRpdiBzdHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkOyAtd2Via2l0LW5i
c3AtbW9kZToNCiAgICAgICAgICAgICAgICBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh
ZnRlci13aGl0ZS1zcGFjZSI+DQpKb25hdGhhbiBMZW5ub3g8YnI+DQo8YSBtb3otZG8tbm90
LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iPmpvbmF0aGFu
QHZpZHlvLmNvbTwvYT48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+
DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1
ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h
dGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3Rl
ZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVn
ZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2Yg
dGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu
c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us
IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg
dHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3Jp
emVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N
Cjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVk
aW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0
aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVk
IGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdl
cyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0
aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNp
cGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p
c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVy
IGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRp
c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJh
bnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBh
bmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2B01CXMB104ADSrimnet_--

From martin.thomson@gmail.com  Thu Mar 14 13:00:38 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AF711E80F2 for ; Thu, 14 Mar 2013 13:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Mn6ejeV9FzmU for ; Thu, 14 Mar 2013 13:00:37 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 762F411E80D7 for ; Thu, 14 Mar 2013 13:00:37 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so2075562wgb.0 for ; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fFfDI1zKSnZocGhol71LN5AUsb9kqEavVjfe9/VvSrc=; b=OdzN/tGza9EvfqTXYoVwkKCreN64RycBZ0bo1IB3CgtMqFFQHEDujEE+aDKCHKeZDm gA4bv1blsBFn9l7a3Vc3PmpqWRNMj/QiDhSs8yC/6NNqcJDsjTyt1lJNcqLBEZzDkQAy Y1eg74gtTUubx1XzSvuBf6jSyXVXDpYkPEw6oNXQuwwo7ebwiE2AjlC1VOEWALfl8RwW YL4HKpZSUK7P0by62KSTRJiaBD6XGttPcmtXSN4htwu4m9RvyKiRRpeWwIwXzHbPgb6v P7g1LaZJLDjlsmWbQBAQ4tCDvJ654UMOYru49GhfnyJBxEscPFcIZY3UoSQ5DjJINk3I mShA==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr6809978wjw.21.1363291236660; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Thu, 14 Mar 2013 13:00:36 -0700 (PDT)
Date: Thu, 14 Mar 2013 16:00:36 -0400
Message-ID: 
From: Martin Thomson 
To: "mmusic@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:00:38 -0000

Someone proposed that we use 0.0.0.1:9 to signal "no candidates".

I don't believe this to be necessary and would rather we don't go there at all.

If privacy concerns do not prevent the sharing of addressing
information, trickle can proceed with host candidates.  This is not a
real concern.

If privacy protection is paramount, pay the price and allocate a turn
candidate prior to sending the offer or answer.  It's only the caller
that is required to pay this cost, which is a little silly because the
answerer is the most likely to want this sort of protection.

Furthermore, in WebRTC, we have a candidate pool that would ensure
that would allow us to prime the answerer in preparation for receiving
an offer such that overall session setup would not take any longer.
If anyone is unconvinced, I'm happy to walk through a proof of this.

From adam@nostrum.com  Thu Mar 14 13:10:20 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7676A11E8133 for ; Thu, 14 Mar 2013 13:10:20 -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=[BAYES_00=-2.599, SPF_PASS=-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 tgUO3aWseqUR for ; Thu, 14 Mar 2013 13:10:20 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19411E8153 for ; Thu, 14 Mar 2013 13:10:18 -0700 (PDT)
Received: from Orochi.local ([130.129.131.42]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EKA7BC037690 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 15:10:08 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51422E9F.5090909@nostrum.com>
Date: Thu, 14 Mar 2013 16:10:07 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Martin Thomson 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.131.42 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:10:20 -0000

If we can maintain privacy without having to specify an intentionally 
bogus address, then I am strongly in support of avoiding this silliness 
also.

/a

On 3/14/13 16:00, Martin Thomson wrote:
> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
>
> I don't believe this to be necessary and would rather we don't go there at all.
>
> If privacy concerns do not prevent the sharing of addressing
> information, trickle can proceed with host candidates.  This is not a
> real concern.
>
> If privacy protection is paramount, pay the price and allocate a turn
> candidate prior to sending the offer or answer.  It's only the caller
> that is required to pay this cost, which is a little silly because the
> answerer is the most likely to want this sort of protection.
>
> Furthermore, in WebRTC, we have a candidate pool that would ensure
> that would allow us to prime the answerer in preparation for receiving
> an offer such that overall session setup would not take any longer.
> If anyone is unconvinced, I'm happy to walk through a proof of this.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From emil@sip-communicator.org  Thu Mar 14 13:13:05 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D06D11E8224 for ; Thu, 14 Mar 2013 13:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUkWCDGKHEjM for ; Thu, 14 Mar 2013 13:13:04 -0700 (PDT)
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6DA11E8103 for ; Thu, 14 Mar 2013 13:13:04 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id wy12so2708267pbc.21 for ; Thu, 14 Mar 2013 13:13:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=rxxD7P46R86v2tllK/E4OKbCYz5glM2kMWetLW8YISA=; b=oEysqk65kcT0rioD3zSBh+zm2aXWdw+NomjlRsTQK+faFRgdlf35dgswZivbuwO+u5 Si13hmGOmVyqzoBNc3bDtSQ11tE3AD7DpGSo4N2YtUDqsOPLMPc+cqQLZ7l/PZto3Gjl J4uLdDTHVTBkK2OyeG9T+nU4ng/FLo/OWke4cVG1UgazW4kK42iBAWZ/lx5MoK5/3e9W +WEwsPKiio3bBcRYH3S/Ft+Udm3cyIyul8s+sWItOzoOFw1q+k8JspJsURi5EBRTuIBR z3i5nUQnWKJ71yDpeExBLPTVY6TJTHj3WBnHMEt5erjNiT+inHQ0JW2r1bY75z4QLp9+ 89oA==
X-Received: by 10.68.130.1 with SMTP id oa1mr8986638pbb.134.1363291983980; Thu, 14 Mar 2013 13:13:03 -0700 (PDT)
Received: from camionet.local (dhcp-42f0.meeting.ietf.org. [130.129.66.240]) by mx.google.com with ESMTPS id cy4sm3226196pbc.13.2013.03.14.13.13.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:13:03 -0700 (PDT)
Message-ID: <51422F4A.8000103@jitsi.org>
Date: Thu, 14 Mar 2013 16:12:58 -0400
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Martin Thomson 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlKLDGvKkDyQLF+3sNxrywuX/XS1b3kq86+tp9Kl+wbpi4h3WhZqqRP6IGs2u2RiyEdewkG
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:13:05 -0000

Hey Martin,

On 14.03.13, 16:00, Martin Thomson wrote:
> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
> 
> I don't believe this to be necessary and would rather we don't go there at all.

When we talked about this on Tuesday, it appeared as if we had consensus
and the only issue was about making a choice between one of the many
possible options. (127..., 0.0.0.X, something else that IANA would
allocate for us).

How do you get from that to "I'd rather we didn't do it at all" ?

> If privacy concerns do not prevent the sharing of addressing
> information, trickle can proceed with host candidates.  This is not a
> real concern.

Right.

> If privacy protection is paramount, pay the price and allocate a turn
> candidate prior to sending the offer or answer.  It's only the caller
> that is required to pay this cost,
>
>
> which is a little silly because the
> answerer is the most likely to want this sort of protection.
> 
> Furthermore, in WebRTC, we have a candidate pool that would ensure
> that would allow us to prime the answerer in preparation for receiving
> an offer such that overall session setup would not take any longer.
> If anyone is unconvinced, I'm happy to walk through a proof of this.

I am not sure I got the idea, so yes, please do :).

Emil


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

-- 
https://jitsi.org

From emil@sip-communicator.org  Thu Mar 14 13:16:49 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D561F11E8189 for ; Thu, 14 Mar 2013 13:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 QP6c967OxCes for ; Thu, 14 Mar 2013 13:16:48 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB211E81B5 for ; Thu, 14 Mar 2013 13:16:48 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id w10so92701pde.17 for ; Thu, 14 Mar 2013 13:16:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=5BdjHRHXO1uSBv9P/bu0zx4f5wU7FJSaxVPY9F7eEro=; b=NuNNtRQ2CgGIDIyvca2QYOUfo7qePdKdon0YyHl96tZ8zgQuNosb3XdwZRmKo463Ky UCDOaru/57IY/9B0x9OIIMO5bPrfeLjbtUP+dIrGfAfW0XOzXzIJOwAxS380hh9j+0oS cj/+9kwEgHFJIPJDFip7PLKfOrSceVu3IdLAYxHLH/lMqZ61D32UZevrc2FMLfDxR8QR wTJ45HjRH2u0kiqDkdbXskSX28bx2vVxomF706rISRaE5ZyyHDbNruYTYcxWOwj7fHM/ 9mt8wqjzdeC5xczjQuv9N0XUH4GiA6t6G/8Y5GMyomdy/c7n4oMNEhdMwzCKy5bVp6aI WabQ==
X-Received: by 10.68.42.134 with SMTP id o6mr9117999pbl.52.1363292208503; Thu, 14 Mar 2013 13:16:48 -0700 (PDT)
Received: from camionet.local (dhcp-42f0.meeting.ietf.org. [130.129.66.240]) by mx.google.com with ESMTPS id ou3sm4774673pbc.7.2013.03.14.13.16.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:16:47 -0700 (PDT)
Message-ID: <51423029.8020809@jitsi.org>
Date: Thu, 14 Mar 2013 16:16:41 -0400
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Adam Roach 
References:  <51422E9F.5090909@nostrum.com>
In-Reply-To: <51422E9F.5090909@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlUN83EV4WkTrutvQszN8SpLyc4FD3Ff5XFbeWY8PJaLKhaKV9+nyyveJvdm/9UPNwD01s8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:16:50 -0000

On 14.03.13, 16:10, Adam Roach wrote:
> If we can maintain privacy without having to specify an intentionally 
> bogus address, then I am strongly in support of avoiding this silliness 
> also.

We do not need a bogus candidate because of privacy. We have one that is
defined by 3264 with exactly the necessary meaning: 0.0.0.0.

The reason we need a bogus candidate is because some people here have
expressed concerns that we need to take into account poorly
implemented/legacy SDP parsers who might somehow fail on 0.0.0.0 because
of what it used to mean in 2543.

Emil


> 
> /a
> 
> On 3/14/13 16:00, Martin Thomson wrote:
>> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
>>
>> I don't believe this to be necessary and would rather we don't go there at all.
>>
>> If privacy concerns do not prevent the sharing of addressing
>> information, trickle can proceed with host candidates.  This is not a
>> real concern.
>>
>> If privacy protection is paramount, pay the price and allocate a turn
>> candidate prior to sending the offer or answer.  It's only the caller
>> that is required to pay this cost, which is a little silly because the
>> answerer is the most likely to want this sort of protection.
>>
>> Furthermore, in WebRTC, we have a candidate pool that would ensure
>> that would allow us to prime the answerer in preparation for receiving
>> an offer such that overall session setup would not take any longer.
>> If anyone is unconvinced, I'm happy to walk through a proof of this.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org

From martin.thomson@gmail.com  Thu Mar 14 13:18:54 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F421F8CE2 for ; Thu, 14 Mar 2013 13:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJGl6yeY4118 for ; Thu, 14 Mar 2013 13:18:54 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2A46611E8126 for ; Thu, 14 Mar 2013 13:18:53 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id dr13so2368459wgb.26 for ; Thu, 14 Mar 2013 13:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3Ct26ezmoidtNe/1TijpBLMUtaiYd/DJiZ2MJepQu8U=; b=Wrtun+Lw6/SREZiphqZcQD7jSBKxpqFWTw+hqYFog24mhicEnOD2ojBVdlweKEkwhw k5eIQxcmMTlbvo0rcXoHuXVTjEXyKnWYjptOpaIejXiBA5baec3KE1eUrVqFtRYw/GPv qJizlnr5lqqwje/OLO4Mgcs76nvB/wcGCbFL4QcUlua6K7BHQyRczoANZuBDSKqvpgWf 3to7ueXkcsQtSq0jg3OHN7rpbe8LGZdwfCTONCOFKEXAjyOdxcCwA0MKaYIHAqbpmRmX tNjXp2OMCkiK9QM1KF0apooGkPjPRXNV/bOg5FmYWBcsGAOP1PCr/Q/BJbsDekr75cOF pkWA==
MIME-Version: 1.0
X-Received: by 10.180.75.177 with SMTP id d17mr6662335wiw.16.1363292331324; Thu, 14 Mar 2013 13:18:51 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Thu, 14 Mar 2013 13:18:51 -0700 (PDT)
In-Reply-To: <51422F4A.8000103@jitsi.org>
References:  <51422F4A.8000103@jitsi.org>
Date: Thu, 14 Mar 2013 16:18:51 -0400
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:18:54 -0000

On 14 March 2013 16:12, Emil Ivov  wrote:
> On 14.03.13, 16:00, Martin Thomson wrote:
>> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
>>
>> I don't believe this to be necessary and would rather we don't go there at all.
>
> When we talked about this on Tuesday, it appeared as if we had consensus
> and the only issue was about making a choice between one of the many
> possible options. (127..., 0.0.0.X, something else that IANA would
> allocate for us).
>
> How do you get from that to "I'd rather we didn't do it at all" ?

I applied some brain cycles to the problem, talked to a few people.

I'll find you and walk through the proof.  It's not especially complicated.

From fandreas@cisco.com  Thu Mar 14 13:39:16 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6903911E812A for ; Thu, 14 Mar 2013 13:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.406
X-Spam-Level: 
X-Spam-Status: No, score=-8.406 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 fQOAKw-xwPFm for ; Thu, 14 Mar 2013 13:39:14 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C0C5E11E80D9 for ; Thu, 14 Mar 2013 13:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43238; q=dns/txt; s=iport; t=1363293554; x=1364503154; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=s9GueZ+GxsuWOZ33oPYaO4grFeoOHdhDHwkjBKCXp44=; b=C+wHsAL0Ujqa6RX+xzPqDUgoVAwdC3o4bNrxU2tlx70faxB86NiPCunG 7RWocTTIdMOQlSS4OIuKf9Y4d3fCmwJcUBx84fP7NHOR26g5v0uIJaZdE J7rqUZ7LDSt4wbqzsaP/Rm0NV220eJvYIM5s0MPzXDyXraSvgOWu6sGyW w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFADM0QlGrRDoG/2dsb2JhbABDhByEEIVbtnuBZRZ0gisBAQEEI0sKARAJAg4DBAEBAQkWAQEGAwICCQMCAQIBNAkIBg0BBQIBAQUSh3gNlCSbA5JRjUqBIggXAQoGAQaCJ4ETA5ZYgR+PY4FUgVIg
X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208,217";a="75524553"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Mar 2013 20:39:14 +0000
Received: from bxb-vpn3-830.cisco.com (bxb-vpn3-830.cisco.com [10.86.251.62]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EKdCGd005028; Thu, 14 Mar 2013 20:39:12 GMT
Message-ID: <5142356F.3060201@cisco.com>
Date: Thu, 14 Mar 2013 16:39:11 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Andrew Allen 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050303080603040805000207"
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 20:39:16 -0000

This is a multi-part message in MIME format.
--------------050303080603040805000207
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 3/14/13 3:50 PM, Andrew Allen wrote:
>
> I am not sure if anything is recorded in any minutes but we had an 
> offline discussion to remove the roadblock on this with Jonathan to 
> address his concern that this was a potential alternative to ICE and 
> addressed this with the current text. This text and the reason behind 
> it I think was pointed out on the list during Quebec or shortly after.
>
Can you find the message or recall who sent it ?

Also, the Quebec meeting was in July 2011. Tracing back we have:

a) The initial (?) individul versions of the draft (2008/2009): 
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
b) Another individual take on the draft (August 2011+): 
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
c) The intial WG version of the draft (March 2012+): 
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

The "a)" version did indeed position the draft as an alternative to ICE, 
however all "b)" and "c)" versions changed this as per the previous 
discussion.

I'm still looking for anything written anywhere that suggests that the 
text in "b)" and "c)" does not represent consensus and/or that consensus 
is that the mechanism MUST always be prohibited from negotiating IP4/IP6 
addresses (as opposed to just when ICE is not available).

Thanks

-- Flemming

>
> *From*: Flemming Andreasen [mailto:fandreas@cisco.com]
> *Sent*: Thursday, March 14, 2013 02:45 PM Central Standard Time
> *To*: Stach, Thomas 
> *Cc*: Andrew Allen; jonathan@vidyo.com ; 
> mmusic@ietf.org 
> *Subject*: Re: AW: [MMUSIC] RE : I-D Action: 
> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
> As to ccap not being an alternative to ICE we are all in agreement on 
> that - the lack of port negotiation alone makes that clear (it simply 
> doesn't work without that).
>
> As to ccap being explicitly forbidden to express IP4 and/or IP6 
> addresses as alternatives, can somebody please point me to either 
> meeting minutes or mailing list discussion to that effect ? The only 
> thing I have found is the port discussion we had in Taipei, where we 
> agreed not to add a port capability. From 
> http://www.ietf.org/proceedings/82/minutes/mmusic.htm:
> 
>
> Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)
>
> =====================================================================
>
> draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt 
> 
>
> Simo presented hisslides 
> .
>
> Simo explained the need to be able to indicate alternative port 
> numbers, but PSTN media, port number doesn't make sense. The CS draft 
> says use port number 9 (the discard port). We have to put something 
> there because required by SDP syntax. If an RTP stream is offered, 
> then a regular port number should be written instead. The problem 
> arises when both CS and RTP streams are offered at the same time, one 
> as an alternative of the other. Then, the port number makes sense for 
> RTP but not for CS, but still, there is a single place to write the 
> port number in the SDP, so, has to be shared by both alternative media 
> streams.
>
> Possible solutions:
>
> 1. Circuit-switched media uses the same port as RTP media even though 
> the port is not really used
>
> 2. Extend capneg with a port number capability attribute, restricting 
> its use to cases where ICE cannot be used.
>
> 3.Select anything as a port number and say "do not care on reception".
>
> Jonathan Lennox suggested saying that port numbers not equal 0 have to 
> be ignored.
>
> Hadriel Kaplan asked if middle boxes not supporting this stuff can be 
> broken. The discussion is moved offline.
>
> There are questions on how could be possible to indicate preference 
> for one media stream above the alternative.
>
> Miguel Garcia suggested using port 9 if it works. If not take anything 
> not equal 0. Receiver has to ignore.
>
> In general, there was pushback on the port negotiation approach. The 
> authors should explore a solution along the third option: write the 
> RTP port number in the "m=" line. If CS alternative is chosen, discard 
> the port number on reception.
> 
>
>
> Apart from that, the only thing I'm aware of is the 4 WG versions of 
> this draft which have all said the same about IP4/IP6 and ICE, and 
> again, that text was both WGLC'ed and reviewed by 2 volunteers without 
> any concerns. Where does the alternate understanding come from ?
>
> Thanks
>
> -- Flemming
>
>
>
> On 3/14/13 2:16 PM, Stach, Thomas wrote:
>> This is also my understanding
>> ... although my initially proposed text does not reflect this correctly.
>> Regards
>> Thomas
>>
>>     ------------------------------------------------------------------------
>>     *Von:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>>     *Im Auftrag von *Andrew Allen
>>     *Gesendet:* Donnerstag, 14. März 2013 14:10
>>     *An:* jonathan@vidyo.com; fandreas@cisco.com
>>     *Cc:* mmusic@ietf.org
>>     *Betreff:* Re: [MMUSIC] RE : I-D Action:
>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>
>>
>>     My understanding also was that we agreed that CCAP was not an
>>     alternative to ICE.
>>
>>
>>     *From*: Jonathan Lennox [mailto:jonathan@vidyo.com]
>>     *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard Time
>>     *To*: Flemming Andreasen 
>>     *Cc*: mohamed.boucadair@orange.com
>>     ; Andrew Allen; mmusic@ietf.org
>>     
>>     *Subject*: Re: [MMUSIC] RE : I-D Action:
>>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>>
>>
>>     On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:
>>
>>>     On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
>>>>     Re-,
>>>>     What is important is the quality of produced documents. The
>>>>     content of the document is not frozen and unless I'm mistaken
>>>>     there is not IETF LC.
>>>>
>>>     Correct.
>>>>     What I understand from the text in the draft is: ccap is
>>>>     allowed to signal an IPv4@ and IPv6@ if ICE is not supported.
>>>>
>>>     ccap is not prohibited from doing so in the absence of ICE,
>>>     however as explained in the document
>>>     1) When the IETF Standard Track mechanism ICE is available, ccap
>>>     MUST NOT signal an IPv4/IPV6 address alternative.
>>>     2) The draft does (intentionally) not provide a full solution
>>>     for negotiating alternative IP-addresses since we have a
>>>     Standards Track mechanism for doing so (ICE).
>>
>>     Hi, Fleming --
>>
>>     My understanding of the WG consensus -- and my interpretation of
>>     the text in the draft -- was stronger than this: ccap MUST NOT be
>>     used for the kinds of alternatives ICE can express, whether or
>>     not ICE is actually being used in a particular offer/answer.
>>
>>     If we're getting divergent interpretations of this document, we
>>     probably do need to update its text.
>>
>>     --
>>     Jonathan Lennox
>>     jonathan@vidyo.com 
>>
>>
>>     ---------------------------------------------------------------------
>>
>>     This transmission (including any attachments) may contain
>>     confidential information, privileged material (including material
>>     protected by the solicitor-client or other applicable
>>     privileges), or constitute non-public information. Any use of
>>     this information by anyone other than the intended recipient is
>>     prohibited. If you have received this transmission in error,
>>     please immediately reply to the sender and delete this
>>     information from your system. Use, dissemination, distribution,
>>     or reproduction of this transmission by unintended recipients is
>>     not authorized and may be unlawful. 
>>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful. 


--------------050303080603040805000207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 3/14/13 3:50 PM, Andrew Allen wrote:

    

    

      
      

        I am not sure if anything is recorded in any minutes but we had
        an offline discussion to remove the roadblock on this with
        Jonathan to address his concern that this was a potential
        alternative to ICE and addressed this with the current text.
        This text and the reason behind it I think was pointed out on
        the list during Quebec or shortly after.

      

    

    Can you find the message or recall who sent it ? 

    

    Also, the Quebec meeting was in July 2011. Tracing back we have:

    

    a) The initial (?) individul versions of the draft (2008/2009):    
    http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap

    b) Another individual take on the draft (August 2011+):        
    http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps

    c) The intial WG version of the draft (March 2012+):            
    http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

    

    The "a)" version did indeed position the draft as an alternative to
    ICE, however all "b)" and "c)" versions changed this as per the
    previous discussion. 

    

    I'm still looking for anything written anywhere that suggests that
    the text in "b)" and "c)" does not represent consensus and/or that
    consensus is that the mechanism MUST always be prohibited from
    negotiating IP4/IP6 addresses (as opposed to just when ICE is not
    available). 

    

    Thanks 

    

    -- Flemming 

    

    

       

      

        From:
          Flemming Andreasen [mailto:fandreas@cisco.com]
          

          Sent: Thursday, March 14, 2013 02:45 PM Central
          Standard Time

          To: Stach, Thomas
          <thomas.stach@siemens-enterprise.com> 

          Cc: Andrew Allen; jonathan@vidyo.com
          <jonathan@vidyo.com>; mmusic@ietf.org
          <mmusic@ietf.org>
          

          Subject: Re: AW: [MMUSIC] RE : I-D Action:
          draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
          

         

      

      As to ccap not being an alternative to ICE we are all in agreement
      on that - the lack of port negotiation alone makes that clear (it
      simply doesn't work without that).
      

      

      As to ccap being explicitly forbidden to express IP4 and/or IP6
      addresses as alternatives, can somebody please point me to either
      meeting minutes or mailing list discussion to that effect ? The
      only thing I have found is the port discussion we had in Taipei,
      where we agreed not to add a port capability. From 
        http://www.ietf.org/proceedings/82/minutes/mmusic.htm:

      <quote>

      

        Miscellaneous
          Capabilities Negotiation in SDP (Simo Veikkolainen, 10)

      

        =====================================================================

      

        draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt

      

         

      

        Simo
          presented his slides.

      

         

      

        Simo
          explained the need to be able to indicate alternative port
          numbers, but PSTN media, port number doesn't make sense. The
          CS draft says use port number 9 (the discard port). We have to
          put something there because required by SDP syntax. If an RTP
          stream is offered, then a regular port number should be
          written instead. The problem arises when both CS and RTP
          streams are offered at the same time, one as an alternative of
          the other. Then, the port number makes sense for RTP but not
          for CS, but still, there is a single place to write the port
          number in the SDP, so, has to be shared by both alternative
          media streams.

      

         

      

        Possible
          solutions:

      

         

      

        1.
          Circuit-switched media uses the same port as RTP media even
          though the port is not really used

      

        2.
          Extend capneg with a port number capability attribute,
          restricting its use to cases where ICE cannot be used.

      

        3.  Select
          anything as a port number and say "do not care on reception".

      

         

      

        Jonathan Lennox suggested saying that port numbers not
          equal 0 have to be ignored.

      

         

      

        Hadriel Kaplan asked if middle boxes not supporting
          this stuff can be broken. The discussion is moved offline.

      

         

      

        There are questions on how could be possible to
          indicate preference for one media stream above the
          alternative.

      

         

      

        Miguel Garcia suggested using port 9 if it works. If
          not take anything not equal 0. Receiver has to ignore.

      

         

      

        In general, there was pushback on the port negotiation
          approach. The authors should explore a solution along the
          third option: write the RTP port number in the "m=" line. If
          CS alternative is chosen, discard the port number on
          reception.

          </quote>

        

      

      Apart from that, the only thing I'm aware of is the 4 WG versions
      of this draft which have all said the same about IP4/IP6 and ICE,
      and again, that text was both WGLC'ed and reviewed by 2 volunteers
      without any concerns. Where does the alternate understanding come
      from ? 

      

      Thanks 

      

      -- Flemming 

      

      

      

      
On 3/14/13 2:16 PM, Stach, Thomas
        wrote:

      

      

        
        
This is also my understanding
            

        
... although my initially proposed text does not
              reflect this correctly.

        
 

        
Regards

            Thomas 

        
 

        

        

          

            

            Von: 
                mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
              Im Auftrag von Andrew Allen

              Gesendet: Donnerstag, 14. März 2013 14:10

              An: jonathan@vidyo.com;
              fandreas@cisco.com

              Cc: mmusic@ietf.org

              Betreff: Re: [MMUSIC] RE : I-D Action:
              draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

            

          

          

            My understanding also was that we agreed that CCAP was not
            an alternative to ICE.

          

           

          

            From: Jonathan Lennox [mailto:jonathan@vidyo.com]
              

              Sent: Thursday, March 14, 2013 01:06 PM Central
              Standard Time

              To: Flemming Andreasen 
                <fandreas@cisco.com> 

              Cc: 
                mohamed.boucadair@orange.com 
                <mohamed.boucadair@orange.com>; Andrew Allen;
              
                mmusic@ietf.org 
                <mmusic@ietf.org> 

              Subject: Re: [MMUSIC] RE : I-D Action:
              draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
              

             

          

          

          

            
On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

            

            

              

                
On 3/14/13 11:40 AM, 
                    mohamed.boucadair@orange.com wrote:

                

                

                  
Re-,

                  
 

                  
What is important is
                        the quality of produced documents. The content
                        of the document is not frozen and unless I'm
                        mistaken there is not IETF LC.

                  


                  

                

                Correct. 

                

                  
What I understand
                        from the text in the draft is: ccap is allowed
                        to signal an IPv4@ and IPv6@ if ICE is not
                        supported.

                  


                  

                

                ccap is not prohibited from doing so in the absence of
                ICE, however as explained in the document

                1) When the IETF Standard Track mechanism ICE is
                available, ccap MUST NOT signal an IPv4/IPV6 address
                alternative.

                2) The draft does (intentionally) not provide a full
                solution for negotiating alternative IP-addresses since
                we have a Standards Track mechanism for doing so (ICE).
                

              

            

            


            

            
Hi, Fleming --

            


            

            
My understanding of the WG consensus -- and my
              interpretation of the text in the draft -- was stronger
              than this: ccap MUST NOT be used for the kinds of
              alternatives ICE can express, whether or not ICE is
              actually being used in a particular offer/answer.

            


            

            
If we're getting divergent interpretations of this
              document, we probably do need to update its text.

          

          

          

                

                  --

                

                  Jonathan Lennox

                  jonathan@vidyo.com

                  

                

              

          

          ---------------------------------------------------------------------
          

          This transmission (including any attachments) may contain
          confidential information, privileged material (including
          material protected by the solicitor-client or other applicable
          privileges), or constitute non-public information. Any use of
          this information by anyone other than the intended recipient
          is prohibited. If you have received this transmission in
          error, please immediately reply to the sender and delete this
          information from your system. Use, dissemination,
          distribution, or reproduction of this transmission by
          unintended recipients is not authorized and may be unlawful. 

      

      

      ---------------------------------------------------------------------
      

      This transmission (including any attachments) may contain
      confidential information, privileged material (including material
      protected by the solicitor-client or other applicable privileges),
      or constitute non-public information. Any use of this information
      by anyone other than the intended recipient is prohibited. If you
      have received this transmission in error, please immediately reply
      to the sender and delete this information from your system. Use,
      dissemination, distribution, or reproduction of this transmission
      by unintended recipients is not authorized and may be unlawful.
    

    

  


--------------050303080603040805000207--

From keith.drage@alcatel-lucent.com  Thu Mar 14 14:36:22 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1F711E812C for ; Thu, 14 Mar 2013 14:36:22 -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 Kr9aQZHVcfij for ; Thu, 14 Mar 2013 14:36:22 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8788C11E812B for ; Thu, 14 Mar 2013 14:36:17 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2ELaGvY024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Mar 2013 16:36:16 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2ELaGaD007621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 17:36:16 -0400
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 14 Mar 2013 17:36:16 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 14 Mar 2013 22:36:14 +0100
From: "DRAGE, Keith (Keith)" 
To: "mmusic@ietf.org" 
Thread-Topic: Slides for AVTEXT/MMUSIC joint on media grouping taxonomy
Thread-Index: Ac4g+/LcHGqaJiyrT/KZVJc/6bEfwA==
Date: Thu, 14 Mar 2013 21:36:14 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0151D0@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.41]
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: [MMUSIC] Slides for AVTEXT/MMUSIC joint on media grouping taxonomy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 21:36:23 -0000

You will find these in the AVTEXT meeting materials area.

Regards

Keith

From andrew.hutton@siemens-enterprise.com  Thu Mar 14 14:47:21 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728181F0D17 for ; Thu, 14 Mar 2013 14:47:21 -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 oXFLwi-ZAPHq for ; Thu, 14 Mar 2013 14:47:21 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D23271F0D09 for ; Thu, 14 Mar 2013 14:47:20 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 717FA23F049B for ; Thu, 14 Mar 2013 22:47:08 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 22:47:08 +0100
From: "Hutton, Andrew" 
To: "mmusic@ietf.org" 
Thread-Topic: Bundle and Complex ICE Scenarios
Thread-Index: Ac4g/Xe3HFOGVBvaRFWIAP3m48T0DQ==
Date: Thu, 14 Mar 2013 21:47:07 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0689CC99@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Bundle and Complex ICE Scenarios
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 21:47:21 -0000

Having reviewed the various bundle proposals I don't believe enough attenti=
on has been made to issues around using bundle with ICE and especially some=
 of the more complex ICE scenarios to verify that they will work or are opt=
imal in these cases.

For example there is no analysis of the following issues:

1. IPV6 / Dual Stack environments where it is necessary to generate candida=
tes for multiple address families.=20

2. Scenarios involving Server Reflexive, Relayed Candidates, and TCP Candid=
ates are required.

Some of these scenarios relate to scenarios involving NAT's & Firewalls whi=
ch we have started to analyse in http://tools.ietf.org/html/draft-hutton-rt=
cweb-nat-firewall-considerations-00.=20

I intend to do some further analysis and look more closely at bundle in the=
 context of these scenarios over the next couple of weeks but personally un=
til this is done I cannot say whether the current bundle proposals meet our=
 needs.

Regards
Andy

From magnus.westerlund@ericsson.com  Thu Mar 14 16:13:08 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D317C11E8158 for ; Thu, 14 Mar 2013 16:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level: 
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_18=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 U8hlIYN1aq4u for ; Thu, 14 Mar 2013 16:13:06 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 093C711E812B for ; Thu, 14 Mar 2013 16:13:05 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-ef-5142598032ef
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 86.E2.10459.08952415; Fri, 15 Mar 2013 00:13:04 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 15 Mar 2013 00:13:03 +0100
Message-ID: <51425974.9070608@ericsson.com>
Date: Thu, 14 Mar 2013 19:12:52 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "mmusic (E-mail)" 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJMWRmVeSWpSXmKPExsUyM+JvjW5DpFOgwdtvGhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoGpRgVrpStmHvdoYDwn2sXIySEhYCLRevw2K4QtJnHh3nq2 LkYuDiGBk4wS7+f9Y4JwljNKtNxsYwKp4hXQlvh4/RkbiM0ioCrx+eppFhCbTcBC4uaPRrC4 qECwxM9XZ1gg6gUlTs58AmaLCKhLtG7uA9rGwSEsYCpx+mQkxGJJiS0v2tlBbGYBPYkpV1sY IWx5ieats5lBbCGgtQ1NHawTGPlnIZk6C0nLLCQtCxiZVzGy5yZm5qSXG25iBIbSwS2/dXcw njoncohRmoNFSZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGurY9785t+RawS34O c7NshpH7xEuLTN6dKREVDAxiVG07eW3V7j3u93Z+9jc/JFbD5yGo/CcsPn6b+CPfXK7oduYo g7AzLyouassHT7znr/5fPKWlWO1N7PGbPRMNrm49+y3k/pvPGxSqMr8WrkkzP53DHt3+9bX/ gSwW3qAHtrP6fn50W5yjxFKckWioxVxUnAgAj+n0EfMBAAA=
Subject: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Mar 2013 23:13:08 -0000

WG,

Flemming has found an issue in Section D.1.5. This is that this section
actually redefined the default behavior of the a=sendrecv, a=recvonly,
a=sendonly. This is clearly unsuitable and I propose that we change the
current text:

D.1.5.  Directionality of media stream

   The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
   provide instructions about the direction the media streams flow
   within a session.  When using RTSP the SDP can be delivered to a
   client using either RTSP DESCRIBE or a number of RTSP external
   methods, like HTTP, FTP, and email.  Based on this the SDP applies to
   how the RTSP client will see the complete session.  Thus media
   streams delivered from the RTSP server to the client, would be given
   the "a=recvonly" attribute.

   The direction attributes are not commonly used in SDPs for RTSP, but
   may occur. "a=recvonly" in a SDP provided to the RTSP client MUST
   indicate that media delivery will only occur in the direction from
   the RTSP server to the client.  In SDP provided to the RTSP client
   that lacks any of the directionality attributes (a=recvonly,
   a=sendonly, a=sendrecv) MUST behave as if the "a=recvonly" attribute
   was received.  Note that this overrules the normal default rule
   defined in SDP[RFC4566].  The usage of "a=sendonly" or "a=sendrecv"
   is not defined, nor is the interpretation of SDP by other entities
   than the RTSP client.

To instead become:

D.1.5.  Directionality of media stream

   The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
   provide instructions about the direction the media streams flow
   within a session.  When using RTSP the SDP can be delivered to a
   client using either RTSP DESCRIBE or a number of RTSP external
   methods, like HTTP, FTP, and email.  Based on this the SDP applies to
   how the RTSP client will see the complete session.  Thus media
   streams delivered from the RTSP server to the client, would be given
   the "a=recvonly" attribute.

   "a=recvonly" in a SDP provided to the RTSP client indicates that
   media delivery will only occur in the direction from the RTSP server
   to the client.  In SDP provided to the RTSP client that lacks any of
   the directionality attributes (a=recvonly, a=sendonly, a=sendrecv)
   would be interpreated as having a=sendrecv.  At the time of writing
   there exist no RTSP mode suitable for media traffic in the direction
   from the RTSP client to the server.  Thus all RTSP SDP SHOULD have
   a=recvonly attribute when using the PLAY mode defined in this
   document.  If future modes are defined for media in client to server
   direction, then usage of a=sendonly, or a=sendrecv may become
   suitable to indicate intended media directions.  The usage of
   "a=sendonly" or "a=sendrecv" SHOULD then be well defined.

This means that we expect SDP files for RTSP 2.0 to do contain the
directionality attribute.

Please provide feedback on this proposal.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From btv1==786c9b4b8d3==HKaplan@acmepacket.com  Thu Mar 14 22:38:09 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5D21F9195 for ; Thu, 14 Mar 2013 22:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066,  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 irjl16xJsdAg for ; Thu, 14 Mar 2013 22:38:08 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id C311221F9193 for ; Thu, 14 Mar 2013 22:38:08 -0700 (PDT)
X-ASG-Debug-ID: 1363325886-03fc217260fae8f0001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id A9NuMqk69OYhYY1j (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Mar 2013 01:38:06 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 15 Mar 2013 01:38:06 -0400
From: Hadriel Kaplan 
To: "Simo.Veikkolainen@nokia.com" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIT9E3TAO6Xjtq0ONCRsMcgqXQA==
Date: Fri, 15 Mar 2013 05:38:04 +0000
Message-ID: 
References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0E0C4CA545E7C34D825DF6EBA5EC7B80@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363325886
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125245 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Cc: "" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 05:48:33 -0000

For section 3.1.2, page 9:
  The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

What does that sentence actually mean??  What's a "situation" where an exis=
ting mechanism *can* be used?

Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they canno=
t both be in an offer? =20
Does it mean 'ccap' MUST NOT be used if it's technically possible to accomp=
lish using ICE, even if the device in question doesn't support ICE?

When is it ok to use a ccap containing an IP4 or IP6 address?

-hadriel


On Mar 13, 2013, at 11:08 AM, Simo.Veikkolainen@nokia.com wrote:

> Hello,
>=20
> We just submitted a new version of the miscellaneous-caps draft, with tex=
t that states that if the connection data capability attribute (a=3Dccap) i=
s used the port number in the resulting SDP MUST be the same as in the orig=
inal "m=3D" line, except for PSTN type bearers (when the port number used i=
s 9).
>=20
> Regards,
> Simo
>=20


From btv1==786c9b4b8d3==HKaplan@acmepacket.com  Thu Mar 14 23:11:16 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443C821F918D for ; Thu, 14 Mar 2013 23:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 hO5DBBEcxR-b for ; Thu, 14 Mar 2013 23:11:15 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2E21F9188 for ; Thu, 14 Mar 2013 23:11:15 -0700 (PDT)
X-ASG-Debug-ID: 1363327873-03fc21725ffb0370001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id DMd4WcrhdQLCXuwi (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Mar 2013 02:11:13 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 15 Mar 2013 02:11:13 -0400
From: Hadriel Kaplan 
To: "Simo.Veikkolainen@nokia.com Veikkolainen" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIUPkbSOR6Ns9c0GQFY3QLJiTKA==
Date: Fri, 15 Mar 2013 06:11:12 +0000
Message-ID: <8680FAA9-F3DC-48FD-8CEC-82E801229072@acmepacket.com>
References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <05A4E5A1EC223740AD4C4E2F0597D986@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363327873
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125247 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 06:11:16 -0000

Sorry, I didn't notice there was a lengthy email chain about this topic.  I=
gnore my email below.  It appears from the later emails that others were al=
so confused by the wording of that section, but they know what they meant i=
t to say.

Although I still have one simple question: when is it ok to use a 'ccap' at=
tribute containing either an IP4 or IP6 address?

For example, how is this useful:

    m=3Daudio 9 PSTN -
    c=3DPSTN E164 +15555556666
    a=3Dccap:1 IN IP4 198.51.100.7
    a=3Dtcap:2 RTP/AVP
    a=3Domcap:1 0

Since there is no port number being offered for the IPv4 ccap, and the numb=
er 9 is being used for PSTN, how would this actually work??

-hadriel


On Mar 15, 2013, at 1:38 AM, Hadriel Kaplan 
 wrote:

>=20
> For section 3.1.2, page 9:
>  The 'ccap' attribute MUST NOT be used in
>  situations where an existing mechanism (such as Interactive
>  Connectivity Establishment (ICE) [RFC5245]) can be used to select
>  between different connection addresses (e.g.  "IP4" and "IP6" or
>  different IP addresses within the same IP address family).
>=20
> What does that sentence actually mean??  What's a "situation" where an ex=
isting mechanism *can* be used?
>=20
> Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they can=
not both be in an offer? =20
> Does it mean 'ccap' MUST NOT be used if it's technically possible to acco=
mplish using ICE, even if the device in question doesn't support ICE?
>=20
> When is it ok to use a ccap containing an IP4 or IP6 address?
>=20
> -hadriel
>=20
>=20
> On Mar 13, 2013, at 11:08 AM, Simo.Veikkolainen@nokia.com wrote:
>=20
>> Hello,
>>=20
>> We just submitted a new version of the miscellaneous-caps draft, with te=
xt that states that if the connection data capability attribute (a=3Dccap) =
is used the port number in the resulting SDP MUST be the same as in the ori=
ginal "m=3D" line, except for PSTN type bearers (when the port number used =
is 9).
>>=20
>> Regards,
>> Simo
>>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From mohamed.boucadair@orange.com  Thu Mar 14 23:36:34 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F821F90CE for ; Thu, 14 Mar 2013 23:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level: 
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, UNPARSEABLE_RELAY=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 t1FLerNibja4 for ; Thu, 14 Mar 2013 23:36:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A594F21F90CC for ; Thu, 14 Mar 2013 23:36:17 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 37A5C324101; Fri, 15 Mar 2013 07:36:16 +0100 (CET)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1C88E238048; Fri, 15 Mar 2013 07:36:16 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 15 Mar 2013 07:36:16 +0100
From: 
To: Flemming Andreasen , Andrew Allen 
Date: Fri, 15 Mar 2013 07:36:14 +0100
Thread-Topic: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: Ac4g9AmsKwiby/2FSP25NtQLJoerlQAUllqg
Message-ID: <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr>
References:  <5142356F.3060201@cisco.com>
In-Reply-To: <5142356F.3060201@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EB7F296B6PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.15.60018
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D Action:	draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 06:36:34 -0000

--_000_94C682931C08B048B7A8645303FDC9F36EB7F296B6PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Felmming,

If you are looking for something written, you can read the minutes in the A=
naheim meeting (In http://tools.ietf.org/wg/mmusic/minutes?item=3Dminutes77=
.html), you can read the following:

              To conclude the WG chair report, Jean-Francois clarified the
              status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's
              slides #9).
              This Internet-Draft was mistakenly accepted as a WG document
              without confirmation on the list.

              After a brief recap of the I-D history and scope, several
              comments were made in support of continuing the work as part =
of
              a WG item as long as the scope does not overlap with ICE for
              IPv4-IPv6 connection address negotiations:
                - Roni Even indicated support for the work and noted that t=
he
                  b parameter was part of the original SDP capability
                  negotiation framework.
                - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Culle=
n
                  Jennings are in favor of the work item as long as its sco=
pe
                  is clarified to not overlap with ICE for IPv4-IPv6 addres=
s
                  negotiation.
                - Ingemar Johansson also expressed support for it
               There was strong support for continuing to define a capabili=
ty
               parameter for b, i and some concerns with the ccap parameter=
.
               More discussions occurred at the end of the meeting when the
               document was presented, see notes below.

               Jean-Francois proposed the next steps:
                - the WG chairs will confirm the interest for a WG item to
                  define additional SDP cap neg parameters (b and i lines)
                - Pending AD approval, the WG item will be chartered
                - Simo V. will re-submit an updated Internet-Draft as an
                  individual submission
                - then the chairs will ask the list if the Working Group
                  supports making Simo's individual submission as the WG
                  draft.

The current discussion shows there is a confusion in the current text and i=
t is worth to be clarified.

Cheers,

Med

________________________________
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part de=
 Flemming Andreasen
Envoy=E9 : jeudi 14 mars 2013 21:39
=C0 : Andrew Allen
Cc : jonathan@vidyo.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt


On 3/14/13 3:50 PM, Andrew Allen wrote:

I am not sure if anything is recorded in any minutes but we had an offline =
discussion to remove the roadblock on this with Jonathan to address his con=
cern that this was a potential alternative to ICE and addressed this with t=
he current text. This text and the reason behind it I think was pointed out=
 on the list during Quebec or shortly after.

Can you find the message or recall who sent it ?

Also, the Quebec meeting was in July 2011. Tracing back we have:

a) The initial (?) individul versions of the draft (2008/2009):     http://=
tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
b) Another individual take on the draft (August 2011+):         http://tool=
s.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
c) The intial WG version of the draft (March 2012+):             http://too=
ls.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

The "a)" version did indeed position the draft as an alternative to ICE, ho=
wever all "b)" and "c)" versions changed this as per the previous discussio=
n.

I'm still looking for anything written anywhere that suggests that the text=
 in "b)" and "c)" does not represent consensus and/or that consensus is tha=
t the mechanism MUST always be prohibited from negotiating IP4/IP6 addresse=
s (as opposed to just when ICE is not available).

Thanks

-- Flemming


From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time
To: Stach, Thomas 
Cc: Andrew Allen; jonathan@vidyo.com ; mmusic@ietf.org 
Subject: Re: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellane=
ous-caps-04.txt

As to ccap not being an alternative to ICE we are all in agreement on that =
- the lack of port negotiation alone makes that clear (it simply doesn't wo=
rk without that).

As to ccap being explicitly forbidden to express IP4 and/or IP6 addresses a=
s alternatives, can somebody please point me to either meeting minutes or m=
ailing list discussion to that effect ? The only thing I have found is the =
port discussion we had in Taipei, where we agreed not to add a port capabil=
ity. From http://www.ietf.org/proceedings/82/minutes/mmusic.htm:

Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt
Simo presented his slides.
Simo explained the need to be able to indicate alternative port numbers, bu=
t PSTN media, port number doesn't make sense. The CS draft says use port nu=
mber 9 (the discard port). We have to put something there because required =
by SDP syntax. If an RTP stream is offered, then a regular port number shou=
ld be written instead. The problem arises when both CS and RTP streams are =
offered at the same time, one as an alternative of the other. Then, the por=
t number makes sense for RTP but not for CS, but still, there is a single p=
lace to write the port number in the SDP, so, has to be shared by both alte=
rnative media streams.
Possible solutions:
1. Circuit-switched media uses the same port as RTP media even though the p=
ort is not really used
2. Extend capneg with a port number capability attribute, restricting its u=
se to cases where ICE cannot be used.
3.  Select anything as a port number and say "do not care on reception".
Jonathan Lennox suggested saying that port numbers not equal 0 have to be i=
gnored.
Hadriel Kaplan asked if middle boxes not supporting this stuff can be broke=
n. The discussion is moved offline.
There are questions on how could be possible to indicate preference for one=
 media stream above the alternative.
Miguel Garcia suggested using port 9 if it works. If not take anything not =
equal 0. Receiver has to ignore.
In general, there was pushback on the port negotiation approach. The author=
s should explore a solution along the third option: write the RTP port numb=
er in the "m=3D" line. If CS alternative is chosen, discard the port number=
 on reception.


Apart from that, the only thing I'm aware of is the 4 WG versions of this d=
raft which have all said the same about IP4/IP6 and ICE, and again, that te=
xt was both WGLC'ed and reviewed by 2 volunteers without any concerns. Wher=
e does the alternate understanding come from ?

Thanks

-- Flemming



On 3/14/13 2:16 PM, Stach, Thomas wrote:
This is also my understanding
... although my initially proposed text does not reflect this correctly.

Regards
Thomas


________________________________
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org] Im Auftrag von Andrew Allen
Gesendet: Donnerstag, 14. M=E4rz 2013 14:10
An: jonathan@vidyo.com; fandreas@cisco.com
Cc: mmusic@ietf.org
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt


My understanding also was that we agreed that CCAP was not an alternative t=
o ICE.


From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen 
Cc: mohamed.boucadair@orange.com ; Andrew Alle=
n; mmusic@ietf.org 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt


On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.
What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).

Hi, Fleming --

My understanding of the WG consensus -- and my interpretation of the text i=
n the draft -- was stronger than this: ccap MUST NOT be used for the kinds =
of alternatives ICE can express, whether or not ICE is actually being used =
in a particular offer/answer.

If we're getting divergent interpretations of this document, we probably do=
 need to update its text.

--
Jonathan Lennox
jonathan@vidyo.com


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--_000_94C682931C08B048B7A8645303FDC9F36EB7F296B6PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Felmming,


 


If you are looking fo=
r=20
something written, you can read the minutes in the Anaheim meeting=20
(=
In http=
://tools.ietf.org/wg/mmusic/minutes?item=3Dminutes77.html),=20
you can read the following:


              To conclude the WG chair report, Jean-F=
rancois clarified the
              status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's
              slides #9).
              This Internet-Draft was mistakenly accepted as a WG document
              without confirmation on the list.
         =20
              After a brief recap of the I-D history and scope, several
              comments were made in support of continuing the work as part =
of
              a WG item as long as the scope does not overlap with ICE for
              IPv4-IPv6 connection address negotiations:
                - Roni Even indicated support for the work and noted that t=
he
                  b parameter was part of the original SDP capability
                  negotiation framework.
                - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Culle=
n
                  Jennings are in favor of the work item as long as its sco=
pe
                  is clarified to not overlap with ICE for IPv4-IPv6 addres=
s
                  negotiation.
                - Ingemar Johansson also expressed support for it
               There was strong support for continuing to define a capabili=
ty
               parameter for b, i and some concerns with the ccap parameter=
.
               More discussions occurred at the end of the meeting when the
               document was presented, see notes below.
         =20
               Jean-Francois proposed the next steps:
                - the WG chairs will confirm the interest for a WG item to
                  define additional SDP cap neg parameters (b and i lines)
                - Pending AD approval, the WG item will be chartered
                - Simo V. will re-submit an updated Internet-Draft as an
                  individual submission
                - then the chairs will ask the list if the Working Group
                  supports making Simo's individual submission as the WG
                  draft.
Th=
e current discussion shows there is a confusion in the current text and it =
is worth to be clarified.
C=
heers,
Med



  

  

  De : mmusic-bounces@ietf.org=20
  [mailto:mmusic-bounces@ietf.org] De la part de Flemming=20
  Andreasen
Envoy=E9 : jeudi 14 mars 2013 21:39
=C0&nb=
sp;:=20
  Andrew Allen
Cc : jonathan@vidyo.com;=20
  mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action:=20
  draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


  


  
On 3/14/13 3:50 PM, Andrew Allen wrote:
<=
/DIV>
  
I=20
    am not sure if anything is recorded in any minutes but we had an offlin=
e=20
    discussion to remove the roadblock on this with Jonathan to address his=
=20
    concern that this was a potential alternative to ICE and addressed this=
 with=20
    the current text. This text and the reason behind it I think was pointe=
d out=20
    on the list during Quebec or shortly after.

=
Can you=20
  find the message or recall who sent it ? 

Also, the Quebec meeting=
 was=20
  in July 2011. Tracing back we have:

a) The initial (?) individul=20
  versions of the draft (2008/2009):     http=
://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
b)=20
  Another individual take on the draft (August 2011+):  =20
        http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps=

c)=20
  The intial WG version of the draft (March 2012+):    =20
          http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps=


The=20
  "a)" version did indeed position the draft as an alternative to ICE, howe=
ver=20
  all "b)" and "c)" versions changed this as per the previous discussion.=20
  

I'm still looking for anything written anywhere that suggests tha=
t the=20
  text in "b)" and "c)" does not represent consensus and/or that consensus =
is=20
  that the mechanism MUST always be prohibited from negotiating IP4/IP6=20
  addresses (as opposed to just when ICE is not available). 

Thanks=
=20
  

-- Flemming 


  

    From:=20
    Flemming Andreasen [mailto:fandreas@cisco.com]=20
    
Sent: Thursday, March 14, 2013 02:45 PM Central Standard=20
    Time
To: Stach, Thomas <thomas.stach@si=
emens-enterprise.com>=20
    
Cc: Andrew Allen; jonathan@vidyo.com <jonathan@vidyo.com>; mmusic@ietf.org <mmusic@ietf.org>=20
    
Subject: Re: AW: [MMUSIC] RE : I-D Action:=20
    draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt=20
    
 
As to ccap not being an alternative to ICE w=
e are=20
    all in agreement on that - the lack of port negotiation alone makes tha=
t=20
    clear (it simply doesn't work without that). 

As to ccap being=20
    explicitly forbidden to express IP4 and/or IP6 addresses as alternative=
s,=20
    can somebody please point me to either meeting minutes or mailing list=
=20
    discussion to that effect ? The only thing I have found is the port=20
    discussion we had in Taipei, where we agreed not to add a port capabili=
ty.=20
    From http://www.ietf.org/proceedings/82/minutes/mmu=
sic.htm:
<quote>

    Miscellaneous=20
    Capabilities Negotiation in SDP (Simo Veikkolainen,=20
10)

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

    draft-garcia-mmus=
ic-sdp-miscellaneous-caps-00.txt

    

    Simo presented hi=
s slides=
.

    

    Simo explained th=
e need=20
    to be able to indicate alternative port numbers, but PSTN media, port n=
umber=20
    doesn't make sense. The CS draft says use port number 9 (the discard po=
rt).=20
    We have to put something there because required by SDP syntax. If an RT=
P=20
    stream is offered, then a regular port number should be written instead=
. The=20
    problem arises when both CS and RTP streams are offered at the same tim=
e,=20
    one as an alternative of the other. Then, the port number makes sense f=
or=20
    RTP but not for CS, but still, there is a single place to write the por=
t=20
    number in the SDP, so, has to be shared by both alternative media=20
    streams.

    

    Possible=20
    solutions:

    

    1.=20
    Circuit-switched media uses the same port as RTP media even though the =
port=20
    is not really used

    2.=20
    Extend capneg with a port number capability attribute, restricting its =
use=20
    to cases where ICE cannot be used.

    3.<=
SPAN>  Select anything as a =
port=20
    number and say "do not care on reception".

    

    Jon=
athan=20
    Lennox suggested saying that port numbers not equal 0 have to be=20
    ignored.

    

    Had=
riel=20
    Kaplan asked if middle boxes not supporting this stuff can be broken. T=
he=20
    discussion is moved offline.

    

    The=
re are=20
    questions on how could be possible to indicate preference for one media=
=20
    stream above the alternative.

    

    Mig=
uel=20
    Garcia suggested using port 9 if it works. If not take anything not equ=
al 0.=20
    Receiver has to ignore.

    

    In=
=20
    general, there was pushback on the port negotiation approach. The autho=
rs=20
    should explore a solution along the third option: write the RTP port nu=
mber=20
    in the "m=3D" line. If CS alternative is chosen, discard the port numbe=
r on=20
    reception.
</quote>

Apart from that, the onl=
y=20
    thing I'm aware of is the 4 WG versions of this draft which have all sa=
id=20
    the same about IP4/IP6 and ICE, and again, that text was both WGLC'ed a=
nd=20
    reviewed by 2 volunteers without any concerns. Where does the alternate=
=20
    understanding come from ? 

Thanks 

-- Flemming=20





    
On 3/14/13 2:16 PM, Stach, Thomas=20
wrote:

    
      
      
Thi=
s is also=20
      my understanding 

      
...=
 although=20
      my initially proposed text does not reflect this=20
      correctly.

      
 

      
Regards
Thomas 

      
 


      
        

        

        Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im =
Auftrag=20
        von Andrew Allen
Gesendet: Donnerstag, 14. M=E4rz 201=
3=20
        14:10
An: jonathan@vidyo.com; fandreas@cisco.com
Cc: mmusic@ietf.org
Betreff: Re:=
=20
        [MMUSIC] RE : I-D Action:=20
        draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


My=20
        understanding also was that we agreed that CCAP was not an alternat=
ive=20
        to ICE.

 

        Fr=
om:=20
        Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent=
:=20
        Thursday, March 14, 2013 01:06 PM Central Standard Time
To:=20
        Flemming Andreasen <fandreas@cisco.com> 
Cc: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>; =
Andrew=20
        Allen; mmusic@ietf.org <mmusic@ietf.org> 
Subject=
:=20
        Re: [MMUSIC] RE : I-D Action:=20
        draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt=20
        
 


        

        
On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:

        

          

          
On 3/14/13 11:40 AM, mohamed.boucadair@orange.com=20
          wrote:

          
            
Re-,

            
 

            
What is important=
 is the=20
            quality of produced documents. The content of the document is n=
ot=20
            frozen and unless I'm mistaken there is not IETF=20
            LC.

            

Correc=
t. 

          
            
What I understand=
 from the=20
            text in the draft is: ccap is allowed to signal an IPv4@ and IP=
v6@=20
            if ICE is not supported.

            

ccap i=
s not=20
          prohibited from doing so in the absence of ICE, however as explai=
ned=20
          in the document
1) When the IETF Standard Track mechanism ICE =
is=20
          available, ccap MUST NOT signal an IPv4/IPV6 address=20
          alternative.
2) The draft does (intentionally) not provide a f=
ull=20
          solution for negotiating alternative IP-addresses since we have a=
=20
          Standards Track mechanism for doing so (ICE). 

        


        
Hi, Fleming --

        


        
My understanding of the WG consensus -- and my interpretation =
of=20
        the text in the draft -- was stronger than this: ccap MUST NOT be u=
sed=20
        for the kinds of alternatives ICE can express, whether or not ICE i=
s=20
        actually being used in a particular offer/answer.

        


        
If we're getting divergent interpretations of this document, w=
e=20
        probably do need to update its text.


        

        --

        Jonathan=20
        Lennox
jonathan@vidyo.com


---------------------------------------------------------=
------------=20
        
This transmission (including any attachments) may contain=20
        confidential information, privileged material (including material=20
        protected by the solicitor-client or other applicable privileges), =
or=20
        constitute non-public information. Any use of this information by a=
nyone=20
        other than the intended recipient is prohibited. If you have receiv=
ed=20
        this transmission in error, please immediately reply to the sender =
and=20
        delete this information from your system. Use, dissemination,=20
        distribution, or reproduction of this transmission by unintended=20
        recipients is not authorized and may be unlawful.=20
    
-----------------------------------------=
----------------------------=20
    
This transmission (including any attachments) may contain confident=
ial=20
    information, privileged material (including material protected by the=20
    solicitor-client or other applicable privileges), or constitute non-pub=
lic=20
    information. Any use of this information by anyone other than the inten=
ded=20
    recipient is prohibited. If you have received this transmission in erro=
r,=20
    please immediately reply to the sender and delete this information from=
 your=20
    system. Use, dissemination, distribution, or reproduction of this=20
    transmission by unintended recipients is not authorized and may be unla=
wful.=20
  


--_000_94C682931C08B048B7A8645303FDC9F36EB7F296B6PUEXCB1Bnante_--

From Simo.Veikkolainen@nokia.com  Fri Mar 15 05:04:19 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821621F8D98 for ; Fri, 15 Mar 2013 05:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.849
X-Spam-Level: 
X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 9DVPcY-ZR4v9 for ; Fri, 15 Mar 2013 05:04:11 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id F32BE21F8775 for ; Fri, 15 Mar 2013 05:04:10 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2FC44d9014092; Fri, 15 Mar 2013 14:04:04 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 15 Mar 2013 14:04:03 +0200
Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Fri, 15 Mar 2013 12:04:02 +0000
From: 
To: , , 
Thread-Topic: [MMUSIC] RE : I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIUd0IL+cDqRW3kaJdA/qHhgy+Jiml7oA
Date: Fri, 15 Mar 2013 12:04:02 +0000
Message-ID: 
References:  <5142356F.3060201@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-version: 3.5.9.3
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ird4Ku9EHHRTe4GqcFO71TcbY0TPGmDhj3rD9kqVWzqwx5r0d0vHCewiR44ySEL3YVZvZ1mKCsXdwLucmsw6NjWis92svu9ni7SDithirT9bJQNKCInI6gp9Zvwu+G7YGgtOk3t/Vif5hFECEIwH5A4kcT9X3BU3iVFDAdLs4NhdGYRkwoVmMRQCor3pUtc1L8/7cEF/4qZ4k1JnP6cblfn9XsbITV5N+A2Y/f1pZE+YbCeAmeLQ4FG2QgKBy8gDQNO87cup3AgUPbVbyiaCQ9I=
x-originating-ip: [62.78.254.72]
Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B21099590008AM1MPN1026mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Mar 2013 12:04:03.0412 (UTC) FILETIME=[2F9E5940:01CE2175]
X-Nokia-AV: Clean
Cc: jonathan@vidyo.com, mmusic@ietf.org
Subject: Re: [MMUSIC] RE : I-D	Action:	draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 12:04:20 -0000

--_000_D09DAE6B636851459F7575D146EFB54B21099590008AM1MPN1026mg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think this goes all the way back to IETF68, where an agreement was made t=
o use ICE for future address type selection (deprecating ANAT).

I couldn't find a written statement in minutes on ccap being explicitly for=
bidden to express IP4 and/or IP6 addresses as alternatives - but my thought=
 has been that alternative IP addresses may only be offered with ICE. This =
was also reflected in by Jean-Francois (http://www.ietf.org/mail-archive/we=
b/mmusic/current/msg07916.html) where he says " As for proposing IPv4/IPv6 =
alternatives, ICE deprecates ANAT and is the preferred solution the WG has =
chosen so far per IETF#68. "

Simo


From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext mohamed.boucadair@orange.com
Sent: 15. maaliskuuta 2013 8:36
To: Flemming Andreasen; Andrew Allen
Cc: jonathan@vidyo.com; mmusic@ietf.org
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt

Felmming,

If you are looking for something written, you can read the minutes in the A=
naheim meeting (In http://tools.ietf.org/wg/mmusic/minutes?item=3Dminutes77=
.html), you can read the following:

              To conclude the WG chair report, Jean-Francois clarified the

              status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's

              slides #9).

              This Internet-Draft was mistakenly accepted as a WG document

              without confirmation on the list.



              After a brief recap of the I-D history and scope, several

              comments were made in support of continuing the work as part =
of

              a WG item as long as the scope does not overlap with ICE for

              IPv4-IPv6 connection address negotiations:

                - Roni Even indicated support for the work and noted that t=
he

                  b parameter was part of the original SDP capability

                  negotiation framework.

                - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Culle=
n

                  Jennings are in favor of the work item as long as its sco=
pe

                  is clarified to not overlap with ICE for IPv4-IPv6 addres=
s

                  negotiation.

                - Ingemar Johansson also expressed support for it

               There was strong support for continuing to define a capabili=
ty

               parameter for b, i and some concerns with the ccap parameter=
.

               More discussions occurred at the end of the meeting when the

               document was presented, see notes below.



               Jean-Francois proposed the next steps:

                - the WG chairs will confirm the interest for a WG item to

                  define additional SDP cap neg parameters (b and i lines)

                - Pending AD approval, the WG item will be chartered

                - Simo V. will re-submit an updated Internet-Draft as an

                  individual submission

                - then the chairs will ask the list if the Working Group

                  supports making Simo's individual submission as the WG

                  draft.

The current discussion shows there is a confusion in the current text and i=
t is worth to be clarified.

Cheers,

Med

________________________________
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part de=
 Flemming Andreasen
Envoy=E9 : jeudi 14 mars 2013 21:39
=C0 : Andrew Allen
Cc : jonathan@vidyo.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-c=
aps-04.txt

On 3/14/13 3:50 PM, Andrew Allen wrote:

I am not sure if anything is recorded in any minutes but we had an offline =
discussion to remove the roadblock on this with Jonathan to address his con=
cern that this was a potential alternative to ICE and addressed this with t=
he current text. This text and the reason behind it I think was pointed out=
 on the list during Quebec or shortly after.
Can you find the message or recall who sent it ?

Also, the Quebec meeting was in July 2011. Tracing back we have:

a) The initial (?) individul versions of the draft (2008/2009):     http://=
tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
b) Another individual take on the draft (August 2011+):         http://tool=
s.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
c) The intial WG version of the draft (March 2012+):             http://too=
ls.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

The "a)" version did indeed position the draft as an alternative to ICE, ho=
wever all "b)" and "c)" versions changed this as per the previous discussio=
n.

I'm still looking for anything written anywhere that suggests that the text=
 in "b)" and "c)" does not represent consensus and/or that consensus is tha=
t the mechanism MUST always be prohibited from negotiating IP4/IP6 addresse=
s (as opposed to just when ICE is not available).

Thanks

-- Flemming



From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time
To: Stach, Thomas 
Cc: Andrew Allen; jonathan@vidyo.com ; mmusic@ietf.org 
Subject: Re: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellane=
ous-caps-04.txt

As to ccap not being an alternative to ICE we are all in agreement on that =
- the lack of port negotiation alone makes that clear (it simply doesn't wo=
rk without that).

As to ccap being explicitly forbidden to express IP4 and/or IP6 addresses a=
s alternatives, can somebody please point me to either meeting minutes or m=
ailing list discussion to that effect ? The only thing I have found is the =
port discussion we had in Taipei, where we agreed not to add a port capabil=
ity. From http://www.ietf.org/proceedings/82/minutes/mmusic.htm:


Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt
Simo presented his slides.
Simo explained the need to be able to indicate alternative port numbers, bu=
t PSTN media, port number doesn't make sense. The CS draft says use port nu=
mber 9 (the discard port). We have to put something there because required =
by SDP syntax. If an RTP stream is offered, then a regular port number shou=
ld be written instead. The problem arises when both CS and RTP streams are =
offered at the same time, one as an alternative of the other. Then, the por=
t number makes sense for RTP but not for CS, but still, there is a single p=
lace to write the port number in the SDP, so, has to be shared by both alte=
rnative media streams.
Possible solutions:
1. Circuit-switched media uses the same port as RTP media even though the p=
ort is not really used
2. Extend capneg with a port number capability attribute, restricting its u=
se to cases where ICE cannot be used.
3.  Select anything as a port number and say "do not care on reception".
Jonathan Lennox suggested saying that port numbers not equal 0 have to be i=
gnored.
Hadriel Kaplan asked if middle boxes not supporting this stuff can be broke=
n. The discussion is moved offline.
There are questions on how could be possible to indicate preference for one=
 media stream above the alternative.
Miguel Garcia suggested using port 9 if it works. If not take anything not =
equal 0. Receiver has to ignore.
In general, there was pushback on the port negotiation approach. The author=
s should explore a solution along the third option: write the RTP port numb=
er in the "m=3D" line. If CS alternative is chosen, discard the port number=
 on reception.


Apart from that, the only thing I'm aware of is the 4 WG versions of this d=
raft which have all said the same about IP4/IP6 and ICE, and again, that te=
xt was both WGLC'ed and reviewed by 2 volunteers without any concerns. Wher=
e does the alternate understanding come from ?

Thanks

-- Flemming


On 3/14/13 2:16 PM, Stach, Thomas wrote:
This is also my understanding
... although my initially proposed text does not reflect this correctly.

Regards
Thomas


________________________________
Von: mmusic-bounces@ietf.org [mailto:mmusic=
-bounces@ietf.org] Im Auftrag von Andrew Allen
Gesendet: Donnerstag, 14. M=E4rz 2013 14:10
An: jonathan@vidyo.com; fandreas@cisco.com
Cc: mmusic@ietf.org
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt

My understanding also was that we agreed that CCAP was not an alternative t=
o ICE.


From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen 
Cc: mohamed.boucadair@orange.com ; Andrew Alle=
n; mmusic@ietf.org 
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-=
caps-04.txt


On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:


On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,

What is important is the quality of produced documents. The content of the =
document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.

What I understand from the text in the draft is: ccap is allowed to signal =
an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as expl=
ained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).

Hi, Fleming --

My understanding of the WG consensus -- and my interpretation of the text i=
n the draft -- was stronger than this: ccap MUST NOT be used for the kinds =
of alternatives ICE can express, whether or not ICE is actually being used =
in a particular offer/answer.

If we're getting divergent interpretations of this document, we probably do=
 need to update its text.

--
Jonathan Lennox
jonathan@vidyo.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--_000_D09DAE6B636851459F7575D146EFB54B21099590008AM1MPN1026mg_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I think this goes all the=
 way back to IETF68, where an agreement was made to use ICE for future addr=
ess type selection (deprecating ANAT).


 <=
/p>

I couldn’t find a w=
ritten statement in minutes on ccap being explicitly forbidden to express I=
P4 and/or IP6 addresses as alternatives – but my thought has been
 that alternative IP addresses may only be offered with ICE. This was also =
reflected in by Jean-Francois (http://www.ietf.org/mail-archive/web/mmus=
ic/current/msg07916.html) where
 he says ” 
As for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT and is the pre=
ferred solution the WG has chosen so far per IETF#68. “  &n=
bsp;          



 <=
/p>

Simo

 <=
/p>

 <=
/p>





From: mmusic-boun=
ces@ietf.org
 [mailto:mmusic-bounces@ietf.org] On Behalf Of ext mohamed.boucadair=
@orange.com

Sent: 15. maaliskuuta 2013 8:36

To: Flemming Andreasen; Andrew Allen

Cc: jonathan@vidyo.com; mmusic@ietf.org

Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscell=
aneous-caps-04.txt






 


Felmming,


 


If you are looking for something written, you c=
an read the minutes in the Anaheim meeting (In
h=
ttp://tools.ietf.org/wg/mmusic/minutes?item=3Dminutes77.html), you can =
read the following:


       &=
nbsp;      To conclude the WG chair report, Jean-F=
rancois clarified the


       &=
nbsp;      status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's


       &=
nbsp;      slides #9).


       &=
nbsp;      This Internet-Draft was mistakenly acce=
pted as a WG document


       &=
nbsp;      without confirmation on the list.<=
/o:p>


       &=
nbsp;  


       &=
nbsp;      After a brief recap of the I-D his=
tory and scope, several


       &=
nbsp;      comments were made in support of contin=
uing the work as part of


       &=
nbsp;      a WG item as long as the scope does not=
 overlap with ICE for


       &=
nbsp;      IPv4-IPv6 connection address negotiatio=
ns:


       &=
nbsp;        - Roni Even indicated suppo=
rt for the work and noted that the


       &=
nbsp;          b parameter was=
 part of the original SDP capability


       &=
nbsp;          negotiation fra=
mework.


       &=
nbsp;        - John Elwell, Gonzalo Cama=
rillo, Jonathan Lennox and Cullen


       &=
nbsp;          Jennings are in=
 favor of the work item as long as its scope


       &=
nbsp;          is clarified to=
 not overlap with ICE for IPv4-IPv6 address


       &=
nbsp;          negotiation.


       &=
nbsp;        - Ingemar Johansson also ex=
pressed support for it


       &=
nbsp;       There was strong support for cont=
inuing to define a capability


       &=
nbsp;       parameter for b, i and some conce=
rns with the ccap parameter.


       &=
nbsp;       More discussions occurred at the =
end of the meeting when the


       &=
nbsp;       document was presented, see notes=
 below.


       &=
nbsp;  


       &=
nbsp;       Jean-Francois proposed the n=
ext steps:


       &=
nbsp;        - the WG chairs will confir=
m the interest for a WG item to


       &=
nbsp;          define addition=
al SDP cap neg parameters (b and i lines)


       &=
nbsp;        - Pending AD approval, the =
WG item will be chartered


       &=
nbsp;        - Simo V. will re-submit an=
 updated Internet-Draft as an


       &=
nbsp;          individual subm=
ission


       &=
nbsp;        - then the chairs will ask =
the list if the Working Group


       &=
nbsp;          supports making=
 Simo's individual submission as the WG


       &=
nbsp;          draft.


The current discussion shows there is a con=
fusion in the current text and it is worth to be clarified.


Cheers,


Med




 








De : mmusic-bounces@ietf.org =
[mailto:mmusic-bounces@ietf.org]
De la part de Flemming Andreasen

Envoy=E9 : jeudi 14 mars 2013 21:39

=C0 : Andrew Allen

Cc : jonathan@vidyo.com; mmusic@ietf.org

Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-mis=
cellaneous-caps-04.txt


 




On 3/14/13 3:50 PM, Andrew Allen wrote:







I am not sure if anything is recorded in any minutes but we had an offline =
discussion to remove the roadblock on this with Jonathan to address his con=
cern that this was a potential alternative to ICE and addressed this with t=
he current text. This text and the
 reason behind it I think was pointed out on the list during Quebec or shor=
tly after.




Can you find the message or recall who sent it ? 


Also, the Quebec meeting was in July 2011. Tracing back we have:



a) The initial (?) individul versions of the draft (2008/2009):  =
   
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap

b) Another individual take on the draft (August 2011+):   &nb=
sp;     
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
c) The intial WG version of the draft (March 2012+):    =
         
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps



The "a)" version did indeed position the draft as an alternative =
to ICE, however all "b)" and "c)" versions changed this=
 as per the previous discussion.




I'm still looking for anything written anywhere that suggests that the text=
 in "b)" and "c)" does not represent consensus and/or t=
hat consensus is that the mechanism MUST always be prohibited from negotiat=
ing IP4/IP6 addresses (as opposed to just when ICE is
 not available). 



Thanks 



-- Flemming 








 




From: Flemming=
 Andreasen [mailto:fandreas@cisco.com=
]


Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time

To: Stach, Thomas <thomas.stach@siemens-enterprise.com>


Cc: Andrew Allen; jonathan@vid=
yo.com
<jonathan@vidyo.com>; 
mmusic@ietf.org <mmusic@ietf.org&=
gt; 

Subject: Re: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-mis=
cellaneous-caps-04.txt


 




As to ccap not being an alternative to ICE we are al=
l in agreement on that - the lack of port negotiation alone makes that clea=
r (it simply doesn't work without that).




As to ccap being explicitly forbidden to express IP4 and/or IP6 addresses a=
s alternatives, can somebody please point me to either meeting minutes or m=
ailing list discussion to that effect ? The only thing I have found is the =
port discussion we had in Taipei,
 where we agreed not to add a port capability. From 
http://www.ietf.org/proceedings/82/minutes/mmusic.htm:

<quote>






Miscellaneous Capabilities Nego=
tiation in SDP (Simo Veikkolainen, 10)



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



draft-garcia-mmusic-sdp-m=
iscellaneous-caps-00.txt



Simo p=
resented his slides.



Simo e=
xplained the need to be able to indicate alternative port numbers, but PSTN=
 media, port number doesn't make sense. The CS draft says use port number 9=
 (the discard port). We have to put something
 there because required by SDP syntax. If an RTP stream is offered, then a =
regular port number should be written instead. The problem arises when both=
 CS and RTP streams are offered at the same time, one as an alternative of =
the other. Then, the port number
 makes sense for RTP but not for CS, but still, there is a single place to =
write the port number in the SDP, so, has to be shared by both alternative =
media streams.


Possib=
le solutions:



1. Cir=
cuit-switched media uses the same port as RTP media even though the port is=
 not really used<=
/p>


2. Ext=
end capneg with a port number capability attribute, restricting its use to =
cases where ICE cannot be used.



3.&nbs=
p; Select anything as a p=
ort number and say "do not care on reception".



Jonath=
an Lennox suggested saying that port numbers not equal 0 have to be ignored=
.



Hadrie=
l Kaplan asked if middle boxes not supporting this stuff can be broken. The=
 discussion is moved offline.<=
/o:p>



There =
are questions on how could be possible to indicate preference for one media=
 stream above the alternative.=




Miguel=
 Garcia suggested using port 9 if it works. If not take anything not equal =
0. Receiver has to ignore.



In gen=
eral, there was pushback on the port negotiation approach. The authors shou=
ld explore a solution along the third option: write the RTP port number in =
the "m=3D" line. If CS alternative is chosen,
 discard the port number on reception.

</quote>



Apart from that, the only thing I'm aware of is the 4 WG versions of this d=
raft which have all said the same about IP4/IP6 and ICE, and again, that te=
xt was both WGLC'ed and reviewed by 2 volunteers without any concerns. Wher=
e does the alternate understanding
 come from ? 



Thanks 



-- Flemming 










On 3/14/13 2:16 PM, Stach, Thomas wrote:<=
/p>







This is also my understanding







... although my initially proposed text d=
oes not reflect this correctly.






 






Regards

Thomas 






 






 








Von:
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von Andrew Allen

Gesendet: Donnerstag, 14. M=E4rz 2013 14:10

An: jonathan@vidyo.com; 
fandreas@cisco.com

Cc: mmusic@ietf.org

Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscell=
aneous-caps-04.txt




My understanding also was that we agreed that CCAP was not an alternative t=
o ICE.



 



 






On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrot=
e:















On 3/14/13 11:40 AM, 
mohamed.boucadair@orange.com wrote:






Re-,


 


What is important is the quality of produced do=
cuments. The content of the document is not frozen and unless I'm mistaken =
there is not IETF LC.


 




Correct. 






What I understand from the text in the draft is=
: ccap is allowed to signal an IPv4@ and IPv6@ if ICE is not supported.


 


ccap is not prohibited from doing so in the absence =
of ICE, however as explained in the document

1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT s=
ignal an IPv4/IPV6 address alternative.

2) The draft does (intentionally) not provide a full solution for negotiati=
ng alternative IP-addresses since we have a Standards Track mechanism for d=
oing so (ICE).







 






Hi, Fleming --






 






My understanding of the WG consensus -- and my inter=
pretation of the text in the draft -- was stronger than this: ccap MUST NOT=
 be used for the kinds of alternatives ICE can express, whether or not ICE =
is actually being used in a particular
 offer/answer.






 






If we're getting divergent interpretations of this d=
ocument, we probably do need to update its text.






 






--






Jonath=
an Lennox

jonathan@vidyo.com








--------------------------------------------------------------------- 

This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 








--------------------------------------------------------------------- 

This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 


 








--_000_D09DAE6B636851459F7575D146EFB54B21099590008AM1MPN1026mg_--

From andrew.hutton@siemens-enterprise.com  Fri Mar 15 05:08:25 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABAC21F9177 for ; Fri, 15 Mar 2013 05:08:25 -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 w1QW+j-dFO2r for ; Fri, 15 Mar 2013 05:08:24 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DD21F9176 for ; Fri, 15 Mar 2013 05:08:24 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 2785D23F05A2 for ; Fri, 15 Mar 2013 13:08:23 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 13:08:22 +0100
From: "Hutton, Andrew" 
To: "mmusic@ietf.org" 
Thread-Topic: Bundle and Complex ICE Scenarios
Thread-Index: Ac4g/Xe3HFOGVBvaRFWIAP3m48T0DQAdeyhQ
Date: Fri, 15 Mar 2013 12:08:22 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0689D588@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF0689CC99@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0689CC99@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Bundle and Complex ICE Scenarios
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 12:08:25 -0000

An example of why I have a concern can be seen in the bundle slides present=
ed in the mmusic session earlier this week http://www.ietf.org/proceedings/=
86/slides/slides-86-mmusic-9.pdf.

Slides 3 and 4 indicate that two offer answer cycles (Maybe 1.5) are needed=
 to get bundled media to flow and they show how the ports on the m-lines ar=
e used.  The 2nd offer contains the same port used in the 1st m-line of the=
 1st offer in all the bundled m-lines of the 2nd offer.

This would appear to conflict with the 2nd offer that is required in some I=
CE scenarios where the port used in the 2nd offer is chosen from one of the=
 candidates and does not match any port on the m-lines in the initial offer=
/answer.

I believe more analysis is needed and I will work on that.

It maybe that trying to come to a single solution covering rtcweb and all o=
ther environments would compromise the rtcweb solution which is not somethi=
ng we should do. Multiple solutions may be better than a single one that co=
mpromises quality.

Regards
Andy





> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hutton, Andrew
> Sent: 14 March 2013 17:47
> To: mmusic@ietf.org
> Subject: [MMUSIC] Bundle and Complex ICE Scenarios
>=20
> Having reviewed the various bundle proposals I don't believe enough
> attention has been made to issues around using bundle with ICE and
> especially some of the more complex ICE scenarios to verify that they
> will work or are optimal in these cases.
>=20
> For example there is no analysis of the following issues:
>=20
> 1. IPV6 / Dual Stack environments where it is necessary to generate
> candidates for multiple address families.
>=20
> 2. Scenarios involving Server Reflexive, Relayed Candidates, and TCP
> Candidates are required.
>=20
> Some of these scenarios relate to scenarios involving NAT's & Firewalls
> which we have started to analyse in http://tools.ietf.org/html/draft-
> hutton-rtcweb-nat-firewall-considerations-00.
>=20
> I intend to do some further analysis and look more closely at bundle in
> the context of these scenarios over the next couple of weeks but
> personally until this is done I cannot say whether the current bundle
> proposals meet our needs.
>=20
> Regards
> Andy
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From sean.sheedy@arrisi.com  Fri Mar 15 05:26:00 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3C21F9097 for ; Fri, 15 Mar 2013 05:26:00 -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_18=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 lc1aiIR9VZPu for ; Fri, 15 Mar 2013 05:26:00 -0700 (PDT)
Received: from arrisi.com (ironmail2.arrisi.com [216.234.147.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0297B21F907C for ; Fri, 15 Mar 2013 05:25:59 -0700 (PDT)
Received: from ([10.2.131.252]) by ironmail2.arrisi.com with ESMTP with TLS id CNFSXF1.55671030; Fri, 15 Mar 2013 08:25:52 -0400
Received: from Helen.ARRS.ARRISI.COM (10.2.141.37) by ATLOWA1.ARRS.ARRISI.com (10.2.131.252) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 08:25:52 -0400
Received: from CHIEXCAS2.ARRS.ARRISI.com (10.6.200.12) by Helen.ARRS.ARRISI.COM (10.2.141.37) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 15 Mar 2013 08:25:52 -0400
Received: from sean-netbook.osioda.org (10.6.159.6) by CHIEXCAS2.ARRS.ARRISI.com (10.6.200.12) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 07:25:51 -0500
Message-ID: <5143134A.90604@arrisi.com>
Date: Fri, 15 Mar 2013 08:25:46 -0400
From: Sean Sheedy 
Organization: ARRIS, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: 
References: <51425974.9070608@ericsson.com>
In-Reply-To: <51425974.9070608@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.6.159.6]
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 12:26:00 -0000

This change sounds good to me.  I would recommend changing "In SDP=20
provided ..." to "SDP provided ...".

Sean


On 03/14/2013 07:12 PM, Magnus Westerlund wrote:
> WG,
>
> Flemming has found an issue in Section D.1.5. This is that this section
> actually redefined the default behavior of the a=3Dsendrecv, a=3Drecvonly=
,
> a=3Dsendonly. This is clearly unsuitable and I propose that we change the
> current text:
>
> D.1.5.  Directionality of media stream
>
>     The SDP attributes "a=3Dsendrecv", "a=3Drecvonly" and "a=3Dsendonly"
>     provide instructions about the direction the media streams flow
>     within a session.  When using RTSP the SDP can be delivered to a
>     client using either RTSP DESCRIBE or a number of RTSP external
>     methods, like HTTP, FTP, and email.  Based on this the SDP applies to
>     how the RTSP client will see the complete session.  Thus media
>     streams delivered from the RTSP server to the client, would be given
>     the "a=3Drecvonly" attribute.
>
>     The direction attributes are not commonly used in SDPs for RTSP, but
>     may occur. "a=3Drecvonly" in a SDP provided to the RTSP client MUST
>     indicate that media delivery will only occur in the direction from
>     the RTSP server to the client.  In SDP provided to the RTSP client
>     that lacks any of the directionality attributes (a=3Drecvonly,
>     a=3Dsendonly, a=3Dsendrecv) MUST behave as if the "a=3Drecvonly" attr=
ibute
>     was received.  Note that this overrules the normal default rule
>     defined in SDP[RFC4566].  The usage of "a=3Dsendonly" or "a=3Dsendrec=
v"
>     is not defined, nor is the interpretation of SDP by other entities
>     than the RTSP client.
>
> To instead become:
>
> D.1.5.  Directionality of media stream
>
>     The SDP attributes "a=3Dsendrecv", "a=3Drecvonly" and "a=3Dsendonly"
>     provide instructions about the direction the media streams flow
>     within a session.  When using RTSP the SDP can be delivered to a
>     client using either RTSP DESCRIBE or a number of RTSP external
>     methods, like HTTP, FTP, and email.  Based on this the SDP applies to
>     how the RTSP client will see the complete session.  Thus media
>     streams delivered from the RTSP server to the client, would be given
>     the "a=3Drecvonly" attribute.
>
>     "a=3Drecvonly" in a SDP provided to the RTSP client indicates that
>     media delivery will only occur in the direction from the RTSP server
>     to the client.  In SDP provided to the RTSP client that lacks any of
>     the directionality attributes (a=3Drecvonly, a=3Dsendonly, a=3Dsendre=
cv)
>     would be interpreated as having a=3Dsendrecv.  At the time of writing
>     there exist no RTSP mode suitable for media traffic in the direction
>     from the RTSP client to the server.  Thus all RTSP SDP SHOULD have
>     a=3Drecvonly attribute when using the PLAY mode defined in this
>     document.  If future modes are defined for media in client to server
>     direction, then usage of a=3Dsendonly, or a=3Dsendrecv may become
>     suitable to indicate intended media directions.  The usage of
>     "a=3Dsendonly" or "a=3Dsendrecv" SHOULD then be well defined.
>
> This means that we expect SDP files for RTSP 2.0 to do contain the
> directionality attribute.
>
> Please provide feedback on this proposal.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--=20
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--
Sean Sheedy
Staff System Software Engineer, Media and Communications Systems
Sean.Sheedy@arrisi.com | 503-495-9454 (Phone)
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--


From magnus.westerlund@ericsson.com  Fri Mar 15 06:14:34 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96021F8FE1 for ; Fri, 15 Mar 2013 06:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.416
X-Spam-Level: 
X-Spam-Status: No, score=-105.416 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_18=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 7L0U43w9yDcg for ; Fri, 15 Mar 2013 06:14:33 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92A21F8FA4 for ; Fri, 15 Mar 2013 06:14:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-fa-51431eb63cda
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.ED.32353.6BE13415; Fri, 15 Mar 2013 14:14:31 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 15 Mar 2013 14:14:31 +0100
Message-ID: <51431EB4.1090407@ericsson.com>
Date: Fri, 15 Mar 2013 09:14:28 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Sean Sheedy 
References: <51425974.9070608@ericsson.com> <5143134A.90604@arrisi.com>
In-Reply-To: <5143134A.90604@arrisi.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje52OedAgyf3xSymLn/MYnFw3kYW ByaPu9/+sHgsWfKTKYApissmJTUnsyy1SN8ugSvjWGMrW8EalYp3ux4xNzAelOli5OSQEDCR +LzgMSuELSZx4d56ti5GLg4hgZOMEn8ntbKDJIQEljNKrFqfAWLzCmhLPNr6mgXEZhFQlTjy /hJYM5uAhcTNH41sILaoQLDEz1dnWCDqBSVOznwCZosIaEisP3ICrJ5ZQFjiwvnjTCC2sICT xIclN9ggdrlLfGvYxQhicwLVT7vSyQ5xnKTElhft7BC9ehJTrrYwQtjyEs1bZzND9GpLNDR1 sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15uvokRGKoHt/w22MG46b7YIUZpDhYlcd5w1wsB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhhPH5lylW3PrJyL5naBSndT09+tdWk2mBrx5/BS 3+cbV/79vSO3vs5uoRvbw5yNXytXVL/4sCJ6lfzWScc3L9247c/3uNmeKkHS/9czvbr5MX6+ 1Cl1r/fJztJa7f4HODLcHKfocyTcUfq2dUtAdF/zYt7MLwYLKqZaylUc/SZf4b505i1X3t+r lViKMxINtZiLihMBT0E8ViMCAAA=
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 13:14:34 -0000

Thanks,

Change applied to source.

Cheers

Magnus

On 2013-03-15 08:25, Sean Sheedy wrote:
> This change sounds good to me.  I would recommend changing "In SDP
> provided ..." to "SDP provided ...".
> 
> Sean
> 
> 
> On 03/14/2013 07:12 PM, Magnus Westerlund wrote:
>> WG,
>>
>> Flemming has found an issue in Section D.1.5. This is that this section
>> actually redefined the default behavior of the a=sendrecv, a=recvonly,
>> a=sendonly. This is clearly unsuitable and I propose that we change the
>> current text:
>>
>> D.1.5.  Directionality of media stream
>>
>>     The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
>>     provide instructions about the direction the media streams flow
>>     within a session.  When using RTSP the SDP can be delivered to a
>>     client using either RTSP DESCRIBE or a number of RTSP external
>>     methods, like HTTP, FTP, and email.  Based on this the SDP applies to
>>     how the RTSP client will see the complete session.  Thus media
>>     streams delivered from the RTSP server to the client, would be given
>>     the "a=recvonly" attribute.
>>
>>     The direction attributes are not commonly used in SDPs for RTSP, but
>>     may occur. "a=recvonly" in a SDP provided to the RTSP client MUST
>>     indicate that media delivery will only occur in the direction from
>>     the RTSP server to the client.  In SDP provided to the RTSP client
>>     that lacks any of the directionality attributes (a=recvonly,
>>     a=sendonly, a=sendrecv) MUST behave as if the "a=recvonly" attribute
>>     was received.  Note that this overrules the normal default rule
>>     defined in SDP[RFC4566].  The usage of "a=sendonly" or "a=sendrecv"
>>     is not defined, nor is the interpretation of SDP by other entities
>>     than the RTSP client.
>>
>> To instead become:
>>
>> D.1.5.  Directionality of media stream
>>
>>     The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
>>     provide instructions about the direction the media streams flow
>>     within a session.  When using RTSP the SDP can be delivered to a
>>     client using either RTSP DESCRIBE or a number of RTSP external
>>     methods, like HTTP, FTP, and email.  Based on this the SDP applies to
>>     how the RTSP client will see the complete session.  Thus media
>>     streams delivered from the RTSP server to the client, would be given
>>     the "a=recvonly" attribute.
>>
>>     "a=recvonly" in a SDP provided to the RTSP client indicates that
>>     media delivery will only occur in the direction from the RTSP server
>>     to the client.  In SDP provided to the RTSP client that lacks any of
>>     the directionality attributes (a=recvonly, a=sendonly, a=sendrecv)
>>     would be interpreated as having a=sendrecv.  At the time of writing
>>     there exist no RTSP mode suitable for media traffic in the direction
>>     from the RTSP client to the server.  Thus all RTSP SDP SHOULD have
>>     a=recvonly attribute when using the PLAY mode defined in this
>>     document.  If future modes are defined for media in client to server
>>     direction, then usage of a=sendonly, or a=sendrecv may become
>>     suitable to indicate intended media directions.  The usage of
>>     "a=sendonly" or "a=sendrecv" SHOULD then be well defined.
>>
>> This means that we expect SDP files for RTSP 2.0 to do contain the
>> directionality attribute.
>>
>> Please provide feedback on this proposal.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From worley@shell01.TheWorld.com  Fri Mar 15 07:32:14 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA421F8617 for ; Fri, 15 Mar 2013 07:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 hJpAvMI7acNm for ; Fri, 15 Mar 2013 07:32:13 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0421F85C4 for ; Fri, 15 Mar 2013 07:32:03 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2FEVKX2005994; Fri, 15 Mar 2013 10:31:22 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2FEVItX498630; Fri, 15 Mar 2013 09:31:20 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2FEVHJ9498642; Fri, 15 Mar 2013 10:31:17 -0400 (EDT)
Date: Fri, 15 Mar 2013 10:31:17 -0400 (EDT)
Message-Id: <201303151431.r2FEVHJ9498642@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Magnus Westerlund 
In-reply-to: <51425974.9070608@ericsson.com> (magnus.westerlund@ericsson.com)
References: <51425974.9070608@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 14:32:14 -0000

> From: Magnus Westerlund 
> 
>    "a=recvonly" in a SDP provided to the RTSP client MUST
>    indicate that media delivery will only occur in the direction from
>    the RTSP server to the client.

I know little about RTSP though I've worked with SIP a lot.  I think
you might want to flag this odd inconsistency between RTSP and SIP:

When SDP is used in offer-answer mode, the directionality attributes
indicate directionality *from the point of view of the sender of the
SDP*.  (RFC 3264 section 5.1) So a SIP offer containing "a=recvonly"
indicates that the offerer expects to *receive* media.

When SDP is used in session-announcement mode, the directionality
attributes indicate directionality *from the point of view of the
receiver of the SDP*.  (This is not stated directly in RFC 4566,
rather it says "a=recvonly: This specifies that the tools should be
started in receive-only mode where applicable." but eventually you can
track down that "the tools" means the receiver's device.)  So an RTSP
announcement containing "a=recvonly" indicates that the announcer
expects to *send* media.

This difference is not what I would have expected.  Initially, I
assumed the text in your draft had gotten the directions reversed
relative to reality.

You might want to mention this somewhere, e.g., after the first
paragraph of D.1.5, add the paragraph

    (Note that RTSP uses SDP in session-announcement mode [RFC 4566],
    in which the directionality attributes indicate the direction of
    media flow from the point view of the interpreter of the SDP.
    This contrasts with SDP in offer-answer mode [RFC 3264], in which
    the directionality attributes indicate the direction of media flow
    from the point of view of the generator of the SDP.)

Dale

From btv1==786c9b4b8d3==HKaplan@acmepacket.com  Fri Mar 15 09:53:54 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F821F8556 for ; Fri, 15 Mar 2013 09:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180,  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 4Vlu9UMUtbSo for ; Fri, 15 Mar 2013 09:53:52 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90721F859C for ; Fri, 15 Mar 2013 09:53:50 -0700 (PDT)
X-ASG-Debug-ID: 1363366426-03fc200f2562d190001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id 9TEVHaxvA0x9S2aw (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Mar 2013 12:53:46 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Fri, 15 Mar 2013 12:53:46 -0400
From: Hadriel Kaplan 
To: "Simo.Veikkolainen@nokia.com" 
Thread-Topic: [MMUSIC] I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-ASG-Orig-Subj: Re: [MMUSIC] I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIZ2oX80TZp0sXU2z/TVygd1ojw==
Date: Fri, 15 Mar 2013 16:53:45 +0000
Message-ID: 
References:  <5142356F.3060201@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363366426
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125284 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Cc: "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [MMUSIC] I-D	Action:	draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 16:53:54 -0000

That was my understanding as well - that ccap wouldn't be used to perform a=
lternate address family selection.  However the current text doesn't clearl=
y say that, but rather is confusing.  Mostly just because of the exact Engl=
ish words being used, I think.

Regardless, ccap can't really be used for alternate address selection anywa=
y, because it doesn't indicate a port number for the ccap alternate address=
.  It's technically possible to use the same port number for an IP4 and IP6=
 interface, of course, but it's not practical for many.

But because ccap doesn't support indicating a port number, it also can't be=
 used to indicate an IP address when the m/c=3D lines indicate a PSTN circu=
it, afaict.  Right?

If so, then why does ccap even support indicating an IP address to begin wi=
th?  Why isn't it *only* for indicating a PSTN circuit, when the m/c lines =
indicate an IP4 or IP6 default?  In other words, why not just change the AB=
NF of ccap to only support a PSTN type; or to never be for 'IP4' nor for 'I=
P6'.

-hadriel


On Mar 15, 2013, at 8:04 AM, Simo.Veikkolainen@nokia.com wrote:

> I think this goes all the way back to IETF68, where an agreement was made=
 to use ICE for future address type selection (deprecating ANAT).
> =20
> I couldn=92t find a written statement in minutes on ccap being explicitly=
 forbidden to express IP4 and/or IP6 addresses as alternatives =96 but my t=
hought has been that alternative IP addresses may only be offered with ICE.=
 This was also reflected in by Jean-Francois (http://www.ietf.org/mail-arch=
ive/web/mmusic/current/msg07916.html) where he says =94 As for proposing IP=
v4/IPv6 alternatives, ICE deprecates ANAT and is the preferred solution the=
 WG has chosen so far per IETF#68. =93            =20
> =20


From randy@qti.qualcomm.com  Fri Mar 15 11:50:17 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01D621F86E8 for ; Fri, 15 Mar 2013 11:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.224
X-Spam-Level: 
X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 c5qtAb3bWImK for ; Fri, 15 Mar 2013 11:50:16 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 272DF21F86D5 for ; Fri, 15 Mar 2013 11:50:15 -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=1363373416; x=1394909416; h=message-id:date:to:from:subject:cc:mime-version; bh=Duvbl8qTC4s024e/mWmdXeUFvH/cOD9fQZ3K9eKSVkg=; b=xRBdZGUB5Fxw4m1p7I1sjjH+rryAXsBBCgqgI7WuBWWG7TyIukkfjKUR TJySlRsoTcRKhCdRWK1pJiahDjrjSZ601JYQF4j5Gip/EtTA5BXv/KKo5 aj1Q1MEkX34jxn30fWbYVZU+t8uftiGtxbzqAtG58W6+txgZUKweKtsVG Y=;
X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208";a="30086197"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 15 Mar 2013 11:50:14 -0700
X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208";a="443061809"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Mar 2013 11:50:08 -0700
Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 11:50:07 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Fri, 15 Mar 2013 11:49:49 -0700
To: 
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.39.5]
Cc: ietf-languages-bounces@alvestrand.no, mmusic@ietf.org
Subject: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 18:50:17 -0000

Hi everyone,

Thanks very much for the productive discussion.  Here are my notes:

SDP or SIP:
- Use SDP for actual negotiation, but use SIP header to provide a hint
- Emergency services use case can use SDP for policy routing/handling decisions
- Other use cases may or may not have ability/desire to use SDP for 
this and can use the SIP header hint
- SDP useful in protocols other than SIP
- SIP header with hint is either a new header or caller preferences 
(RFC 3841), presumably Accept-Contact; caller sets media and language 
and optionally required; not clear if this matches our desired 
semantics
- SIP header is just a hint; it is not required to be sent or to be 
used on receipt; it is recommended to be sent

New SDP attribute(s) vs re-use of existing 'lang' attribute:
- Existing attribute semantics are unclear so should be avoided
- Minting new attributes is cheap

Directionality of SDP attributes:
- Define two new SDP media-level attributes: 'send-lang' and 
'recv-lang'.  In an offer, send-lang is a list in preference order of 
the languages the offerer wishes to send and recv-lang is a list in 
preference order of the languages the offerer wishes to receive.  In 
most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.  In an answer, 
send-lang is the accepted language the answerer will send (which in 
most cases should be one of the languages in the offer's recv-lang) 
and recv-lang is the accepted language the answerer expects to 
receive (which in most cases should be one of the languages in the 
offer's send-lang).

Advisory vs Required:
- Does call fail if no common language?
- Define token for use in offer to indicate caller's preference to 
fail call or not if no common language.
- One choice is to say that if the last character of the send-lang or 
recv-lan value an asterisk, this indicates a request to not fail the 
call (similar to SIP Accept-Language syntax).  Either way, the called 
party may ignore this, e.g., for the emergency services use case, a 
PSAP will likely not fail the call.

Other changes (from additional side discussions):
- Add advice that the value of the parameters should stick to the 
largest granularity of language tags, that is, it is recommended not 
to add subtags (e.g., for region or dialect) unless the languages 
might be mutually incomprehensible without them.
- Expand Introduction to be more clear about purpose of document and 
problem being solved
- Add more detailed use case descriptions

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I was gratified to be able to answer promptly, and I did.  I said
I didn't know."                                      --Mark Twain

From gunnar.hellstrom@omnitor.se  Fri Mar 15 12:05:06 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13C21F8688 for ; Fri, 15 Mar 2013 12:05:06 -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 gyE2D+qo18qI for ; Fri, 15 Mar 2013 12:05:05 -0700 (PDT)
Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id ED46C21F868E for ; Fri, 15 Mar 2013 12:05:04 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 15 Mar 2013 20:04:56 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 2833D3A160 for ; Fri, 15 Mar 2013 20:04:56 +0100 (CET)
Message-ID: <514370DA.8080704@omnitor.se>
Date: Fri, 15 Mar 2013 20:04:58 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 19:05:06 -0000

These seem to be good conclusions.

You say about directionality, for the lang-parameters in the different 
directions:
In most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.

I do not think that should be expected.

Examples:
1. Many deafblind persons prefer to sign for sending, but require text 
reception.

2. Many hard-of-hearing persons want to talk but receive text back.

3. Many persons with speech disabilities want to send text but receive 
speech


The conclusion to develop specifications for both the SIP level and the 
SDP level seems a bit complex, but can provide the desired resulting 
functionality.

Good.

/Gunnar




On 2013-03-15 19:49, Randall Gellens wrote:
> Hi everyone,
>
> Thanks very much for the productive discussion.  Here are my notes:
>
> SDP or SIP:
> - Use SDP for actual negotiation, but use SIP header to provide a hint
> - Emergency services use case can use SDP for policy routing/handling 
> decisions
> - Other use cases may or may not have ability/desire to use SDP for 
> this and can use the SIP header hint
> - SDP useful in protocols other than SIP
> - SIP header with hint is either a new header or caller preferences 
> (RFC 3841), presumably Accept-Contact; caller sets media and language 
> and optionally required; not clear if this matches our desired semantics
> - SIP header is just a hint; it is not required to be sent or to be 
> used on receipt; it is recommended to be sent
>
> New SDP attribute(s) vs re-use of existing 'lang' attribute:
> - Existing attribute semantics are unclear so should be avoided
> - Minting new attributes is cheap
>
> Directionality of SDP attributes:
> - Define two new SDP media-level attributes: 'send-lang' and 
> 'recv-lang'.  In an offer, send-lang is a list in preference order of 
> the languages the offerer wishes to send and recv-lang is a list in 
> preference order of the languages the offerer wishes to receive.  In 
> most cases these are expected to have the same value, because 
> otherwise it is harder to match desired resources.  In an answer, 
> send-lang is the accepted language the answerer will send (which in 
> most cases should be one of the languages in the offer's recv-lang) 
> and recv-lang is the accepted language the answerer expects to receive 
> (which in most cases should be one of the languages in the offer's 
> send-lang).
>
> Advisory vs Required:
> - Does call fail if no common language?
> - Define token for use in offer to indicate caller's preference to 
> fail call or not if no common language.
> - One choice is to say that if the last character of the send-lang or 
> recv-lan value an asterisk, this indicates a request to not fail the 
> call (similar to SIP Accept-Language syntax).  Either way, the called 
> party may ignore this, e.g., for the emergency services use case, a 
> PSAP will likely not fail the call.
>
> Other changes (from additional side discussions):
> - Add advice that the value of the parameters should stick to the 
> largest granularity of language tags, that is, it is recommended not 
> to add subtags (e.g., for region or dialect) unless the languages 
> might be mutually incomprehensible without them.
> - Expand Introduction to be more clear about purpose of document and 
> problem being solved
> - Add more detailed use case descriptions
>


From keith.drage@alcatel-lucent.com  Fri Mar 15 12:27:20 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1221F86CE; Fri, 15 Mar 2013 12:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cclw9dRMsOF; Fri, 15 Mar 2013 12:27:18 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A025921F86BA; Fri, 15 Mar 2013 12:27:18 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2FJRD5M023444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2013 14:27:13 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r2FJRCIS012744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 15:27:13 -0400
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 15 Mar 2013 15:27:09 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 15 Mar 2013 20:27:08 +0100
From: "DRAGE, Keith (Keith)" 
To: "avtext@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: RTP grouping taxonomy
Thread-Index: Ac4hsk+S4mfi5mU7TkGQ4dtodxjawQ==
Date: Fri, 15 Mar 2013 19:27:07 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B016A9B@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.39]
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.39
Subject: [MMUSIC] RTP grouping taxonomy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 19:27:20 -0000

(As AVTEXT cochair)

In the joint session between AVTEXT and MMUSIC today we took a call in the =
room with substantial consensus in the room that there should be a document=
 in some group in the RAI area that described the RTP grouping taxonomy.=20

The RAI ADs will decide which group this should go to and therefore which l=
ist should be used for the discussion.

This is a call to the membership of both the MMUSIC list and AVTEXT list to=
 confirm that decision. If you were in the room you do not need to reply. P=
articularly if you do have objections please reply as soon as practicable a=
t least to the appropriate chairs and the RAI ADs with your objections.

In addition, if you want to contribute to Jonathan Lennox's document=20

https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy=
/=20

directly then please do feel free to contact him for details on how to prov=
ide text. There will be at least another author version of this document be=
fore any call for adoption of the text.

Regards

Keith



From juberti@google.com  Fri Mar 15 13:01:24 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5721F8698 for ; Fri, 15 Mar 2013 13:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.974
X-Spam-Level: 
X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100,  WEIRD_PORT=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 EDqmM0FQB8u5 for ; Fri, 15 Mar 2013 13:01:23 -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 7356B21F8696 for ; Fri, 15 Mar 2013 13:01:23 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id 1so2146199qec.22 for ; Fri, 15 Mar 2013 13:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OR5w+Dap4tBWlF2HUP07Mdmh5h5L9DiWIr9Qaol9rmc=; b=RudN+CV/dLKsFZ3fg10oVFJBLodRe1vvEoi1MMvnxkliC9bGPRJm2T1Eb/tu+1a7xk B9KgSHKk+hm8dgRLx+FDe+LRxzdsYzXez3nmNWMxNzWYN9zxzO5gjx4r+BPyYBLDqu6r 49xLVIyfP/ESQacmSfkGvigxJnukpsQNmi/qCGKGu1+UmKHRxMQ5t+cgn40r/mLQoLUL 3cEL74KJV6PWsnA2cq3aiIYA6adjzBIhjMI/r8fFlrm2/FZ4hPG2z9ydnLxO/abMZhwA B5DmMjGL6NOYgmylC7r6EJPwVIweVOzJMHM6DApf66nzD5AD8ZyqerbefdWmnLQx5rcg 9xlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=OR5w+Dap4tBWlF2HUP07Mdmh5h5L9DiWIr9Qaol9rmc=; b=j0+DKdyaNLIX05UI30T4CB5EtPrfDZwi4rw8CY+rnzM0jIR4HsFLeCo2k0Wqh0oN0n P3/IVG2zSWuoRNUldWyUO6lbIy33BjXJOYspAWRjW12j1a1K36SCxKXNbQFQZzJ2r4wJ P/IVf94RGtxUAlA4LKedYnIlQ+YZtk0fNXo/v+HRaLehQar+7KeH9qxSSKpu0Dw5i5Lw TLH3SU3wXc3U8UKmQf5rSIwoOXfSXbNwGENmrsgr8fmYByU7uWG6GkFjgXUJIrW4jLtH DobTVg6U/Ku4aD9dTjhNH3fyyRwvJaxmtiFhpTRhijihDrj/ZF4mz47ZaKGYngQGs00A r2iA==
X-Received: by 10.49.15.198 with SMTP id z6mr8192932qec.6.1363377682586; Fri, 15 Mar 2013 13:01:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Fri, 15 Mar 2013 13:01:02 -0700 (PDT)
In-Reply-To: 
References:  <51422F4A.8000103@jitsi.org> 
From: Justin Uberti 
Date: Fri, 15 Mar 2013 13:01:02 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7bd6ae8077587904d7fc1a0c
X-Gm-Message-State: ALoCoQn2hNDeV4HpFG3V1h7yRTNxQ0arKJvW6PnU1HQwQFm6DrfYRbQXaZESphpvgfHb5DJ2t4/JrwY2LKF8SNlcENDBgufNSHWqgKWx86jE92VPb4g++KfufOYB/+eSQzeKIgwZxCX6SVf2vuwFeaz+xQaPi3i1yVgkh4gTPie83Jr/Vedlj+KHrHQSyxlEgfiU1Ncge9oR
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Trickle, privacy and bogus addresses
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 20:01:24 -0000

--047d7bd6ae8077587904d7fc1a0c
Content-Type: text/plain; charset=UTF-8

You may want to enforce address privacy on the outgoing offer because you
_never_ want the other side to learn your IP.

In the case where both sides want to maintain address privacy, using a null
address shortens the setup time since TURN allocation can happen in
parallel.


On Thu, Mar 14, 2013 at 1:18 PM, Martin Thomson wrote:

> On 14 March 2013 16:12, Emil Ivov  wrote:
> > On 14.03.13, 16:00, Martin Thomson wrote:
> >> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
> >>
> >> I don't believe this to be necessary and would rather we don't go there
> at all.
> >
> > When we talked about this on Tuesday, it appeared as if we had consensus
> > and the only issue was about making a choice between one of the many
> > possible options. (127..., 0.0.0.X, something else that IANA would
> > allocate for us).
> >
> > How do you get from that to "I'd rather we didn't do it at all" ?
>
> I applied some brain cycles to the problem, talked to a few people.
>
> I'll find you and walk through the proof.  It's not especially complicated.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--047d7bd6ae8077587904d7fc1a0c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You may want to enforce address privacy on the outgoing of=
fer because you _never_ want the other side to learn your IP.

In the case where both sides want to maintain address privacy, =
using a null address shortens the setup time since TURN allocation can happ=
en in parallel.





On Thu,=
 Mar 14, 2013 at 1:18 PM, Martin Thomson <martin.thomson@gmail.com<=
/a>> wrote:



On 14 March 2013 16:12, Em=
il Ivov <emcho@jitsi.org> wrot=
e:



> On 14.03.13, 16:00, Martin Thomson wrote:

>> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".

>>

>> I don't believe this to be necessary and would rather we don&#=
39;t go there at all.

>

> When we talked about this on Tuesday, it appeared as if we had consens=
us

> and the only issue was about making a choice between one of the many
> possible options. (127..., 0.0.0.X, something else that IANA would

> allocate for us).

>

> How do you get from that to "I'd rather we didn't do it a=
t all" ?




I applied some brain cycles to the problem, talked to a few people.


I'll find you and walk through the proof. =C2=A0It's not especially=
 complicated.


___________________________________=
____________

mmusic mailing list

mmusic@ietf.org

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





--047d7bd6ae8077587904d7fc1a0c--

From juberti@google.com  Fri Mar 15 13:51:39 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826DF21F86A8 for ; Fri, 15 Mar 2013 13:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level: 
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S3XwgL0OinB for ; Fri, 15 Mar 2013 13:51:34 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4243321F8667 for ; Fri, 15 Mar 2013 13:51:34 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id x7so2193332qeu.17 for ; Fri, 15 Mar 2013 13:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=/Jjr1T/FoPPcc7Bj6D6uVYJuQPta/69lZgoEn3edFIo=; b=cdr1ndzlZ+ICF3qW9G5X9jC7vEG2OdkkS68uOoCLXw4cN9dUAJZBPBE1Ss9eOKta+q Tz+t4AgKTm/2z3SHaY0REQ7ao7YS42kZLJcsWaLbNBcYua/xBkvarHoBCyNVaWl+B1i8 et0b99uISGt4Xfp7x0zJeDJqJ26K8llGfZdrugwyEtyZJa88xsf/0kNSLXvdEB17n6ip 0ptD9F3S8NrfkoipjvOD9KbVJrGr5BqMvKW1AMVIgtlx98bpL6KTJ1YqCXSaR+jUH+px 5b3WYmQ7hfbtY1z0GQ67y9gDTi21gxGnVvhQY8rvjch/X33HLLOHjucKEg4hgLoKRz6T Q2rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=/Jjr1T/FoPPcc7Bj6D6uVYJuQPta/69lZgoEn3edFIo=; b=RGDuE2FxkMhWyVRv0SjbwWSFz67Tr5gYHZwipvWPwxV0AEi4xqHfobplDehSCyOVDL kXll0/kHTU2p6DnziJyD8djxSzrwAAgPuQCPIiNTODlaNF8A2Nr6VyNN/uk6Ql9mFvrU 36MiOXqMI5tXaKnKRy60Gq8BqCTXOZc7KsQiLpj5ycUFM7CiCgm9MTCK3b5U060oEuA+ KekW+F3BzxjdTRs7HyBdvNn2mOBT/Zj0jjWMCvgzNzsQDAsHdrUPqEKvX9ZeLGIleXy5 CEXi66bvG2kzxoyrC3MK+R9Qu3FP8lCSweZthNeYj7qR1HENK7VOpjNljAQUH82zQcNq z/WA==
X-Received: by 10.224.176.70 with SMTP id bd6mr7954347qab.26.1363380687863; Fri, 15 Mar 2013 13:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Fri, 15 Mar 2013 13:51:04 -0700 (PDT)
From: Justin Uberti 
Date: Fri, 15 Mar 2013 13:51:04 -0700
Message-ID: 
To: "mmusic@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf302ef790981d5904d7fccd89
X-Gm-Message-State: ALoCoQnHTQ1sEA6pPDgiUdKyV93tQAs/YoWVZ61U+PFGlSIQsfyAOl/75ahzm08pwU5cWaaA/rLx7N5s1v4lluHPh/8FrQU17T78Gx1OiVgV2zVOEL6m447wVDgLPRk8NuE7A0UANbVvNr07T/EzGIxVnx0gUplOVZFKC7QgxBYH7BJsegB9ew8Cdk2awcxY8Sj7wDyDcWTO
Subject: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 20:51:40 -0000

--20cf302ef790981d5904d7fccd89
Content-Type: text/plain; charset=UTF-8

The list below is a set of questions (some marked as OPEN ISSUE already)
regarding the new BUNDLE proposal. If you agree with my suggested answers,
I'm willing to contribute text accordingly.

   1. Can you create a BUNDLE with a single m= line? (assuming yes)
   2. Can you create multiple BUNDLEs? (assuming yes)
   3. When creating an initial offer, how should we deal with the case
   where a "null" port is to be used with trickle ICE (since 6.1:1 indicates
   the ports MUST be different)
   4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use
   same c=, add rtcp-mux, same a=fingerprint)
   5. From 6.1, list 2 - is condition 6 right? Why would we use different
   SDES keys for a single RTP session?
   6. If you start with a m= line with one SDES config (e.g. 32-bit MAC),
   and then BUNDLE with another SDES line with a different (non overlapping)
   SDES config (e.g. 80-bit MAC), what happens? (assume fail)
   7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
   offer, what happens? (assume fail)
   8. If you add a m= line to an existing BUNDLE, can the recipient reject
   that BUNDLEing (assume no)
   9. If m= lines are rejected, should their mids show up in the BUNDLE
   answer? (assume yes?)
      1. If not, how does remote side indicate BUNDLE support if it rejects
      the m= lines that are BUNDLEd?
   10. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
   that were previously BUNDLEd (assume no)

--20cf302ef790981d5904d7fccd89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The list below is a set of questions (some marked as OPEN =
ISSUE already) regarding the new BUNDLE proposal. If you agree with my sugg=
ested answers, I'm willing to contribute text accordingly.
    


  1. Can you create a BUNDLE with a single m=3D line? (assuming yes)
    2. Can you create multiple BUNDLEs? (assuming yes)
  2. When creatin=
g an initial offer, how should we deal with the case where a "null&quo=
t; port is to be used with trickle ICE (since 6.1:1 indicates the ports MUS=
T be different)=C2=A0
    3. 


  3. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST=
 use same c=3D, add rtcp-mux, same a=3Dfingerprint)
  4. From 6.1,=
 list 2 - is condition 6 right? Why would we use different SDES keys for a =
single RTP session?
    5. 


  5. If you start with a m=3D line with one SDES config (e.g. 32-bit M=
AC), and then BUNDLE with another SDES line with a different (non overlappi=
ng) SDES config (e.g. 80-bit MAC), what happens? (assume fail)
  6. 

If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the o=
ffer, what happens? (assume fail)
  7. If you add a m=3D line to a=
n existing BUNDLE, can the recipient reject that BUNDLEing (assume no)
    8. 


  8. If m=3D lines are rejected, should their mids show up in the BUND=
LE answer? (assume yes?)
    1. If not, how does remote si=
de indicate BUNDLE support if it rejects the m=3D lines that are BUNDLEd?


  9. Is there any way, in a single PeerConnection, to unBUNDLE m=
=3D lines that were previously BUNDLEd (assume no)


--20cf302ef790981d5904d7fccd89--

From worley@shell01.TheWorld.com  Fri Mar 15 14:32:06 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF91F0CE0 for ; Fri, 15 Mar 2013 14:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.38
X-Spam-Level: 
X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=-0.600,  BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 EVnOs1moRQyJ for ; Fri, 15 Mar 2013 14:32:06 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id AFBB91F0C52 for ; Fri, 15 Mar 2013 14:32:05 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2FLUAcp030035 for ; Fri, 15 Mar 2013 17:30:15 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2FLU9X8512208 for ; Fri, 15 Mar 2013 16:30:09 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2FLU9HW511660; Fri, 15 Mar 2013 17:30:09 -0400 (EDT)
Date: Fri, 15 Mar 2013 17:30:09 -0400 (EDT)
Message-Id: <201303152130.r2FLU9HW511660@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
Subject: [MMUSIC] Revised bundling proposal (draft-worley-sdp-bundle-06)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 21:32:07 -0000

I've submitted a revised bundling proposal
(http://tools.ietf.org/html/draft-worley-sdp-bundle-06).  The major
changes are that it no longer uses encapsulation (Martin Thompson and
Dan Wing explained to me why that is undesirable) and it uses a
special attribute ("a=bundleaccept") along with a zero port number to
indicate that a constituent media description has been accepted within
a bundle.  The powerpoint version is:

Major characteristics:

* SDP m= lines are grouped using a new SDP grouping value.

* There is a separate bundle media description, which uses media type
  "audio" (to avoid tripping legacy SBCs) and proto "bundle" (to
  prevent non-supporting answerers from accepting that media
  description).

* Each constituent media description is offered with a distinct port.

* If the answerer accepts a constituent media description within the
  bundle, it answers with a zero port, but marks the media
  description with "a=bundleaccept".  The media description is still
  listed in the "a=group:BUNDLE" line, which is an extension of RFC
  5888.

* If the offerer did not preallocate TURN relays for constituent media
  descriptions, and the answerer does not support bundling, and TURN
  relays are required on the offerer's side, then the offerer will
  have to update its offer to establish communication.

Advantages:

* Avoids all known limitations of common SBCs.  Only requires SBCs to
  pass unknown proto values.

* Legacy intermediary entities see media which matches the SDP.

* Interoperates directly with non-supporting answerers.

* Requires updated offer only if offerer has not preallocated TURN
  relays for the constituent media descriptions and they turn out to
  be necessary.

* No artificial addresses (e.g., 0.0.0.0) are used, so it places no
  constraints on future uses of artificial addresses (e.g., trickle
  ICE).

A typical offer (with a usual pattern of ICE candidates):

           o=- 2890844526 2890844526 IN IP4 host.example.com
           c=IN IP4 host.example.com

           a=group:BUNDLE bundle con1 con2

           m=audio 10000 RTP/AVP 0 8 97
           a=mid:con1
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx

           m=video 10002 RTP/AVP 31 32
           a=mid:con2
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx

           m=audio 10004 bundle 0
           a=mid:bundle
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51004 typ srflx
           a=candidate:2 1 UDP 1006633215 10.0.100.1 31004 typ relay

A typical answer from an endpoint that supports bundling:

           o=- 2890844526 2890844526 IN IP4 answer.example.com
           c=IN IP4 answer.example.com

           a=group:BUNDLE bundle con1 con2

           m=audio 0 RTP/AVP 0 8 97
           a=mid:con1
           a=bundleaccept
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000

           m=video 0 RTP/AVP 31 32
           a=mid:con2
           a=bundleaccept
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000

           m=audio 20000 bundle 0
           a=mid:bundle
           a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx
           a=candidate:2 1 UDP 1006633215 10.0.100.1 32000 typ relay

Dale

From randy@qti.qualcomm.com  Fri Mar 15 15:16:07 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5EA21F86AE for ; Fri, 15 Mar 2013 15:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.459
X-Spam-Level: 
X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 U4Ib67iz+xdB for ; Fri, 15 Mar 2013 15:16:07 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0203321F861B for ; Fri, 15 Mar 2013 15:16:06 -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=1363385766; x=1394921766; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=xcYfsrzCE/4wWlW/YTdkyKGpUgaS0eS0GrFGRGaEmuM=; b=IWBM2bE5K/LuM0AEh6kuhEn49TCYm57l4gI5rf28LQODkuhZ8Qhf/2F8 04hDNv5zephNys0JnU92Y6V6+7qyoqh0YBwgYTDRVKSNkrx+322M8PDwI NsAWbAHlF4TaIJhW3wvLXcqb/egOPX73VMEm8agRXwU0YU+Mwtdjdq3hv U=;
X-IronPort-AV: E=Sophos;i="4.84,854,1355126400"; d="scan'208";a="30235104"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 15 Mar 2013 15:16:06 -0700
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Mar 2013 15:16:06 -0700
Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 15:15:27 -0700
Message-ID: 
In-Reply-To: <514370DA.8080704@omnitor.se>
References:  <514370DA.8080704@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 15 Mar 2013 15:14:04 -0700
To: Gunnar Hellstrom , 
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.39.5]
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Mar 2013 22:16:08 -0000

At 8:04 PM +0100 3/15/13, Gunnar Hellstrom wrote:

>  Examples:
>  1. Many deafblind persons prefer to sign for sending, but require 
> text reception.
>
>  2. Many hard-of-hearing persons want to talk but receive text back.
>
>  3. Many persons with speech disabilities want to send text but receive speech

Yes, but that does not mean that the media streams need to be 
explicitly negotiated such.  E.g., just because someone intends to 
primarily use a text stream for sending does not mean it must be 
prohibited to receive text back.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.                                           --Mark Twain

From gunnar.hellstrom@omnitor.se  Sat Mar 16 00:23:17 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102621F8CF4 for ; Sat, 16 Mar 2013 00:23:17 -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_18=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 uqENuXVgb2qf for ; Sat, 16 Mar 2013 00:23:16 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 0C5D221F8CF0 for ; Sat, 16 Mar 2013 00:23:14 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sat, 16 Mar 2013 08:23:04 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 998933A149; Sat, 16 Mar 2013 08:23:04 +0100 (CET)
Message-ID: <51441DD6.5040706@omnitor.se>
Date: Sat, 16 Mar 2013 08:23:02 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Randall Gellens 
References:  <514370DA.8080704@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 07:23:17 -0000

On 2013-03-15 23:14, Randall Gellens wrote:
> At 8:04 PM +0100 3/15/13, Gunnar Hellstrom wrote:
>
>>  Examples:
>>  1. Many deafblind persons prefer to sign for sending, but require 
>> text reception.
>>
>>  2. Many hard-of-hearing persons want to talk but receive text back.
>>
>>  3. Many persons with speech disabilities want to send text but 
>> receive speech
>
> Yes, but that does not mean that the media streams need to be 
> explicitly negotiated such.  E.g., just because someone intends to 
> primarily use a text stream for sending does not mean it must be 
> prohibited to receive text back.
Yes, very true.
Other media and media directions than the ones you declare preference 
for are usually also appreciated, and sometimes important.
You said some time ago that a medium-direction with no language 
indication just means that there is no preferred language use of it, but 
it may very well be desired in the call and should be connected if 
supported. That was why the a=sendonly and a=recvonly attributes cannot 
be used for preference indications.

Let us take the deaf-blind example.

A deaf-blind person may prefer to sign, and prefer to receive text, and 
be able to send text.
But in contact with another deaf-blind person with same preferences and 
capabilities, there are then two choices:
1. Connect the call directly and type both ways.
or
2. Connect a relay service that handles sign-to-text translation both ways.

I would assume that most users for this case would select the direct 
connection, but that is a matter of preference and situation.

This can create a need for level of preference indication between two 
different media, and not just by position of a language within one medium.
I mean for the example above: prefer sign out, but manage text out.

/Gunnar

From btv1==78736fa84fe==HKaplan@acmepacket.com  Sat Mar 16 12:54:50 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9531921F888B for ; Sat, 16 Mar 2013 12:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level: 
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157,  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 D0x4nM+2U7dc for ; Sat, 16 Mar 2013 12:54:47 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9273521F8788 for ; Sat, 16 Mar 2013 12:54:47 -0700 (PDT)
X-ASG-Debug-ID: 1363463686-03fc2172601023790001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id fcTS2B8ngK3igch9 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 15:54:46 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sat, 16 Mar 2013 15:54:46 -0400
From: Hadriel Kaplan 
To: Randall Gellens 
Thread-Topic: [MMUSIC] Notes from Orlando human language draft discussion
X-ASG-Orig-Subj: Re: [MMUSIC] Notes from Orlando human language draft discussion
Thread-Index: AQHOIoAbfdhuHviRWEioUUIhgvdWNQ==
Date: Sat, 16 Mar 2013 19:54:44 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1B28935EFCE0CD48A06CB7264CA434C8@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363463686
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125382 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" , "" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 19:55:08 -0000

On Mar 15, 2013, at 2:49 PM, Randall Gellens  wrote=
:

> SDP or SIP:
> - Use SDP for actual negotiation, but use SIP header to provide a hint
> - Emergency services use case can use SDP for policy routing/handling dec=
isions
> - Other use cases may or may not have ability/desire to use SDP for this =
and can use the SIP header hint

Another reason not to only put it in SDP is the delayed-offer scenario.


> Directionality of SDP attributes:
> - Define two new SDP media-level attributes: 'send-lang' and 'recv-lang'.=
  In an offer, send-lang is a list in preference order of the languages the=
 offerer wishes to send and recv-lang is a list in preference order of the =
languages the offerer wishes to receive.  In most cases these are expected =
to have the same value, because otherwise it is harder to match desired res=
ources.  In an answer, send-lang is the accepted language the answerer will=
 send (which in most cases should be one of the languages in the offer's re=
cv-lang) and recv-lang is the accepted language the answerer expects to rec=
eive (which in most cases should be one of the languages in the offer's sen=
d-lang).

What's the use-case when the two directions are not identical?  I.e., when =
does it make sense to receive Latin but send Swahili for the same media?
I ask because this separation complicates things quite a bit in code/testin=
g/error-handling, obviously.


> Advisory vs Required:
> - Does call fail if no common language?

I haven't thought about this draft's scenarios much, but think we need to t=
hink about this very carefully.  Otherwise the outcome would be SBCs would =
strip it from the INVITE, just to avoid failing the call.  I don't think an=
yone would actually want such calls to truly fail for the end user - not ju=
st for Emergency calls, but for any calls - people can always hang up if th=
ey don't like what they hear/see.  ISTM that there's a high likelihood of t=
his language value actually being *wrong* in either the sender or receiver =
or both, so I think failing the call because of a mismatch would be really =
bad.

At first glance, I can see one and only one reason failing it would make se=
nse: for a serial-forking proxy/B2BUA/UA to be able to recurse to alternate=
 targets if the first one didn't support the language(s).  But it has a ver=
y negative drawback: if there are no more targets it can recurse to, or if =
there were no such forking to begin with, the call fails.  Then we're back =
to square one above, and the thing gets removed from all calls by middlebox=
es, just to avoid such cases.

-hadriel
p.s. was this presented in MMUSIC this past week?  For some reason this top=
ic was neither on the MMUSIC agenda pages (http://www.ietf.org/proceedings/=
86/agenda/agenda-86-mmusic), nor in the meeting materials (https://datatrac=
ker.ietf.org/meeting/86/materials.html), nor is the draft on the MMUSIC too=
ls page (http://tools.ietf.org/wg/mmusic/).  I only mention this because I =
was looking for the slides and draft today and didn't find them.


From gunnar.hellstrom@omnitor.se  Sat Mar 16 14:32:31 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9721F874A for ; Sat, 16 Mar 2013 14:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 TPMDhx9ew-II for ; Sat, 16 Mar 2013 14:32:30 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 5173321F872E for ; Sat, 16 Mar 2013 14:32:29 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 16 Mar 2013 22:32:21 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id EB80A3A166 for ; Sat, 16 Mar 2013 22:32:21 +0100 (CET)
Message-ID: <5144E4E5.4030801@omnitor.se>
Date: Sat, 16 Mar 2013 22:32:21 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 21:32:31 -0000

On 2013-03-16 20:54, Hadriel Kaplan wrote:
> What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
Examples are:

1. Deaf-blind person who want to use sign language in video out, but 
cannot see it in reception and therefore declare language in video only 
for send video.
( also declaring preference for reading text and acceptance for typing 
text )

2. Hard-of-hearing person who want to talk in audio channel, but cannot 
hear answers , and therefore declare languge for audio only in send audio
( also declaring preference for reading text and acceptance for typing 
text )

3. Person with speech disabilities who want to hear in audio channel, 
but cannot use audio for talking
( also declaring preference for typing text and acceptance for reading 
text )

By the way, here we have a tricky case:
4. Person with speech disabilities who want to hear in audio channel, 
and talks unclearly, so that he want a speech relay service to listen to 
the call and clarify what got hard to understand for the other party.
Maybe that service needs to be requested with an explicit service 
request instead of language and modality matching?

  /Gunnar

From randy@qti.qualcomm.com  Sat Mar 16 14:55:18 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6528821F867B for ; Sat, 16 Mar 2013 14:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XMxdiEY+xqe for ; Sat, 16 Mar 2013 14:55:17 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05A21F867A for ; Sat, 16 Mar 2013 14:55:16 -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=1363470916; x=1395006916; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=+qDZf2m0Zc/bS0uythbbBuHeBWs+Vjfg3houmE9tdx8=; b=K/INVjN4YDujxz8TX2QJpf/fH4lrix6uLca9UMs48QgDF/M9gqv3uCbj /lmzE0TfR1L+5mxEzKjcaaLjyUhS82l0MVaTMsBCw1PsQHBasUPMCx0XY 6yFqhLySsGxaw+gRkFLlIYh7PxY4GIToyaPh0xyCic9DZydnHr2Zz776Q M=;
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="30336300"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 16 Mar 2013 14:55:16 -0700
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="506283920"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Mar 2013 14:55:16 -0700
Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 16 Mar 2013 14:55:15 -0700
Message-ID: 
In-Reply-To: 
References:  
X-Mailer: Eudora for Mac OS X
Date: Sat, 16 Mar 2013 14:54:46 -0700
To: Hadriel Kaplan 
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.39.5]
Cc: Randall Gellens , "" , "" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 21:55:18 -0000

At 7:54 PM +0000 3/16/13, Hadriel Kaplan wrote:

>  On Mar 15, 2013, at 2:49 PM, Randall Gellens  wrote:
>
>>  SDP or SIP:
>>  - Use SDP for actual negotiation, but use SIP header to provide a hint
>>  - Emergency services use case can use SDP for policy 
>> routing/handling decisions
>>  - Other use cases may or may not have ability/desire to use SDP 
>> for this and can use the SIP header hint
>
>  Another reason not to only put it in SDP is the delayed-offer scenario.
>
>
>>  Directionality of SDP attributes:
>>  - Define two new SDP media-level attributes: 'send-lang' and 
>> 'recv-lang'.  In an offer, send-lang is a list in preference order 
>> of the languages the offerer wishes to send and recv-lang is a 
>> list in preference order of the languages the offerer wishes to 
>> receive.  In most cases these are expected to have the same value, 
>> because otherwise it is harder to match desired resources.  In an 
>> answer, send-lang is the accepted language the answerer will send 
>> (which in most cases should be one of the languages in the offer's 
>> recv-lang) and recv-lang is the accepted language the answerer 
>> expects to receive (which in most cases should be one of the 
>> languages in the offer's send-lang).
>
>  What's the use-case when the two directions are not identical? 
> I.e., when does it make sense to receive Latin but send Swahili for 
> the same media?
>  I ask because this separation complicates things quite a bit in 
> code/testing/error-handling, obviously.

I'll let Harald speak to this as he was pretty insistent that it was 
a misuse of SDP (if I understood him) to use the same attribute for 
sending and receiving.

>   > Advisory vs Required:
>>  - Does call fail if no common language?
>
>  I haven't thought about this draft's scenarios much, but think we 
> need to think about this very carefully.  Otherwise the outcome 
> would be SBCs would strip it from the INVITE, just to avoid failing 
> the call.  I don't think anyone would actually want such calls to 
> truly fail for the end user - not just for Emergency calls, but for 
> any calls - people can always hang up if they don't like what they 
> hear/see.  ISTM that there's a high likelihood of this language 
> value actually being *wrong* in either the sender or receiver or 
> both, so I think failing the call because of a mismatch would be 
> really bad.
>
>  At first glance, I can see one and only one reason failing it would 
> make sense: for a serial-forking proxy/B2BUA/UA to be able to 
> recurse to alternate targets if the first one didn't support the 
> language(s).  But it has a very negative drawback: if there are no 
> more targets it can recurse to, or if there were no such forking to 
> begin with, the call fails.  Then we're back to square one above, 
> and the thing gets removed from all calls by middleboxes, just to 
> avoid such cases.

The result of the discussion is to add a token for the caller to 
indicate a preference for the language being mandatory or advisory, 
but the callee is not required to honor this preference.  I can 
imagine scenarios where failing the call might be preferred, such as 
a caller who will call an alternate party if the required language 
isn't supported.

>
>  -hadriel
>  p.s. was this presented in MMUSIC this past week?  For some reason 
> this topic was neither on the MMUSIC agenda pages 
> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor 
> in the meeting materials 
> (https://datatracker.ietf.org/meeting/86/materials.html), nor is 
> the draft on the MMUSIC tools page 
> (http://tools.ietf.org/wg/mmusic/).  I only mention this because I 
> was looking for the slides and draft today and didn't find them.

No, this is my fault.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter

From btv1==788266430c8==HKaplan@acmepacket.com  Sat Mar 16 17:21:42 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3C21F8628 for ; Sat, 16 Mar 2013 17:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG1q3fltIUtd for ; Sat, 16 Mar 2013 17:21:42 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2D21F8626 for ; Sat, 16 Mar 2013 17:21:41 -0700 (PDT)
X-ASG-Debug-ID: 1363479699-03fc200f266aacb0001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id tShaEAGBDuUr5F2U (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 20:21:39 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sat, 16 Mar 2013 20:21:39 -0400
From: Hadriel Kaplan 
To: Gunnar Hellstrom 
Thread-Topic: [MMUSIC] Notes from Orlando human language draft discussion
X-ASG-Orig-Subj: Re: [MMUSIC] Notes from Orlando human language draft discussion
Thread-Index: AQHOIqVjrWQrOw9cbEynnCutbiMHMw==
Date: Sun, 17 Mar 2013 00:21:37 +0000
Message-ID: <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com>
References:   <5144E4E5.4030801@omnitor.se>
In-Reply-To: <5144E4E5.4030801@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363479699
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125400 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 01:03:31 -0000

Preface note: I am not against the needs of hearing-impaired or visually-im=
paired people - I'm asking the questions because I think the simpler the me=
chanism is, the more likely it will be to actually work and be deployed, an=
d thus not hinder such cases.

I may be very very wrong, and I'd certainly defer to those who know for sur=
e, but I would think they'd want the call to succeed for the media types th=
ey need to use, rather than only succeed if the specific directionality tra=
its of those media lines are supported by the other side.

For the below comments, I'll use 'sign-language' as a token, although I ass=
ume there must actually be many tokens since there are many sign languages.

Other comments inline...


On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom =
 wrote:

> On 2013-03-16 20:54, Hadriel Kaplan wrote:
>> What's the use-case when the two directions are not identical?  I.e., wh=
en does it make sense to receive Latin but send Swahili for the same media?
>> I ask because this separation complicates things quite a bit in code/tes=
ting/error-handling, obviously.
> Examples are:
>=20
> 1. Deaf-blind person who want to use sign language in video out, but cann=
ot see it in reception and therefore declare language in video only for sen=
d video.
> ( also declaring preference for reading text and acceptance for typing te=
xt )

So just indicate 'sign-language' for video media, and have a text media lin=
e.
It will be very clear to the far-end when they see the caller is blind that=
 they can only see sign language but not send it.  Or if you want to make i=
t one-way video on the wire, that's what the 'a=3Dsendonly' is for. (same g=
oes for text media line)

The important thing is that you need to reach someone who can understand yo=
ur sign language.


> 2. Hard-of-hearing person who want to talk in audio channel, but cannot h=
ear answers , and therefore declare languge for audio only in send audio
> ( also declaring preference for reading text and acceptance for typing te=
xt )

If you literally only want to send audio but not receive, use 'a=3Dsendonly=
' for the audio line, and have a text media line.  If, however, you mean th=
ey want bi-directional audio but a preference to reach someone who can also=
 do text, or video for sign-language, send normal audio and text media line=
s, or with a 'sign-language' video line.

The important thing is that you reach someone who can hear you, and can typ=
e text back to you (or do sign language).


> 3. Person with speech disabilities who want to hear in audio channel, but=
 cannot use audio for talking
> ( also declaring preference for typing text and acceptance for reading te=
xt )

Same as above, but with 'a=3Drecvonly' if you literally want one-way on the=
 wire.
The important thing is you reach someone who can talk to you, but also can =
read text from you or see your sign language.


> By the way, here we have a tricky case:
> 4. Person with speech disabilities who want to hear in audio channel, and=
 talks unclearly, so that he want a speech relay service to listen to the c=
all and clarify what got hard to understand for the other party.
> Maybe that service needs to be requested with an explicit service request=
 instead of language and modality matching?

I have not looked into how such relay services work, for example VRS.  It w=
ould be good to know how they're used in practice. (I can imagine several w=
ays they could be done)

-hadriel


From btv1==788266430c8==HKaplan@acmepacket.com  Sat Mar 16 18:03:21 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4579421F8517 for ; Sat, 16 Mar 2013 18:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  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 w9KIVS1Ecxwy for ; Sat, 16 Mar 2013 18:03:20 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9095321F84E7 for ; Sat, 16 Mar 2013 18:03:20 -0700 (PDT)
X-ASG-Debug-ID: 1363482193-03fc21725f1032860001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id jSSjc0Tlf843wt4l (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 21:03:13 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sat, 16 Mar 2013 21:03:13 -0400
From: Hadriel Kaplan 
To: Randall Gellens 
Thread-Topic: [MMUSIC] Notes from Orlando human language draft discussion
X-ASG-Orig-Subj: Re: [MMUSIC] Notes from Orlando human language draft discussion
Thread-Index: AQHOIqsyYKFxkcc+jkilErBlQ5pP/A==
Date: Sun, 17 Mar 2013 01:03:13 +0000
Message-ID: <4CB74555-CA6A-4FE8-B410-AAD1EF2354A6@acmepacket.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363482193
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125404 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "ietf-languages-bounces@alvestrand.no" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 01:03:40 -0000

On Mar 16, 2013, at 5:54 PM, Randall Gellens  wrote=
:

>> What's the use-case when the two directions are not identical? I.e., whe=
n does it make sense to receive Latin but send Swahili for the same media?
>> I ask because this separation complicates things quite a bit in code/tes=
ting/error-handling, obviously.
>=20
> I'll let Harald speak to this as he was pretty insistent that it was a mi=
suse of SDP (if I understood him) to use the same attribute for sending and=
 receiving.

That may be true for attributes specific to a format/payload type... maybe.=
  But for just attributes applying to a media or session section, I don't t=
hink so.  You can look up the registered SDP attributes in IANA and find a =
bunch that really apply to both directions, at least in practice.  For exam=
ple: the 'a=3Dinactive' attribute.  It's not inactive for a specific direct=
ion, it's inactive for both directions.


> The result of the discussion is to add a token for the caller to indicate=
 a preference for the language being mandatory or advisory, but the callee =
is not required to honor this preference. =20

If the callee is not required to honor a mandatory preference, then it's no=
t really mandatory is it?
Is there a third token for "I really mean it"? ;)


> I can imagine scenarios where failing the call might be preferred, such a=
s a caller who will call an alternate party if the required language isn't =
supported.

I can imagine scenarios where the caller will call an alternate party as we=
ll, but that's what we let them do by letting them hang-up/end the session.
And I'm not saying that to be flippant.  I'm really worried calls will fail=
 when the user didn't want them to, and that would be bad.  Bad because I d=
on't want them having to read a manual to make a call work, or having them =
contact their provider's tech support to figure out why their call failed.

-hadriel


From gunnar.hellstrom@omnitor.se  Sun Mar 17 00:37:42 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC321F86C5 for ; Sun, 17 Mar 2013 00:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_18=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 0xbN3a5-1QOm for ; Sun, 17 Mar 2013 00:37:41 -0700 (PDT)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C60F121F8548 for ; Sun, 17 Mar 2013 00:37:40 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Sun, 17 Mar 2013 08:36:59 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id BA8E63A00B; Sun, 17 Mar 2013 08:36:59 +0100 (CET)
Message-ID: <5145729C.6030905@omnitor.se>
Date: Sun, 17 Mar 2013 08:37:00 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References:   <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com>
In-Reply-To: <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 07:37:42 -0000

On 2013-03-17 01:21, Hadriel Kaplan wrote:
> Preface note: I am not against the needs of hearing-impaired or visually-impaired people - I'm asking the questions because I think the simpler the mechanism is, the more likely it will be to actually work and be deployed, and thus not hinder such cases.
>
> I may be very very wrong, and I'd certainly defer to those who know for sure, but I would think they'd want the call to succeed for the media types they need to use, rather than only succeed if the specific directionality traits of those media lines are supported by the other side.
Yes, we said so yesterday:
Other media and media directions than the ones you declare preference 
for are usually also appreciated, and sometimes important.
You said some time ago that a medium-direction with no language 
indication just means that there is no preferred language use of it, but 
it may very well be desired in the call and should be connected if 
supported. That was why the a=sendonly and a=recvonly attributes cannot 
be used for preference indications.
>
> For the below comments, I'll use 'sign-language' as a token, although I assume there must actually be many tokens since there are many sign languages.
>
> Other comments inline...
>
>
> On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom  wrote:
>
>> On 2013-03-16 20:54, Hadriel Kaplan wrote:
>>> What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
>>> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
The need came from the relay service examples.
But let us try to fancy a need from the spoken language side:
A high level conference is held with English as main language but 
possibility to get interpreting to and from other languages.

A delegate from Kenya feel well confident in listening directly in 
English, not risking delays and dropouts through interpreters, but feel 
much more confident in expressing herself in Swahili when she speaks. 
Therefore she selects that combination and the remote conference is set 
up so that she get the Swahili interpretation when she talks.
>> Examples are:
>>
>> 1. Deaf-blind person who want to use sign language in video out, but cannot see it in reception and therefore declare language in video only for send video.
>> ( also declaring preference for reading text and acceptance for typing text )
> So just indicate 'sign-language' for video media, and have a text media line.
> It will be very clear to the far-end when they see the caller is blind that they can only see sign language but not send it.  Or if you want to make it one-way video on the wire, that's what the 'a=sendonly' is for. (same goes for text media line)
>
> The important thing is that you need to reach someone who can understand your sign language.
No, the important thing is to have a chance to rapidly evaluate either 
how to route the call to someone who match the preferences, or to add 
services doing translations so that the preferences are fulfilled.

It is not good to let the deaf-blind user be connected with a person who 
has only video enabled.
>
>
>> 2. Hard-of-hearing person who want to talk in audio channel, but cannot hear answers , and therefore declare languge for audio only in send audio
>> ( also declaring preference for reading text and acceptance for typing text )
> If you literally only want to send audio but not receive, use 'a=sendonly' for the audio line, and have a text media line.
We said yesterday that that is not the case, we are not discussing 
sendonly etc.  It is use of the media we are discussing.  Support of the 
media is another thing, already well covered in both SDP and SIP.
>   If, however, you mean they want bi-directional audio but a preference to reach someone who can also do text, or video for sign-language, send normal audio and text media lines, or with a 'sign-language' video line.
>
> The important thing is that you reach someone who can hear you, and can type text back to you (or do sign language).
>
>
>> 3. Person with speech disabilities who want to hear in audio channel, but cannot use audio for talking
>> ( also declaring preference for typing text and acceptance for reading text )
> Same as above, but with 'a=recvonly' if you literally want one-way on the wire.
> The important thing is you reach someone who can talk to you, but also can read text from you or see your sign language.
>
>
>> By the way, here we have a tricky case:
>> 4. Person with speech disabilities who want to hear in audio channel, and talks unclearly, so that he want a speech relay service to listen to the call and clarify what got hard to understand for the other party.
>> Maybe that service needs to be requested with an explicit service request instead of language and modality matching?
> I have not looked into how such relay services work, for example VRS.  It would be good to know how they're used in practice. (I can imagine several ways they could be done)
Read
http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf

>
> -hadriel
>
/Gunnar

From harald@alvestrand.no  Sun Mar 17 01:01:55 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763E021F877B for ; Sun, 17 Mar 2013 01:01:55 -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 j0aIh2Kx4yTW for ; Sun, 17 Mar 2013 01:01:54 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59521F877A for ; Sun, 17 Mar 2013 01:01:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C4FC39E1BB for ; Sun, 17 Mar 2013 09:01:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft4C6sphvk7j for ; Sun, 17 Mar 2013 09:01:52 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:8470:250e:fe3c:a2a6] (unknown [IPv6:2001:470:de0a:27:8470:250e:fe3c:a2a6]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D9E3B39E029 for ; Sun, 17 Mar 2013 09:01:51 +0100 (CET)
Message-ID: <5145786F.8060507@alvestrand.no>
Date: Sun, 17 Mar 2013 09:01:51 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: mmusic@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020706010509070101060305"
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 08:01:55 -0000

This is a multi-part message in MIME format.
--------------020706010509070101060305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/15/2013 09:51 PM, Justin Uberti wrote:
> The list below is a set of questions (some marked as OPEN ISSUE 
> already) regarding the new BUNDLE proposal. If you agree with my 
> suggested answers, I'm willing to contribute text accordingly.
>
>  1. Can you create a BUNDLE with a single m= line? (assuming yes)
>  2. Can you create multiple BUNDLEs? (assuming yes)
>  3. When creating an initial offer, how should we deal with the case
>     where a "null" port is to be used with trickle ICE (since 6.1:1
>     indicates the ports MUST be different)
>
Tangential, sort of - when creating an initial offer, when would one 
need to use a null port?
We're creating the offer, if we don't want the m-line, we can omit it 
altogether.
(This was one of the things that simplified the problem when Christer, 
Cullen and I were discussing this version).

>  1. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>     use same c=, add rtcp-mux, same a=fingerprint)
>  2. From 6.1, list 2 - is condition 6 right? Why would we use
>     different SDES keys for a single RTP session?
>
Having the same SDES keys for two RTP sessions runs the risk of a 
two-time pad attack, I think (needs some other things to be the same 
too, but I don't think there's a guard against that anywhere). So this 
is a fatal flaw if the negotiation results in non-BUNDLE.

The lists could be better formatted - only 1, 3 and 4 are different 
between the lists, I think it's good to keep the differences between 
"before BUNDLE" and "after BUNDLE" minimal, but one should call out the 
differences.

>  1. If you start with a m= line with one SDES config (e.g. 32-bit
>     MAC), and then BUNDLE with another SDES line with a different (non
>     overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume
>     fail)
>
I assume so too. This should be noted.
>
>  1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>     the offer, what happens? (assume fail)
>
I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>
>  1. If you add a m= line to an existing BUNDLE, can the recipient
>     reject that BUNDLEing (assume no)
>  2. If m= lines are rejected, should their mids show up in the BUNDLE
>     answer? (assume yes?)
>      1. If not, how does remote side indicate BUNDLE support if it
>         rejects the m= lines that are BUNDLEd?
>  3. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>     that were previously BUNDLEd (assume no)
>

Syntactically, it's easy (omit the mid from the a=group:bundle line); 
semantically, I think it hurts my mind to think about what should happen 
in the RTP session(s) and when, so let's just outlaw it.

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


--------------020706010509070101060305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/15/2013 09:51 PM, Justin Uberti
      wrote:

    

    

      
The list below is a set of questions (some marked
        as OPEN ISSUE already) regarding the new BUNDLE proposal. If you
        agree with my suggested answers, I'm willing to contribute text
        accordingly.
        

          
    
            
  1. Can you create a BUNDLE with a single m= line? (assuming
              yes)
    2. 
            
  2. Can you create multiple BUNDLEs? (assuming yes)
    3. 
            
  3. When creating an initial offer, how should we
              deal with the case where a "null" port is to be used with
              trickle ICE (since 6.1:1 indicates the ports MUST be
              different) 
    
            
    4. 
          

        

      

    

    Tangential, sort of - when creating an initial offer, when would one
    need to use a null port?

    We're creating the offer, if we don't want the m-line, we can omit
    it altogether.

    (This was one of the things that simplified the problem when
    Christer, Cullen and I were discussing this version).

    

    

      

        

          
    
            
  1. From 6.1, list 1 - are conditions 2, 5, 7
              really necessary? (MUST use same c=, add rtcp-mux, same
              a=fingerprint)
    2. 
            
  2. From 6.1, list 2 - is condition 6 right? Why
              would we use different SDES keys for a single RTP session?
    3. 
          

        

      

    

    Having the same SDES keys for two RTP sessions runs the risk of a
    two-time pad attack, I think (needs some other things to be the same
    too, but I don't think there's a guard against that anywhere). So
    this is a fatal flaw if the negotiation results in non-BUNDLE.

    

    The lists could be better formatted - only 1, 3 and 4 are different
    between the lists, I think it's good to keep the differences between
    "before BUNDLE" and "after BUNDLE" minimal, but one should call out
    the differences.

    

    

      

        

          
    
            
  1. If you start with a m= line with one SDES
              config (e.g. 32-bit MAC), and then BUNDLE with another
              SDES line with a different (non overlapping) SDES config
              (e.g. 80-bit MAC), what happens? (assume fail)
    2. 
          

        

      

    

    I assume so too. This should be noted.

    

      

        

          
    
            
  1. 
              If the BUNDLE mids in the answer doesn't match the BUNDLE
              mids in the offer, what happens? (assume fail)
    2. 
          

        

      

    

    I think this violates RFC 5888 section 9.1, so it should be a FAIL.

    

      

        

          
    
            
  1. If you add a m= line to an existing BUNDLE, can
              the recipient reject that BUNDLEing (assume no)
    2. 
            
  2. If m= lines are rejected, should their mids
              show up in the BUNDLE answer? (assume yes?)
    3. 
            
      
              
    1. If not, how does remote side indicate BUNDLE
                support if it rejects the m= lines that are BUNDLEd?
      2. 
            
    
            
  3. Is there any way, in a single PeerConnection,
              to unBUNDLE m= lines that were previously BUNDLEd (assume
              no)
    4. 
          

        

      

    

    

    Syntactically, it's easy (omit the mid from the a=group:bundle
    line); semantically, I think it hurts my mind to think about what
    should happen in the RTP session(s) and when, so let's just outlaw
    it.

    

    

      

      

      

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


    

    

  


--------------020706010509070101060305--

From randy@qti.qualcomm.com  Sun Mar 17 12:43:34 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC421F8B74 for ; Sun, 17 Mar 2013 12:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.374
X-Spam-Level: 
X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 6N2PIGbwX3sQ for ; Sun, 17 Mar 2013 12:43:32 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16321F8AA0 for ; Sun, 17 Mar 2013 12:43:32 -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=1363549412; x=1395085412; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=mYnNlDOWxw0ldCnuibzZV0tkj6lp2cNygXYTYThyx2E=; b=ABK+tI29QBCgVP7lKBKt8uNJvGjhD5n/WkSFIH0d8eBAcfntnjEYMBbC Y2ie9PCrQY3YDubyBX4MHCzLMTQe4vJooaFoF3BJV8NspKSQ8rMqa1n38 9QogQZfsN6SO0TOOMIzrkD1fe4IoTU138apOHIVRvt93faKrY4zEUEUnG U=;
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="30395716"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 17 Mar 2013 12:43:31 -0700
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="443843191"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Mar 2013 12:43:31 -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; Sun, 17 Mar 2013 12:43:31 -0700
Message-ID: 
In-Reply-To: <4CB74555-CA6A-4FE8-B410-AAD1EF2354A6@acmepacket.com>
References:    <4CB74555-CA6A-4FE8-B410-AAD1EF2354A6@acmepacket.com>
X-Mailer: Eudora for Mac OS X
Date: Sun, 17 Mar 2013 12:36:22 -0700
To: Hadriel Kaplan 
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]
Cc: Randall Gellens , "ietf-languages-bounces@alvestrand.no" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 19:43:34 -0000

At 1:03 AM +0000 3/17/13, Hadriel Kaplan wrote:

>  On Mar 16, 2013, at 5:54 PM, Randall Gellens  wrote:
>
>>>  What's the use-case when the two directions are not identical? 
>>> I.e., when does it make sense to receive Latin but send Swahili 
>>> for the same media?
>>>  I ask because this separation complicates things quite a bit in 
>>> code/testing/error-handling, obviously.
>>
>>  I'll let Harald speak to this as he was pretty insistent that it 
>> was a misuse of SDP (if I understood him) to use the same 
>> attribute for sending and receiving.
>
>  That may be true for attributes specific to a format/payload 
> type... maybe.  But for just attributes applying to a media or 
> session section, I don't think so.  You can look up the registered 
> SDP attributes in IANA and find a bunch that really apply to both 
> directions, at least in practice.

I don't want to put words in Harald's mouth, but my recollection is 
that he specifically mentioned the "in practice" as being an abuse.

>   For example: the 'a=inactive' attribute.  It's not inactive for a 
> specific direction, it's inactive for both directions.

That makes sense, and personally I'm in favor of keeping things as 
simple as possible.  But I also don't want to be accused of fomenting 
further misuse of SDP :-)

>>  The result of the discussion is to add a token for the caller to 
>> indicate a preference for the language being mandatory or 
>> advisory, but the callee is not required to honor this preference.
>
>  If the callee is not required to honor a mandatory preference, then 
> it's not really mandatory is it?
>  Is there a third token for "I really mean it"? ;)

The preference is not mandatory (if it was, it wouldn't be a 
preference, it would be a demand).  The preference indicates if the 
caller wants the callee to treat language as mandatory versus 
advisory.

>>  I can imagine scenarios where failing the call might be preferred, 
>> such as a caller who will call an alternate party if the required 
>> language isn't supported.
>
>  I can imagine scenarios where the caller will call an alternate 
> party as well, but that's what we let them do by letting them 
> hang-up/end the session.

If this is really what is wanted, it is quicker if the call fails 
during setup rather than going through full setup, possible queues 
(remember, a major use case is calling call centers), attempting to 
speak to a representative, and then hanging up in frustration.

>  And I'm not saying that to be flippant.  I'm really worried calls 
> will fail when the user didn't want them to, and that would be bad. 
> Bad because I don't want them having to read a manual to make a 
> call work, or having them contact their provider's tech support to 
> figure out why their call failed.

I am also concerned about introducing features where it is not 
obvious what the client should do.  I can see obvious ways for a 
client to make a reasonable default language choice, and ways to 
allow the user to configure it.  It's harder to see how a client 
knows if the advisory token should be set to fail or proceed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The fetters imposed on liberty at home have ever been forged out of the
weapons provided for defence against real, pretended, or imaginary
dangers from abroad.
        --James Madison, 4th US president (1751-1836)

From juberti@google.com  Sun Mar 17 20:20:17 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3521F8C7D for ; Sun, 17 Mar 2013 20:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level: 
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhm2KL3t+amu for ; Sun, 17 Mar 2013 20:20:16 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id A1E4A21F8C77 for ; Sun, 17 Mar 2013 20:20:14 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id o13so1402692qaj.1 for ; Sun, 17 Mar 2013 20:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EYW7o8bgsZa9jbhTGz4ZkiqE6CX3CPSiOKYpFCCpsFk=; b=YgadBk46FZI06DEfALr66ahovbMgCX67TNRlwy4AZcSZ0DA1T7csY+PAQwV4+l81pp Zzb92iQ04Z2EXFM/VjvJuFOPAG5klBl0xF+VjPcTlOQ6ILwuci1qcnq0ZknUSOS6Fb04 CO6jRVd8SnW3oaKUKtNXCN9cgv3Pdfh/6hBMJcz7fKYDWTQMNMzDuedZXUakDWZ84mVO SUue8cDmPJjLJrjUvKFS++7c/gJjUv4AZeRaO/rMh4oDCOGwTch7H7NWIDAwm8KGYQn+ n6S5DnwnRI/Xf1lrHgvFjQ9cpZ1ckSnHb6zgo+EVWYhN/MWx53MGB9ZRumLSOMRz5Pyo e+4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=EYW7o8bgsZa9jbhTGz4ZkiqE6CX3CPSiOKYpFCCpsFk=; b=oZzUZJXmHhqWwiWoWs1CRfK9aC5mFqAehHacTdI4JaTlwoUkRXGMxKMgp7Xa/7vZmb C0Fc0IQ24t8MZ3dRaOo3h/RADBgyxp2kXao/8lwvPh5RZ64sTQMhI+pWMAcMYtkeqf1H kmnETo3AoU9q3yMZxKaJTmGS/E768fnYNirPFSzBFD8YYuGDGM3u9967iSRMPcpzW/Da /NZKgmEqGALIDwlcsDUSLICWjAUCZjJlF1jCW81bEu/ScGziS+4Q7DX+ydwiWPqY+vqH QiJx67Pi+pxFuiiR+Uhx/4fock+Sy4p2Sz5+GcjD/gH5vIDBWjW4hbj+bymi2J75VVxz aGTg==
X-Received: by 10.224.42.66 with SMTP id r2mr17693296qae.36.1363576812962; Sun, 17 Mar 2013 20:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Sun, 17 Mar 2013 20:19:49 -0700 (PDT)
In-Reply-To: <5145786F.8060507@alvestrand.no>
References:  <5145786F.8060507@alvestrand.no>
From: Justin Uberti 
Date: Sun, 17 Mar 2013 20:19:49 -0700
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=20cf3074b63e8f9b3904d82a77c8
X-Gm-Message-State: ALoCoQlsMTR2zjSnCNjih7xK4hHNnmeWFS7/HfiSKX/3Z6Szgrr706cDXaha473mNIkKSV5WdTazthaeFfzPUblzu2OyH1HbiUyCvJtW3K/RMMZ05nqYNjqNFn3Q3wbnRkmG8B8T7w1eZd1fYlO80EagQxgbhHZcgBF2QNxBwF0OPndm1yihZMjJYx3/dh5qVzinI8xNIxAh
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 03:20:17 -0000

--20cf3074b63e8f9b3904d82a77c8
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 17, 2013 at 1:01 AM, Harald Alvestrand wrote:

>  On 03/15/2013 09:51 PM, Justin Uberti wrote:
>
> The list below is a set of questions (some marked as OPEN ISSUE already)
> regarding the new BUNDLE proposal. If you agree with my suggested answers,
> I'm willing to contribute text accordingly.
>
>    1. Can you create a BUNDLE with a single m= line? (assuming yes)
>    2. Can you create multiple BUNDLEs? (assuming yes)
>    3. When creating an initial offer, how should we deal with the case
>    where a "null" port is to be used with trickle ICE (since 6.1:1 indicates
>    the ports MUST be different)
>
>   Tangential, sort of - when creating an initial offer, when would one
> need to use a null port?
> We're creating the offer, if we don't want the m-line, we can omit it
> altogether.
> (This was one of the things that simplified the problem when Christer,
> Cullen and I were discussing this version).
>

If you are hiding your source address when doing trickle, some non-zero
port # needs to be put into the offer. The current thinking was to use port
9 for this, but this would mean all m= lines would share port 9, although
their ICE info would be different.

This is a corner case, but I think we should specify the behavior exactly.

>
>
>
>    1. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>    use same c=, add rtcp-mux, same a=fingerprint)
>    2. From 6.1, list 2 - is condition 6 right? Why would we use different
>    SDES keys for a single RTP session?
>
>   Having the same SDES keys for two RTP sessions runs the risk of a
> two-time pad attack, I think (needs some other things to be the same too,
> but I don't think there's a guard against that anywhere). So this is a
> fatal flaw if the negotiation results in non-BUNDLE.
>

I was referring to 6.1, list 2, which indicates the behavior to be used
when we know we are BUNDLEing (i.e. one RTP session). List 2 says to use
different SDES keys in this case.

>
> The lists could be better formatted - only 1, 3 and 4 are different
> between the lists, I think it's good to keep the differences between
> "before BUNDLE" and "after BUNDLE" minimal, but one should call out the
> differences.
>
>
>
>    1. If you start with a m= line with one SDES config (e.g. 32-bit MAC),
>    and then BUNDLE with another SDES line with a different (non overlapping)
>    SDES config (e.g. 80-bit MAC), what happens? (assume fail)
>
>   I assume so too. This should be noted.
>
>
>    1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>    the offer, what happens? (assume fail)
>
>   I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>

According to 9.2, the only restriction is the answer mids must be a subset
of the offer, so we would have to specify an exact match directly. But I
think we do want to impose this restriction, or else we can't BUNDLE a new
m-line until we know the other side wants to BUNDLE it as well.

>
>
>    1. If you add a m= line to an existing BUNDLE, can the recipient
>    reject that BUNDLEing (assume no)
>    2. If m= lines are rejected, should their mids show up in the BUNDLE
>    answer? (assume yes?)
>
> Turns out 5888 spells out the behavior here, namely the mids do not
appear.

>
>     1. If not, how does remote side indicate BUNDLE support if it rejects
>       the m= lines that are BUNDLEd?
>
> 5888 also says an empty a=group:BUNDLE line is permissible, so this is a
non-issue.

>
>     1. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>    that were previously BUNDLEd (assume no)
>
>
> Syntactically, it's easy (omit the mid from the a=group:bundle line);
> semantically, I think it hurts my mind to think about what should happen in
> the RTP session(s) and when, so let's just outlaw it.
>

SGTM

>
>
>
> _______________________________________________
> mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--20cf3074b63e8f9b3904d82a77c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Sun, Mar 17, 2013 at 1:01 AM, Harald Alvestrand <harald@alve=
strand.no> wrote:




 =20
   =20
 =20
  

    
On 03/15/2013 09:51 PM, Justin Uberti
      wrote:

    

    

      
The list below is a set of questions (some marked
        as OPEN ISSUE already) regarding the new BUNDLE proposal. If you
        agree with my suggested answers, I'm willing to contribute text
        accordingly.
        

          
    
            
  1. Can you create a BUNDLE with a single m=3D line? (assuming
              yes)
    2. 
            
  2. Can you create multiple BUNDLEs? (assuming yes)
    3. 
            
  3. When creating an initial offer, how should we
              deal with the case where a "null" port is to be use=
d with
              trickle ICE (since 6.1:1 indicates the ports MUST be
              different) 
    
            
    4. 
          

        

      

    

    Tangential, sort of - when creating an initial offer, when would one
    need to use a null port?

    We're creating the offer, if we don't want the m-line, we can o=
mit
    it altogether.

    (This was one of the things that simplified the problem when
    Christer, Cullen and I were discussing this version).

If you are hiding your source address when doing=
 trickle, some non-zero port # needs to be put into the offer. The current =
thinking was to use port 9 for this, but this would mean all m=3D lines wou=
ld share port 9, although their ICE info would be different.




This is a corner case, but I think we shoul=
d specify the behavior exactly.





    

    

      

        

          
    
            
  1. From 6.1, list 1 - are conditions 2, 5, 7
              really necessary? (MUST use same c=3D, add rtcp-mux, same
              a=3Dfingerprint)
    2. 
            
  2. From 6.1, list 2 - is condition 6 right? Why
              would we use different SDES keys for a single RTP session?
          

        

      

    

    Having the same SDES keys for two RTP sessions runs the risk of a
    two-time pad attack, I think (needs some other things to be the same
    too, but I don't think there's a guard against that anywhere). =
So
    this is a fatal flaw if the negotiation results in non-BUNDLE.

I was referring to 6.1, list 2, whi=
ch indicates the behavior to be used when we know we are BUNDLEing (i.e. on=
e RTP session). List 2 says to use different SDES keys in this case.




    

    The lists could be better formatted - only 1, 3 and 4 are different
    between the lists, I think it's good to keep the differences betwee=
n
    "before BUNDLE" and "after BUNDLE" minimal, but one=
 should call out
    the differences.


    

    

      

        

          
    
            
  1. If you start with a m=3D line with one SDES
              config (e.g. 32-bit MAC), and then BUNDLE with another
              SDES line with a different (non overlapping) SDES config
              (e.g. 80-bit MAC), what happens? (assume fail)
    2. 
          

        

      

    

    I assume so too. This should be noted.


    

      

        

          
    
            
  1. 
              If the BUNDLE mids in the answer doesn't match the BUNDLE
              mids in the offer, what happens? (assume fail)
    2. 
          

        

      

    

    I think this violates RFC 5888 section 9.1, so it should be a FAIL.

According to 9.2, the only restric=
tion is the answer mids must be a subset of the offer, so we would have to =
specify an exact match directly. But I think we do want to impose this rest=
riction, or else we can't BUNDLE a new m-line until we know the other s=
ide wants to BUNDLE it as well.





    

      

        

          
    
            
  1. If you add a m=3D line to an existing BUNDLE, can
              the recipient reject that BUNDLEing (assume no)
    2. 
            
  2. If m=3D lines are rejected, should their mids
              show up in the BUNDLE answer? (assume yes?)
Turns out 5888 spells =
out the behavior here, namely the mids do not appear.=C2=A0



    
            
      
              
    1. If not, how does remote side indicate BUNDLE
                support if it rejects the m=3D lines that are BUNDLEd?
      2. =

5888=
 also says an empty a=3Dgroup:BUNDLE line is permissible, so this is a non-=
issue.=C2=A0



      
            
    
            
  1. Is there any way, in a single PeerConnection,
              to unBUNDLE m=3D lines that were previously BUNDLEd (assume
              no)
    2. 
          

        

      

    

    

    Syntactically, it's easy (omit the mid from the a=3Dgroup:bundle
    line); semantically, I think it hurts my mind to think about what
    should happen in the RTP session(s) and when, so let's just outlaw
    it.

SGTM=C2=A0

    

    

      

      

      

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


    

    

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

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





--20cf3074b63e8f9b3904d82a77c8--

From fandreas@cisco.com  Sun Mar 17 22:58:57 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AC821F861A for ; Sun, 17 Mar 2013 22:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.239
X-Spam-Level: 
X-Spam-Status: No, score=-9.239 tagged_above=-999 required=5 tests=[AWL=0.161,  BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 Py-6yOXaxUZO for ; Sun, 17 Mar 2013 22:58:56 -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 E001F21F861B for ; Sun, 17 Mar 2013 22:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2659; q=dns/txt; s=iport; t=1363586336; x=1364795936; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IEdPxDmz5yQdmMAwUV/xCF7n44qqF6TFagI1ZidjY5A=; b=G0Dl0RFgfQHmmtti/tnUc+65GVX0GhXkK1BKPv0Go6atln7+1pa+xggl ETmVlCLMBi2t2ewv4qc/NGNMcdwtt82DP42/MW3OkdOmsYTwz1jg0t0fc WlGxQ38T8ES61qjAIoOnaVf/2JWWVn8N2HTzHjoK8hV4+Uql00nY81Uln M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGWsRlGtJXHB/2dsb2JhbABCxSOBWRZ0giQBAQEDAQEBATU2CgEFCwsOCgkWDwkDAgECARUwBg0BBQIBAYgKBgzBSRMEjVWBQAeDQAOWXpECgyYggTc
X-IronPort-AV: E=Sophos;i="4.84,862,1355097600"; d="scan'208";a="188496238"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 18 Mar 2013 05:58:55 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.244.39]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2I5wspe025552;  Mon, 18 Mar 2013 05:58:54 GMT
Message-ID: <51469282.3080204@cisco.com>
Date: Mon, 18 Mar 2013 00:05:22 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <20130313133920.4040.66777.idtracker@ietfa.amsl.com>   <8680FAA9-F3DC-48FD-8CEC-82E801229072@acmepacket.com>
In-Reply-To: <8680FAA9-F3DC-48FD-8CEC-82E801229072@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 05:58:58 -0000

On 3/15/13 2:11 AM, Hadriel Kaplan wrote:
> Sorry, I didn't notice there was a lengthy email chain about this topic.  Ignore my email below.  It appears from the later emails that others were also confused by the wording of that section, but they know what they meant it to say.
>
> Although I still have one simple question: when is it ok to use a 'ccap' attribute containing either an IP4 or IP6 address?
Based on the thread, that seems to be a discussion that needs to happen.

> For example, how is this useful:
>
>      m=audio 9 PSTN -
>      c=PSTN E164 +15555556666
>      a=ccap:1 IN IP4 198.51.100.7
>      a=tcap:2 RTP/AVP
>      a=omcap:1 0
>
> Since there is no port number being offered for the IPv4 ccap, and the number 9 is being used for PSTN, how would this actually work??
It wouldn't; you could only do it in the other direction (i.e. start 
with "IN" and then offer "PSTN" as an alternative configuration) - not a 
terribly generic connection data capability.

-- Flemming

> -hadriel
>
>
> On Mar 15, 2013, at 1:38 AM, Hadriel Kaplan 
>   wrote:
>
>> For section 3.1.2, page 9:
>>   The 'ccap' attribute MUST NOT be used in
>>   situations where an existing mechanism (such as Interactive
>>   Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>   between different connection addresses (e.g.  "IP4" and "IP6" or
>>   different IP addresses within the same IP address family).
>>
>> What does that sentence actually mean??  What's a "situation" where an existing mechanism *can* be used?
>>
>> Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they cannot both be in an offer?
>> Does it mean 'ccap' MUST NOT be used if it's technically possible to accomplish using ICE, even if the device in question doesn't support ICE?
>>
>> When is it ok to use a ccap containing an IP4 or IP6 address?
>>
>> -hadriel
>>
>>
>> On Mar 13, 2013, at 11:08 AM, Simo.Veikkolainen@nokia.com wrote:
>>
>>> Hello,
>>>
>>> We just submitted a new version of the miscellaneous-caps draft, with text that states that if the connection data capability attribute (a=ccap) is used the port number in the resulting SDP MUST be the same as in the original "m=" line, except for PSTN type bearers (when the port number used is 9).
>>>
>>> Regards,
>>> Simo
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>


From fandreas@cisco.com  Sun Mar 17 22:59:01 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D36F21F866F for ; Sun, 17 Mar 2013 22:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.415
X-Spam-Level: 
X-Spam-Status: No, score=-8.415 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 Yh2mwpAR2zpa for ; Sun, 17 Mar 2013 22:58:54 -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 7635021F85EE for ; Sun, 17 Mar 2013 22:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57457; q=dns/txt; s=iport; t=1363586333; x=1364795933; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iq55Bza2xoZjyaNFkW2xKyQCwE+Qaf22gf8bnk4REdM=; b=Uxmu86XQWASgSF/r5zjAsrUA5vHy/nhivm5W1dt7pUFJxkBOHlzYuGne eRT+3oeVTAN2PsGUOyO28idY+CQs72cwG02eVM85oU1GI5IW5EEK7xmYO IOv3rdEC3AExruk6O94snqWRBbYlVeJ6KxOfMTn2/6NVVbKGoCJt3OmY8 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAKerRlGtJXG9/2dsb2JhbABChBSJa7ckgVkWdIIkAQEBBBoTQQsFCwsRBAEBAQkXAQYHDwI1CQgTAQUCAQEFEod5DMFHF4kJgzyBBRuBAwsQBwEKBgEGgzoDll6BH49jgyYggTc
X-IronPort-AV: E=Sophos;i="4.84,862,1355097600";  d="scan'208,217";a="188501632"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 18 Mar 2013 05:58:51 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.244.39]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2I5wnaV023996;  Mon, 18 Mar 2013 05:58:50 GMT
Message-ID: <514690F2.700@cisco.com>
Date: Sun, 17 Mar 2013 23:58:42 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Simo.Veikkolainen@nokia.com
References:  <5142356F.3060201@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000806000909070709010205"
X-Mailman-Approved-At: Sun, 17 Mar 2013 23:30:59 -0700
Cc: jonathan@vidyo.com, mmusic@ietf.org
Subject: Re: [MMUSIC] RE : I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 05:59:01 -0000

This is a multi-part message in MIME format.
--------------000806000909070709010205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As noted in my e-mail below, the Anaheim discussion was based on the 
original draft-garcia-mmusic-sdp-misc-cap 
 document, 
which did indeed position "ccap" as an alternative to ICE. The 
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps 
which was adopted by the WG changed the wording to what is being 
discussed now and was adopted by the WG.

If people wanted to explicitly prevent this mechanism from being used 
for IP4 and/or IP6 addresses, then I"m at a loss to understand why the 
current wording was chosen and agreed to as well as to why a general 
mechanism like "connection data capability" as part of the overall 
capability negotiation framework was chosen and agreed to. However, in 
spite of the document reviews, long completed WGLC, and the external 
3GPP dependency, it is obvious from the e-mail thread that more 
discussion is needed on this, and hence we will have to deal with that 
before we can progress the document.

Thanks

-- Flemming (MMUSIC co-chair)


On 3/15/13 8:04 AM, Simo.Veikkolainen@nokia.com wrote:
>
> I think this goes all the way back to IETF68, where an agreement was 
> made to use ICE for future address type selection (deprecating ANAT).
>
> I couldn't find a written statement in minutes on ccap being 
> explicitly forbidden to express IP4 and/or IP6 addresses as 
> alternatives -- but my thought has been that alternative IP addresses 
> may only be offered with ICE. This was also reflected in by 
> Jean-Francois 
> (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html) 
> where he says " As for proposing IPv4/IPv6 alternatives, ICE 
> deprecates ANAT and is the preferred solution the WG has chosen so far 
> per IETF#68. "
>
> Simo
>
> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On 
> Behalf Of *ext mohamed.boucadair@orange.com
> *Sent:* 15. maaliskuuta 2013 8:36
> *To:* Flemming Andreasen; Andrew Allen
> *Cc:* jonathan@vidyo.com; mmusic@ietf.org
> *Subject:* Re: [MMUSIC] RE : I-D Action: 
> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
> Felmming,
>
> If you are looking for something written, you can read the minutes in 
> the Anaheim meeting (In 
> http://tools.ietf.org/wg/mmusic/minutes?item=minutes77.html), you can 
> read the following:
>
>                To conclude the WG chair report, Jean-Francois clarified the
>                status ofdraft-ietf-mmusic-sdp-misc-cap-00    (see the chair's
>                slides #9).
>                This Internet-Draft was mistakenly accepted as a WG document
>                without confirmation on the list.
>            
>                After a brief recap of the I-D history and scope, several
>                comments were made in support of continuing the work as part of
>                a WG item as long as the scope does not overlap with ICE for
>                IPv4-IPv6 connection address negotiations:
>                  - Roni Even indicated support for the work and noted that the
>                    b parameter was part of the original SDP capability
>                    negotiation framework.
>                  - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen
>                    Jennings are in favor of the work item as long as its scope
>                    is clarified to not overlap with ICE for IPv4-IPv6 address
>                    negotiation.
>                  - Ingemar Johansson also expressed support for it
>                 There was strong support for continuing to define a capability
>                 parameter for b, i and some concerns with the ccap parameter.
>                 More discussions occurred at the end of the meeting when the
>                 document was presented, see notes below.
>            
>                 Jean-Francois proposed the next steps:
>                  - the WG chairs will confirm the interest for a WG item to
>                    define additional SDP cap neg parameters (b and i lines)
>                  - Pending AD approval, the WG item will be chartered
>                  - Simo V. will re-submit an updated Internet-Draft as an
>                    individual submission
>                  - then the chairs will ask the list if the Working Group
>                    supports making Simo's individual submission as the WG
>                    draft.
> The current discussion shows there is a confusion in the current text and it is worth to be clarified.
> Cheers,
> Med
>
>     ------------------------------------------------------------------------
>
>     *De :*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *De
>     la part de* Flemming Andreasen
>     *Envoyé :* jeudi 14 mars 2013 21:39
>     *À :* Andrew Allen
>     *Cc :* jonathan@vidyo.com; mmusic@ietf.org
>     *Objet :* Re: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>     On 3/14/13 3:50 PM, Andrew Allen wrote:
>
>
>         I am not sure if anything is recorded in any minutes but we
>         had an offline discussion to remove the roadblock on this with
>         Jonathan to address his concern that this was a potential
>         alternative to ICE and addressed this with the current text.
>         This text and the reason behind it I think was pointed out on
>         the list during Quebec or shortly after.
>
>     Can you find the message or recall who sent it ?
>
>     Also, the Quebec meeting was in July 2011. Tracing back we have:
>
>     a) The initial (?) individul versions of the draft (2008/2009):
>     http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
>     b) Another individual take on the draft (August 2011+):
>     http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
>     c) The intial WG version of the draft (March 2012+):
>     http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps
>
>     The "a)" version did indeed position the draft as an alternative
>     to ICE, however all "b)" and "c)" versions changed this as per the
>     previous discussion.
>
>     I'm still looking for anything written anywhere that suggests that
>     the text in "b)" and "c)" does not represent consensus and/or that
>     consensus is that the mechanism MUST always be prohibited from
>     negotiating IP4/IP6 addresses (as opposed to just when ICE is not
>     available).
>
>     Thanks
>
>     -- Flemming
>
>
>     *From*: Flemming Andreasen [mailto:fandreas@cisco.com]
>     *Sent*: Thursday, March 14, 2013 02:45 PM Central Standard Time
>     *To*: Stach, Thomas 
>     
>     *Cc*: Andrew Allen; jonathan@vidyo.com 
>      ; mmusic@ietf.org
>       
>     *Subject*: Re: AW: [MMUSIC] RE : I-D Action:
>     draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>     As to ccap not being an alternative to ICE we are all in agreement
>     on that - the lack of port negotiation alone makes that clear (it
>     simply doesn't work without that).
>
>     As to ccap being explicitly forbidden to express IP4 and/or IP6
>     addresses as alternatives, can somebody please point me to either
>     meeting minutes or mailing list discussion to that effect ? The
>     only thing I have found is the port discussion we had in Taipei,
>     where we agreed not to add a port capability. From
>     http://www.ietf.org/proceedings/82/minutes/mmusic.htm
>     :
>     
>
>     Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)
>
>     =====================================================================
>
>     draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt
>     
>
>     Simo presented hisslides
>     .
>
>     Simo explained the need to be able to indicate alternative port
>     numbers, but PSTN media, port number doesn't make sense. The CS
>     draft says use port number 9 (the discard port). We have to put
>     something there because required by SDP syntax. If an RTP stream
>     is offered, then a regular port number should be written instead.
>     The problem arises when both CS and RTP streams are offered at the
>     same time, one as an alternative of the other. Then, the port
>     number makes sense for RTP but not for CS, but still, there is a
>     single place to write the port number in the SDP, so, has to be
>     shared by both alternative media streams.
>
>     Possible solutions:
>
>     1. Circuit-switched media uses the same port as RTP media even
>     though the port is not really used
>
>     2. Extend capneg with a port number capability attribute,
>     restricting its use to cases where ICE cannot be used.
>
>     3. Select anything as a port number and say "do not care on
>     reception".
>
>     Jonathan Lennox suggested saying that port numbers not equal 0
>     have to be ignored.
>
>     Hadriel Kaplan asked if middle boxes not supporting this stuff can
>     be broken. The discussion is moved offline.
>
>     There are questions on how could be possible to indicate
>     preference for one media stream above the alternative.
>
>     Miguel Garcia suggested using port 9 if it works. If not take
>     anything not equal 0. Receiver has to ignore.
>
>     In general, there was pushback on the port negotiation approach.
>     The authors should explore a solution along the third option:
>     write the RTP port number in the "m=" line. If CS alternative is
>     chosen, discard the port number on reception.
>     
>
>
>     Apart from that, the only thing I'm aware of is the 4 WG versions
>     of this draft which have all said the same about IP4/IP6 and ICE,
>     and again, that text was both WGLC'ed and reviewed by 2 volunteers
>     without any concerns. Where does the alternate understanding come
>     from ?
>
>     Thanks
>
>     -- Flemming
>
>
>     On 3/14/13 2:16 PM, Stach, Thomas wrote:
>
>         This is also my understanding
>
>         ... although my initially proposed text does not reflect this
>         correctly.
>
>         Regards
>         Thomas
>
>             ------------------------------------------------------------------------
>
>             *Von:*mmusic-bounces@ietf.org
>             
>             [mailto:mmusic-bounces@ietf.org] *Im Auftrag von *Andrew Allen
>             *Gesendet:* Donnerstag, 14. März 2013 14:10
>             *An:* jonathan@vidyo.com ;
>             fandreas@cisco.com 
>             *Cc:* mmusic@ietf.org 
>             *Betreff:* Re: [MMUSIC] RE : I-D Action:
>             draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>
>             My understanding also was that we agreed that CCAP was not
>             an alternative to ICE.
>
>             *From*: Jonathan Lennox [mailto:jonathan@vidyo.com]
>             *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard
>             Time
>             *To*: Flemming Andreasen 
>             
>             *Cc*: mohamed.boucadair@orange.com
>             
>             
>             ; Andrew Allen;
>             mmusic@ietf.org  
>             
>             *Subject*: Re: [MMUSIC] RE : I-D Action:
>             draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>             On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:
>
>
>
>             On 3/14/13 11:40 AM, mohamed.boucadair@orange.com
>              wrote:
>
>                 Re-,
>
>                 What is important is the quality of produced
>                 documents. The content of the document is not frozen
>                 and unless I'm mistaken there is not IETF LC.
>
>             Correct.
>
>             What I understand from the text in the draft is: ccap is
>             allowed to signal an IPv4@ and IPv6@ if ICE is not supported.
>
>             ccap is not prohibited from doing so in the absence of
>             ICE, however as explained in the document
>             1) When the IETF Standard Track mechanism ICE is
>             available, ccap MUST NOT signal an IPv4/IPV6 address
>             alternative.
>             2) The draft does (intentionally) not provide a full
>             solution for negotiating alternative IP-addresses since we
>             have a Standards Track mechanism for doing so (ICE).
>
>             Hi, Fleming --
>
>             My understanding of the WG consensus -- and my
>             interpretation of the text in the draft -- was stronger
>             than this: ccap MUST NOT be used for the kinds of
>             alternatives ICE can express, whether or not ICE is
>             actually being used in a particular offer/answer.
>
>             If we're getting divergent interpretations of this
>             document, we probably do need to update its text.
>
>             --
>
>             Jonathan Lennox
>             jonathan@vidyo.com 
>
>
>             ---------------------------------------------------------------------
>
>             This transmission (including any attachments) may contain
>             confidential information, privileged material (including
>             material protected by the solicitor-client or other
>             applicable privileges), or constitute non-public
>             information. Any use of this information by anyone other
>             than the intended recipient is prohibited. If you have
>             received this transmission in error, please immediately
>             reply to the sender and delete this information from your
>             system. Use, dissemination, distribution, or reproduction
>             of this transmission by unintended recipients is not
>             authorized and may be unlawful.
>
>
>     ---------------------------------------------------------------------
>     This transmission (including any attachments) may contain
>     confidential information, privileged material (including material
>     protected by the solicitor-client or other applicable privileges),
>     or constitute non-public information. Any use of this information
>     by anyone other than the intended recipient is prohibited. If you
>     have received this transmission in error, please immediately reply
>     to the sender and delete this information from your system. Use,
>     dissemination, distribution, or reproduction of this transmission
>     by unintended recipients is not authorized and may be unlawful.
>


--------------000806000909070709010205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    As noted in my e-mail below, the Anaheim discussion was based on the
    original draft-garcia-mmusic-sdp-misc-cap
    document, which did indeed position "ccap" as an alternative to ICE.
    The http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
    which was adopted by the WG changed the wording to what is being
    discussed now and was adopted by the WG. 

    

    If people wanted to explicitly prevent this mechanism from being
    used for IP4 and/or IP6 addresses, then I"m at a loss to understand
    why the current wording was chosen and agreed to as well as to why a
    general mechanism like "connection data capability" as part of the
    overall capability negotiation framework was chosen and agreed to.
    However, in spite of the document reviews, long completed WGLC, and
    the external 3GPP dependency, it is obvious from the e-mail thread
    that more discussion is needed on this, and hence we will have to
    deal with that before we can progress the document. 

    

    Thanks 

    

    -- Flemming (MMUSIC co-chair)

    

    

    
On 3/15/13 8:04 AM,
      Simo.Veikkolainen@nokia.com wrote:

    

    

      
      
      
      
      

        
I
            think this goes all the way back to IETF68, where an
            agreement was made to use ICE for future address type
            selection (deprecating ANAT).

        
 

        
I
            couldn’t find a written statement in minutes on ccap being
            explicitly forbidden to express IP4 and/or IP6 addresses as
            alternatives – but my thought has been that alternative IP
            addresses may only be offered with ICE. This was also
            reflected in by Jean-Francois (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html)
            where he says ” As
            for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT
            and is the preferred solution the WG has chosen so far per
            IETF#68. “             
            

        
 

        
Simo

        
 

        
 

        

          

            
From:
                mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
                On Behalf Of ext mohamed.boucadair@orange.com

                Sent: 15. maaliskuuta 2013 8:36

                To: Flemming Andreasen; Andrew Allen

                Cc: jonathan@vidyo.com; mmusic@ietf.org

                Subject: Re: [MMUSIC] RE : I-D Action:
                draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          

        

        
 

        
Felmming,

        
 

        
If you are looking for something
            written, you can read the minutes in the Anaheim meeting (In
            http://tools.ietf.org/wg/mmusic/minutes?item=minutes77.html),
            you can read the following:

        
              To conclude the WG chair report, Jean-Francois clarified the

        
              status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's

        
              slides #9).

        
              This Internet-Draft was mistakenly accepted as a WG document

        
              without confirmation on the list.

        
          

        
              After a brief recap of the I-D history and scope, several

        
              comments were made in support of continuing the work as part of

        
              a WG item as long as the scope does not overlap with ICE for

        
              IPv4-IPv6 connection address negotiations:

        
                - Roni Even indicated support for the work and noted that the

        
                  b parameter was part of the original SDP capability

        
                  negotiation framework.

        
                - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen

        
                  Jennings are in favor of the work item as long as its scope

        
                  is clarified to not overlap with ICE for IPv4-IPv6 address

        
                  negotiation.

        
                - Ingemar Johansson also expressed support for it

        
               There was strong support for continuing to define a capability

        
               parameter for b, i and some concerns with the ccap parameter.

        
               More discussions occurred at the end of the meeting when the

        
               document was presented, see notes below.

        
          

        
               Jean-Francois proposed the next steps:

        
                - the WG chairs will confirm the interest for a WG item to

        
                  define additional SDP cap neg parameters (b and i lines)

        
                - Pending AD approval, the WG item will be chartered

        
                - Simo V. will re-submit an updated Internet-Draft as an

        
                  individual submission

        
                - then the chairs will ask the list if the Working Group

        
                  supports making Simo's individual submission as the WG

        
                  draft.

        
The current discussion shows there is a confusion in the current text and it is worth to be clarified.

        
Cheers,

        
Med

        

          
 

          

              

            

          
De : mmusic-bounces@ietf.org
              [mailto:mmusic-bounces@ietf.org]
              De la part de Flemming Andreasen

              Envoyé : jeudi 14 mars 2013 21:39

              À : Andrew Allen

              Cc : jonathan@vidyo.com; mmusic@ietf.org

              Objet : Re: [MMUSIC] RE : I-D Action:
              draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

          
 

          

            
On 3/14/13 3:50 PM, Andrew Allen wrote:

          

          

            


                I am not sure if anything is recorded in any minutes but
                we had an offline discussion to remove the roadblock on
                this with Jonathan to address his concern that this was
                a potential alternative to ICE and addressed this with
                the current text. This text and the reason behind it I
                think was pointed out on the list during Quebec or
                shortly after.

          

          
Can you find the message or recall who
            sent it ? 

            

            Also, the Quebec meeting was in July 2011. Tracing back we
            have:

            

            a) The initial (?) individul versions of the draft
            (2008/2009):     
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap

            b) Another individual take on the draft (August 2011+):  
                  http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps

            c) The intial WG version of the draft (March 2012+):        
                http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

            

            The "a)" version did indeed position the draft as an
            alternative to ICE, however all "b)" and "c)" versions
            changed this as per the previous discussion.
            

            

            I'm still looking for anything written anywhere that
            suggests that the text in "b)" and "c)" does not represent
            consensus and/or that consensus is that the mechanism MUST
            always be prohibited from negotiating IP4/IP6 addresses (as
            opposed to just when ICE is not available). 

            

            Thanks 

            

            -- Flemming 

            

            

            

          
 

          

            
From:
                Flemming Andreasen [mailto:fandreas@cisco.com]
                

                Sent: Thursday, March 14, 2013 02:45 PM Central
                Standard Time

                To: Stach, Thomas <thomas.stach@siemens-enterprise.com>
                

                Cc: Andrew Allen; jonathan@vidyo.com
                <jonathan@vidyo.com>;
                
                  mmusic@ietf.org <mmusic@ietf.org>
                

                Subject: Re: AW: [MMUSIC] RE : I-D Action:
                draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
                

               

          

          
As to ccap not being an alternative to
            ICE we are all in agreement on that - the lack of port
            negotiation alone makes that clear (it simply doesn't work
            without that).
            

            

            As to ccap being explicitly forbidden to express IP4 and/or
            IP6 addresses as alternatives, can somebody please point me
            to either meeting minutes or mailing list discussion to that
            effect ? The only thing I have found is the port discussion
            we had in Taipei, where we agreed not to add a port
            capability. From 
              http://www.ietf.org/proceedings/82/minutes/mmusic.htm:

            <quote>

            

            

          
Miscellaneous Capabilities Negotiation in SDP
              (Simo Veikkolainen, 10)

          

            =====================================================================

          

            draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt

          

            Simo presented his slides.

          

            Simo explained the need to be able to indicate
              alternative port numbers, but PSTN media, port number
              doesn't make sense. The CS draft says use port number 9
              (the discard port). We have to put something there because
              required by SDP syntax. If an RTP stream is offered, then
              a regular port number should be written instead. The
              problem arises when both CS and RTP streams are offered at
              the same time, one as an alternative of the other. Then,
              the port number makes sense for RTP but not for CS, but
              still, there is a single place to write the port number in
              the SDP, so, has to be shared by both alternative media
              streams.

          

            Possible solutions:

          

            1. Circuit-switched media uses the same port as
              RTP media even though the port is not really used

          

            2. Extend capneg with a port number capability
              attribute, restricting its use to cases where ICE cannot
              be used.

          

            3.  Select
              anything as a port number and say "do not care on
              reception".

          

            Jonathan Lennox suggested saying that port
              numbers not equal 0 have to be ignored.

          

            Hadriel Kaplan asked if middle boxes not
              supporting this stuff can be broken. The discussion is
              moved offline.

          

            There are questions on how could be possible to
              indicate preference for one media stream above the
              alternative.

          

            Miguel Garcia suggested using port 9 if it
              works. If not take anything not equal 0. Receiver has to
              ignore.

          

            In general, there was pushback on the port
              negotiation approach. The authors should explore a
              solution along the third option: write the RTP port number
              in the "m=" line. If CS alternative is chosen, discard the
              port number on reception.

              </quote>

          


            Apart from that, the only thing I'm aware of is the 4 WG
            versions of this draft which have all said the same about
            IP4/IP6 and ICE, and again, that text was both WGLC'ed and
            reviewed by 2 volunteers without any concerns. Where does
            the alternate understanding come from ? 

            

            Thanks 

            

            -- Flemming 

            

            

            

          

            
On 3/14/13 2:16 PM, Stach, Thomas
              wrote:

          

          

            

              
This
                  is also my understanding
                

            

            

              
...
                  although my initially proposed text does not reflect
                  this correctly.

            

            

              
 

            

            

              
Regards

                  Thomas 

            

            

              
 

            

            

              
 

              

                  

                

              
Von:
                  mmusic-bounces@ietf.org
                  [mailto:mmusic-bounces@ietf.org]
                  Im Auftrag von Andrew Allen

                  Gesendet: Donnerstag, 14. März 2013 14:10

                  An: jonathan@vidyo.com;
                  
                    fandreas@cisco.com

                  Cc: mmusic@ietf.org

                  Betreff: Re: [MMUSIC] RE : I-D Action:
                  draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

              


                  My understanding also was that we agreed that CCAP was
                  not an alternative to ICE.

                

                 

              

                
From:
                    Jonathan Lennox [mailto:jonathan@vidyo.com]
                    

                    Sent: Thursday, March 14, 2013 01:06 PM
                    Central Standard Time

                    To: Flemming Andreasen <fandreas@cisco.com>
                    

                    Cc: mohamed.boucadair@orange.com
                    <mohamed.boucadair@orange.com>;
                    Andrew Allen;
                    mmusic@ietf.org
                    
                      <mmusic@ietf.org> 

                    Subject: Re: [MMUSIC] RE : I-D Action:
                    draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
                    

                   

              

              
 

              

                

                  
On Mar 14, 2013, at 1:43 PM,
                    Flemming Andreasen wrote:

                

                


                  

                  

                

                  

                    
On 3/14/13 11:40 AM, 
                        mohamed.boucadair@orange.com wrote:

                  

                  

                    
Re-,

                    
 

                    
What is important is the
                        quality of produced documents. The content of
                        the document is not frozen and unless I'm
                        mistaken there is not IETF LC.

                    
 

                  

                  
Correct. 

                    

                    

                  
What I understand from the
                      text in the draft is: ccap is allowed to signal an
                      IPv4@ and IPv6@ if ICE is not supported.

                  
 

                  
ccap is not prohibited from doing
                    so in the absence of ICE, however as explained in
                    the document

                    1) When the IETF Standard Track mechanism ICE is
                    available, ccap MUST NOT signal an IPv4/IPV6 address
                    alternative.

                    2) The draft does (intentionally) not provide a full
                    solution for negotiating alternative IP-addresses
                    since we have a Standards Track mechanism for doing
                    so (ICE).
                    

                

                

                  
 

                

                

                  
Hi, Fleming --

                

                

                  
 

                

                

                  
My understanding of the WG
                    consensus -- and my interpretation of the text in
                    the draft -- was stronger than this: ccap MUST NOT
                    be used for the kinds of alternatives ICE can
                    express, whether or not ICE is actually being used
                    in a particular offer/answer.

                

                

                  
 

                

                

                  
If we're getting divergent
                    interpretations of this document, we probably do
                    need to update its text.

                

              

              
 

              

                

                  
--

                

                

                  
Jonathan
                      Lennox

                      jonathan@vidyo.com

                

              

              


                ---------------------------------------------------------------------
                

                This transmission (including any attachments) may
                contain confidential information, privileged material
                (including material protected by the solicitor-client or
                other applicable privileges), or constitute non-public
                information. Any use of this information by anyone other
                than the intended recipient is prohibited. If you have
                received this transmission in error, please immediately
                reply to the sender and delete this information from
                your system. Use, dissemination, distribution, or
                reproduction of this transmission by unintended
                recipients is not authorized and may be unlawful. 

            

          

          


            ---------------------------------------------------------------------
            

            This transmission (including any attachments) may contain
            confidential information, privileged material (including
            material protected by the solicitor-client or other
            applicable privileges), or constitute non-public
            information. Any use of this information by anyone other
            than the intended recipient is prohibited. If you have
            received this transmission in error, please immediately
            reply to the sender and delete this information from your
            system. Use, dissemination, distribution, or reproduction of
            this transmission by unintended recipients is not authorized
            and may be unlawful. 

          
 

        

      

    

    

  


--------------000806000909070709010205--

From harald@alvestrand.no  Mon Mar 18 00:08:12 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47D321F86A8 for ; Mon, 18 Mar 2013 00:08:12 -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 z9CL6PHd9G77 for ; Mon, 18 Mar 2013 00:08:12 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C460621F854F for ; Mon, 18 Mar 2013 00:08:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1639439E0E1; Mon, 18 Mar 2013 08:08:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbIdDoIRm2DB; Mon, 18 Mar 2013 08:08:07 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:8cd4:f75f:204f:7ae0] (unknown [IPv6:2001:470:de0a:27:8cd4:f75f:204f:7ae0]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2D1A439E01E; Mon, 18 Mar 2013 08:08:07 +0100 (CET)
Message-ID: <5146BD66.9090506@alvestrand.no>
Date: Mon, 18 Mar 2013 08:08:22 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Justin Uberti 
References:  <5145786F.8060507@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090800090006060106090107"
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 07:08:12 -0000

This is a multi-part message in MIME format.
--------------090800090006060106090107
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/18/2013 04:19 AM, Justin Uberti wrote:
>
>
>>      1. If the BUNDLE mids in the answer doesn't match the BUNDLE
>>         mids in the offer, what happens? (assume fail)
>>
>     I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>
>
> According to 9.2, the only restriction is the answer mids must be a 
> subset of the offer, so we would have to specify an exact match 
> directly. But I think we do want to impose this restriction, or else 
> we can't BUNDLE a new m-line until we know the other side wants to 
> BUNDLE it as well.

The important phrase from 9.1 is

    If a media stream that contained a particular "mid" identifier in the
    offer contains a different identifier in the answer, the application
    ignores all of the "mid" and "group" lines that might appear in the
    session description.  The following example illustrates this
    scenario.

So if there's any mismatch, we don't get BUNDLE negotiated. Negotiation 
might not fail, but we don't get BUNDLE (or any other form of grouping).



--------------090800090006060106090107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 03/18/2013 04:19 AM, Justin Uberti
      wrote:

    

    

      


        

          

            

              

                


                  

                    

                      

                        
    
                          
  1.  If the BUNDLE mids in the answer doesn't
                            match the BUNDLE mids in the offer, what
                            happens? (assume fail)
    2. 
                        

                      

                    

                  

                

                I think this violates RFC 5888 section 9.1, so it should
                be a FAIL.

            

            


            

            
According to 9.2, the only restriction is the
              answer mids must be a subset of the offer, so we would
              have to specify an exact match directly. But I think we do
              want to impose this restriction, or else we can't BUNDLE a
              new m-line until we know the other side wants to BUNDLE it
              as well.

          

        

      

    

    

    The important phrase from 9.1 is

    

       If a media stream that contained a particular "mid" identifier in
    the

       offer contains a different identifier in the answer, the
    application

       ignores all of the "mid" and "group" lines that might appear in
    the

       session description.  The following example illustrates this

       scenario.

    

    So if there's any mismatch, we don't get BUNDLE negotiated.
    Negotiation might not fail, but we don't get BUNDLE (or any other
    form of grouping).

    

    

  


--------------090800090006060106090107--

From juberti@google.com  Mon Mar 18 08:59:46 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3EA21F8D64 for ; Mon, 18 Mar 2013 08:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.376
X-Spam-Level: 
X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRdOQlK673Oa for ; Mon, 18 Mar 2013 08:59:46 -0700 (PDT)
Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id D21B021F8D62 for ; Mon, 18 Mar 2013 08:59:45 -0700 (PDT)
Received: by mail-qe0-f41.google.com with SMTP id 6so3487044qeb.0 for ; Mon, 18 Mar 2013 08:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=emls6xyRfOJz0Zo5OEBU0/k6p1u7tzrcx0PjSo7EYXQ=; b=hpQ6BYyvsjfvAAnVZwAStdCRKfR47g7BFosfKo8CmwDvxqtGRVIyFo/9QTUtPJWShI Ce3ea0d7NvdNaJJo1fLWIwDBAt6CT13pZRaCRqc3a1YrZQiZNyR21zjSJ1IkLTi7lZtU quQjv2IruyrrDEnJlVNXE8G0LbLOmloRDpheQ/Yvb0Nj+T9W6tB0WKiVVGHz3mMQ4uRs QtFeDrOuEmI1AhOVg0B+UDfSxvjxvF4VJJhsN5KhpMPrL8H7IhYSIs1Nw9NeRS05snnM KLsfP3WiwjfcjHLcWyJ42Ps7hkSlyEcoT/svoJdWkWs6xqwe1AxLVNEVTxmCRYoS1xjK ezog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=emls6xyRfOJz0Zo5OEBU0/k6p1u7tzrcx0PjSo7EYXQ=; b=nCj8YEtxBorR2g+8B2279Krr2+Tm66QYFiE3hZQT48Lvx/vTZNjvBmu86oRF6KlTWL mqhOf9KakF3Hl/NaWo6R3UyYs8hjbUloqfAOVgYS78xzJkSMhMEMqX+mVxHfpjThTO+X xt/Q5UFi4vpvhN0IK6XUXJA2CKLtOO6xKWHo3IZ2/qZyZ7R7GCLFoL0Z30FPps+F8/bg fozDpzxIygiHnyqpF1KIfX46dCOH9mz1W2pb2YVZ9SE2TxfP3iLqzugxeTevkGjiNCS5 RfHDDZa93Pz6nw6bXQXfd6C54SJTNm1YkTg3Cw1bD84I6djI/RgndrwzopEImvLRXKef MWIw==
X-Received: by 10.224.178.77 with SMTP id bl13mr20720307qab.13.1363622385319;  Mon, 18 Mar 2013 08:59:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Mon, 18 Mar 2013 08:59:22 -0700 (PDT)
In-Reply-To: <5146BD66.9090506@alvestrand.no>
References:  <5145786F.8060507@alvestrand.no>  <5146BD66.9090506@alvestrand.no>
From: Justin Uberti 
Date: Mon, 18 Mar 2013 08:59:22 -0700
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=20cf302ef79ee299c804d8351303
X-Gm-Message-State: ALoCoQnzddAb/UeaOPKTbtQf5xgbt+T62eojbRxi2D4u4pV4H9kLNiIygwCqLC8CsUi12WTKHjPisVYvMLYckAvcv60cK+E91l7+M9GHyWrVZDIEWTDRjvPbV6QddqKsX2xecnCq90TvvZUSfqzJ+XWyvlO11TAtFc2f04wVDPdMiLaveAPfsXl5+CsXnWZjoHDmDzWqL31b
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 15:59:46 -0000

--20cf302ef79ee299c804d8351303
Content-Type: text/plain; charset=UTF-8

You're looking at the handling of a=mid, not a=group.

Section 9.2 indicates the handling of a=group, which seems to indicate a
subset is allowed:


   A SIP entity that receives an offer that contains an "a=group" line
   with semantics that are understood MUST return an answer that
   contains an "a=group" line with the same semantics.  The
   identification-tags contained in this "a=group" line MUST be the same
   as those received in the offer, or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in the
   session MUST be the one present in the answer.




On Mon, Mar 18, 2013 at 12:08 AM, Harald Alvestrand wrote:

>  On 03/18/2013 04:19 AM, Justin Uberti wrote:
>
>
>
>>
>>    1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>>    the offer, what happens? (assume fail)
>>
>>   I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>>
>
>  According to 9.2, the only restriction is the answer mids must be a
> subset of the offer, so we would have to specify an exact match directly.
> But I think we do want to impose this restriction, or else we can't BUNDLE
> a new m-line until we know the other side wants to BUNDLE it as well.
>
>
> The important phrase from 9.1 is
>
>    If a media stream that contained a particular "mid" identifier in the
>    offer contains a different identifier in the answer, the application
>    ignores all of the "mid" and "group" lines that might appear in the
>    session description.  The following example illustrates this
>    scenario.
>
> So if there's any mismatch, we don't get BUNDLE negotiated. Negotiation
> might not fail, but we don't get BUNDLE (or any other form of grouping).
>
>
>

--20cf302ef79ee299c804d8351303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You're looking at the handling of a=3Dmid, not a=3Dgro=
up.

Section 9.2 indicates the handling of a=3Dgroup, whi=
ch seems to indicate a subset is allowed:


   A SIP entity that receives an offer that contains an "a=3Dgroup&quo=
t; line
   with semantics that are understood MUST return an answer that
   contains an "a=3Dgroup" line with the same semantics.  The
   identification-tags contained in this "a=3Dgroup" line MUST be=
 the same
   as those received in the offer, or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in th=
e
   session MUST be the one present in the answer.




On Mon, Mar 18, 2013 at 12:08 AM, Harald Alvestrand <harald@alvestrand.no> wrote:




 =20
   =20
 =20
  

    
On 03/18/2013 04:19 AM, Justin Uberti
      wrote:

    

    

      


        

          

            

              

                


                  

                    

                      

                        
    
                          
  1.  If the BUNDLE mids in the answer doesn't
                            match the BUNDLE mids in the offer, what
                            happens? (assume fail)
    2. 
                        

                      

                    

                  

                

                I think this violates RFC 5888 section 9.1, so it should
                be a FAIL.

            

            


            

            
According to 9.2, the only restriction is the
              answer mids must be a subset of the offer, so we would
              have to specify an exact match directly. But I think we do
              want to impose this restriction, or else we can't BUNDLE =
a
              new m-line until we know the other side wants to BUNDLE it
              as well.

          

        

      

    

    

    The important phrase from 9.1 is

    

    =C2=A0=C2=A0 If a media stream that contained a particular "mid&qu=
ot; identifier in
    the

    =C2=A0=C2=A0 offer contains a different identifier in the answer, the
    application

    =C2=A0=C2=A0 ignores all of the "mid" and "group" l=
ines that might appear in
    the

    =C2=A0=C2=A0 session description.=C2=A0 The following example illustrat=
es this

    =C2=A0=C2=A0 scenario.

    

    So if there's any mismatch, we don't get BUNDLE negotiated.
    Negotiation might not fail, but we don't get BUNDLE (or any other
    form of grouping).

    

    

  






--20cf302ef79ee299c804d8351303--

From worley@shell01.TheWorld.com  Mon Mar 18 09:19:29 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B416221F8D11 for ; Mon, 18 Mar 2013 09:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.913
X-Spam-Level: 
X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 lmlDUOm4Au19 for ; Mon, 18 Mar 2013 09:19:21 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E3CE021F8922 for ; Mon, 18 Mar 2013 09:19:05 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2IGIhoV031285; Mon, 18 Mar 2013 12:18:45 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2IGIgvX694881; Mon, 18 Mar 2013 11:18:42 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2IGIf0M694742; Mon, 18 Mar 2013 12:18:41 -0400 (EDT)
Date: Mon, 18 Mar 2013 12:18:41 -0400 (EDT)
Message-Id: <201303181618.r2IGIf0M694742@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Harald Alvestrand 
In-reply-to: <5145786F.8060507@alvestrand.no> (harald@alvestrand.no)
References:  <5145786F.8060507@alvestrand.no>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 16:19:29 -0000

> From: Harald Alvestrand 
> 
> On 03/15/2013 09:51 PM, Justin Uberti wrote:
> > The list below is a set of questions (some marked as OPEN ISSUE 
> > already) regarding the new BUNDLE proposal. If you agree with my 
> > suggested answers, I'm willing to contribute text accordingly.
> >
> >  1. Can you create a BUNDLE with a single m= line? (assuming yes)
> >  2. Can you create multiple BUNDLEs? (assuming yes)
> >  3. When creating an initial offer, how should we deal with the case
> >     where a "null" port is to be used with trickle ICE (since 6.1:1
> >     indicates the ports MUST be different)
> >
> Tangential, sort of - when creating an initial offer, when would one 
> need to use a null port?

I think what Justin means is that if an m= line does not have any
candidates at the time of the offer (candidates will be supplied
during trickle ICE), then the m= line is given a dummy port of 9.
>From draft-ivov-mmusic-trickle-ice-01 section 5.1:

   As mentioned earlier in this section, Offers and Answers can contain
   any set of candidates, which means that a trickle ICE session
   description MAY contain no candidates at all.  In such cases the
   agent would still need to place an address in the "c=" line(s).  If
   the use of a host address there is undesirable (e.g.  for privacy
   reasons), the agent MAY set the connection address to IP6 ::. In this
   case it MUST also set the port number to 9 (Discard).  There is no
   need to include a fictitious candidate for the IP6 :: address when
   doing so.

If there are multiple such lines, port 9 can appear in multiple m=
lines, and if the offerer is not hiding its address, the corresponding
c= lines could contain the host address.

Dale

From eckelcu@cisco.com  Mon Mar 18 12:02:13 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6311E80F4; Mon, 18 Mar 2013 12:02:13 -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 UOmHNLiU4NBK; Mon, 18 Mar 2013 12:02:02 -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 AEA5011E80F7; Mon, 18 Mar 2013 12:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1664; q=dns/txt; s=iport; t=1363633279; x=1364842879; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WMlPumO9yPiaA5xywcCwEE/IvoovuY18HCpc/s9ZiUw=; b=E4D5Fbye6nItQy5ATNFzaM8KxAceL+68Tep+DUUe851ptjMqKR44GZuq G3NzEzwkeiy01Fiokjnhda4ybSiIhC2DNRme8wrHE3H5XLxEJJ5AcW9OW +QzQYf3r2+ftWEyooAwE3jUV6tNkPuOawL7uXAtDRUBN9sKrknHo7NOhR Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFABlkR1GtJXG//2dsb2JhbABDxR2BVhZ0giQBAQEEAQEBGh00FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIiAsBDMIUBI5kOAaCWWEDp2CDCoIo
X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188768634"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 18 Mar 2013 19:01:19 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2IJ1JJD028774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 19:01:19 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 14:01:19 -0500
From: "Charles Eckel (eckelcu)" 
To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: RTP grouping taxonomy
Thread-Index: Ac4hsk+S4mfi5mU7TkGQ4dtodxjawQCWGR5Q
Date: Mon, 18 Mar 2013 19:01:18 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D7FF5@xmb-aln-x08.cisco.com>
References: <949EF20990823C4C85C18D59AA11AD8B016A9B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B016A9B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.68.16.50]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] RTP grouping taxonomy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:02:13 -0000

I agree there is need for such a document, and I am willing to contribute t=
ext and/or review it.

Cheers,
Charles

> -----Original Message-----
> From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Friday, March 15, 2013 12:27 PM
> To: avtext@ietf.org; mmusic@ietf.org
> Subject: [avtext] RTP grouping taxonomy
>=20
> (As AVTEXT cochair)
>=20
> In the joint session between AVTEXT and MMUSIC today we took a call in th=
e
> room with substantial consensus in the room that there should be a
> document in some group in the RAI area that described the RTP grouping
> taxonomy.
>=20
> The RAI ADs will decide which group this should go to and therefore which
> list should be used for the discussion.
>=20
> This is a call to the membership of both the MMUSIC list and AVTEXT list =
to
> confirm that decision. If you were in the room you do not need to reply.
> Particularly if you do have objections please reply as soon as practicabl=
e at
> least to the appropriate chairs and the RAI ADs with your objections.
>=20
> In addition, if you want to contribute to Jonathan Lennox's document
>=20
> https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-
> taxonomy/
>=20
> directly then please do feel free to contact him for details on how to pr=
ovide
> text. There will be at least another author version of this document befo=
re
> any call for adoption of the text.
>=20
> Regards
>=20
> Keith
>=20
>=20
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext

From magnus.westerlund@ericsson.com  Mon Mar 18 12:16:39 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040491F0C52 for ; Mon, 18 Mar 2013 12:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.774
X-Spam-Level: 
X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiEBf-EhPsYd for ; Mon, 18 Mar 2013 12:16:29 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA0421F9097 for ; Mon, 18 Mar 2013 12:15:31 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-00-514767d16ce0
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AE.31.19728.1D767415; Mon, 18 Mar 2013 20:15:30 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 18 Mar 2013 20:15:29 +0100
Message-ID: <514767D1.3000906@ericsson.com>
Date: Mon, 18 Mar 2013 20:15:29 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Dale R. Worley" 
References: <51425974.9070608@ericsson.com> <201303151431.r2FEVHJ9498642@shell01.TheWorld.com>
In-Reply-To: <201303151431.r2FEVHJ9498642@shell01.TheWorld.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RvdSunugQfdJJoupyx+zWLw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZUz+uZG5oFWqYmvLJ6YGxtMiXYycHBICJhJN 694zQdhiEhfurWfrYuTiEBI4yShx+dssZghnOaNEw6vVrCBVvALaEpMnbWMGsVkEVCX2757E CGKzCVhI3PzRyAZiiwoES/x8dYYFol5Q4uTMJ0A2B4eIgKZEx4IckDCzgLDEhfPHwRYLCzhJ fFhyA6xVSCBOYv6zCWDjOQXsJT6v7WKHOE5SYsuLdnaIXj2JKVdbGCFseYnmrbOZIXq1JRqa OlgnMArNQrJ5FpKWWUhaFjAyr2Jkz03MzEkvN9rECAzUg1t+q+5gvHNO5BCjNAeLkjhvuOuF ACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Ma+dp6W6LanXpEOHZ1X/O6sulWu5Drx6zPusy v7TguZ7wIeN6J2uTybMZ2FfNWHXp+75A7V95axrSF+i9YJWqbilUeWQ1m6XE/e+x+J+fNI8V 7T/1buXnL2y/1N/f/D1vTlZM9Z4nz7cd8NUuqPU+unPO2ok81/6ePueTWf7fMiH/TLRk3q7P V5VYijMSDbWYi4oTAfZpCdIiAgAA
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 19:16:39 -0000

Hi Dale,

You are correct that RTSP uses SDP with an different interpretation, the
interpretation that is common to usage in SAP, rather than the one in
O/A. I think you are correct that this should be pointed out, but
belongs in the introduction, rather than down in the definition,
although this appears to be the only section where it really matters.

I thus propose a more generic version of your text in the D. section:

   This appendix describes how an SDP file determines the operation of
   an RTSP session.  Thus, it is worth pointing out that the
   interpretation of the SDP is done in the context of the SDP receiver
   is the one being configured.  This is the same as in SAP [RFC2974],
   this differs from SDP Offer/Answer [RFC3264] where the SDP describes
   what the peer agent is ready to receive and willing to send.

Does this works for you?

Thanks

Magnus

On 2013-03-15 15:31, Dale R. Worley wrote:
>> From: Magnus Westerlund 
>>
>>    "a=recvonly" in a SDP provided to the RTSP client MUST
>>    indicate that media delivery will only occur in the direction from
>>    the RTSP server to the client.
> 
> I know little about RTSP though I've worked with SIP a lot.  I think
> you might want to flag this odd inconsistency between RTSP and SIP:
> 
> When SDP is used in offer-answer mode, the directionality attributes
> indicate directionality *from the point of view of the sender of the
> SDP*.  (RFC 3264 section 5.1) So a SIP offer containing "a=recvonly"
> indicates that the offerer expects to *receive* media.
> 
> When SDP is used in session-announcement mode, the directionality
> attributes indicate directionality *from the point of view of the
> receiver of the SDP*.  (This is not stated directly in RFC 4566,
> rather it says "a=recvonly: This specifies that the tools should be
> started in receive-only mode where applicable." but eventually you can
> track down that "the tools" means the receiver's device.)  So an RTSP
> announcement containing "a=recvonly" indicates that the announcer
> expects to *send* media.
> 
> This difference is not what I would have expected.  Initially, I
> assumed the text in your draft had gotten the directions reversed
> relative to reality.
> 
> You might want to mention this somewhere, e.g., after the first
> paragraph of D.1.5, add the paragraph
> 
>     (Note that RTSP uses SDP in session-announcement mode [RFC 4566],
>     in which the directionality attributes indicate the direction of
>     media flow from the point view of the interpreter of the SDP.
>     This contrasts with SDP in offer-answer mode [RFC 3264], in which
>     the directionality attributes indicate the direction of media flow
>     from the point of view of the generator of the SDP.)
> 
> Dale
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From harald@alvestrand.no  Mon Mar 18 14:05:41 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4189321F9000 for ; Mon, 18 Mar 2013 14:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.398
X-Spam-Level: 
X-Spam-Status: No, score=-109.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 DkpXXp0doHRE for ; Mon, 18 Mar 2013 14:05:40 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2B821F9081 for ; Mon, 18 Mar 2013 14:05:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D4DC39E1C9; Mon, 18 Mar 2013 22:05:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILvn2qKex5lv; Mon, 18 Mar 2013 22:05:37 +0100 (CET)
Received: from [172.30.42.70] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D555C39E1C4; Mon, 18 Mar 2013 22:05:37 +0100 (CET)
Message-ID: <514781A1.8030904@alvestrand.no>
Date: Mon, 18 Mar 2013 22:05:37 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Justin Uberti 
References:  <5145786F.8060507@alvestrand.no>  <5146BD66.9090506@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000101040002090609030600"
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Mar 2013 21:05:41 -0000

This is a multi-part message in MIME format.
--------------000101040002090609030600
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/18/2013 04:59 PM, Justin Uberti wrote:
> You're looking at the handling of a=mid, not a=group.
>
> Section 9.2 indicates the handling of a=group, which seems to indicate 
> a subset is allowed:
>
>     A SIP entity that receives an offer that contains an "a=group" line
>     with semantics that are understood MUST return an answer that
>     contains an "a=group" line with the same semantics.  The
>     identification-tags contained in this "a=group" line MUST be the same
>     as those received in the offer, or a subset of them (zero
>     identification-tags is a valid subset).  When the identification-tags
>     in the answer are a subset, the "group" value to be used in the
>     session MUST be the one present in the answer.

Aha, I misinterpreted the phrase "BUNDLE mids in the answer doesn't match".

This is, in some sense, a subset of the question "is unbundling 
possible". I don't have a strong opinion on this.


>
>
>
> On Mon, Mar 18, 2013 at 12:08 AM, Harald Alvestrand 
> > wrote:
>
>     On 03/18/2013 04:19 AM, Justin Uberti wrote:
>>
>>
>>>          1. If the BUNDLE mids in the answer doesn't match the
>>>             BUNDLE mids in the offer, what happens? (assume fail)
>>>
>>         I think this violates RFC 5888 section 9.1, so it should be a
>>         FAIL.
>>
>>
>>     According to 9.2, the only restriction is the answer mids must be
>>     a subset of the offer, so we would have to specify an exact match
>>     directly. But I think we do want to impose this restriction, or
>>     else we can't BUNDLE a new m-line until we know the other side
>>     wants to BUNDLE it as well.
>
>     The important phrase from 9.1 is
>
>        If a media stream that contained a particular "mid" identifier
>     in the
>        offer contains a different identifier in the answer, the
>     application
>        ignores all of the "mid" and "group" lines that might appear in the
>        session description.  The following example illustrates this
>        scenario.
>
>     So if there's any mismatch, we don't get BUNDLE negotiated.
>     Negotiation might not fail, but we don't get BUNDLE (or any other
>     form of grouping).
>
>
>


--------------000101040002090609030600
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 03/18/2013 04:59 PM, Justin Uberti
      wrote:

    

    

      
You're looking at the handling of a=mid, not
        a=group.
        


        

        
Section 9.2 indicates the handling of a=group, which seems
          to indicate a subset is allowed:

        


        

        

          
   A SIP entity that receives an offer that contains an "a=group" line
   with semantics that are understood MUST return an answer that
   contains an "a=group" line with the same semantics.  The
   identification-tags contained in this "a=group" line MUST be the same
   as those received in the offer, or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in the
   session MUST be the one present in the answer.

        

      

    

    

    Aha, I misinterpreted the phrase "BUNDLE mids in the answer doesn't
    match".

    

    This is, in some sense, a subset of the question "is unbundling
    possible". I don't have a strong opinion on this.

    

    

    

      

        

          

        

        


        

      

      


        

        
On Mon, Mar 18, 2013 at 12:08 AM,
          Harald Alvestrand <harald@alvestrand.no> wrote:

          

            

              

                
On 03/18/2013 04:19 AM, Justin Uberti wrote:

                

                

                  


                    

                      

                        

                          

                            


                              

                                

                                  

                                    
    
                                      
  1.  If the BUNDLE mids in the
                                        answer doesn't match the BUNDLE
                                        mids in the offer, what happens?
                                        (assume fail)
    2. 
                                    

                                  

                                

                              

                            

                            I think this violates RFC 5888 section 9.1,
                            so it should be a FAIL.

                        

                        


                        

                        
According to 9.2, the only restriction is
                          the answer mids must be a subset of the offer,
                          so we would have to specify an exact match
                          directly. But I think we do want to impose
                          this restriction, or else we can't BUNDLE a
                          new m-line until we know the other side wants
                          to BUNDLE it as well.

                      

                    

                  

                

                

              

              The important phrase from 9.1 is

              

                 If a media stream that contained a particular "mid"
              identifier in the

                 offer contains a different identifier in the answer,
              the application

                 ignores all of the "mid" and "group" lines that might
              appear in the

                 session description.  The following example illustrates
              this

                 scenario.

              

              So if there's any mismatch, we don't get BUNDLE
              negotiated. Negotiation might not fail, but we don't get
              BUNDLE (or any other form of grouping).

              

              

            

          

        

        

      

    

    

  


--------------000101040002090609030600--

From juberti@google.com  Mon Mar 18 17:17:44 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A791E21F8B48 for ; Mon, 18 Mar 2013 17:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.777
X-Spam-Level: 
X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 IRIORwRdLRFF for ; Mon, 18 Mar 2013 17:17:44 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBA321F85EE for ; Mon, 18 Mar 2013 17:17:43 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id x14so27983ief.35 for ; Mon, 18 Mar 2013 17:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=D535PrjJ7Ml+Vh+D0Qlff8w4MdQBlDhRCDQZ8ilgKoc=; b=OXUFcLWRN2VdqgkfWXKtQVsSj5X4dpwEf/O1M10o7q09p5/4mh6ZvKvoY/DmpfwIcw XVGGdFhhopmsYzRott1f4k2g2LSbGym1F2+4X7LR7sLQMOLxo4tCLJXJBPohMAxOJsz1 /Ah7ifVdywAKmHAJwWUq1XscNHjHj5uqYLiYwKGTs6EdVf5QJ0hVV4rpzHnjXe2u8ZiV TQD58vzSjevi3lOZZl2OvbQRxZ0q1CSD3AFe8cqQqfrM3WirIWQU2WwAvtTKy8U61LCP mji3U5xl6Fe4DoyUdFl9zkWSst8eiVLVxMRRbMmvU2kW7BzrptokT+5oTQ9Ohxpo6VLZ Z4bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=D535PrjJ7Ml+Vh+D0Qlff8w4MdQBlDhRCDQZ8ilgKoc=; b=oDrunRePT7jWmlTmXg6Vwc+Q2a+jf+MJj6x0pNDaSaQ4dLmAmqrDFGIkMVtOUf5hKQ rpxQ9DBSSJ98snybE7U/CcrbUpQsq1J3vy+keudkWj8q4h8PGgK5buRO/TmZGcIehUap 5hr91bBl+XUYMHuAjzwOToopRPd4he4yyPY+zTg3Ims+K2ntAHaB2+WZkgG/5mB3znD2 QYSKnWAYrjy4E/p3XWcS9ksfdcqtBU9c74pHzO85Adz1leXnPn0wxhqwdEuPfbDSuzwJ iMGaENAp5tzeYelOWf/rMAc29MPAae8R9iFhOJXx5qvGeUI4aUPVPREHztgCH8HQjJo7 2fIw==
X-Received: by 10.50.13.71 with SMTP id f7mr455039igc.32.1363652263519; Mon, 18 Mar 2013 17:17:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.250.18 with HTTP; Mon, 18 Mar 2013 17:17:23 -0700 (PDT)
In-Reply-To: <514781A1.8030904@alvestrand.no>
References:  <5145786F.8060507@alvestrand.no>  <5146BD66.9090506@alvestrand.no>  <514781A1.8030904@alvestrand.no>
From: Justin Uberti 
Date: Mon, 18 Mar 2013 17:17:23 -0700
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=089e013c66d2c3e26c04d83c08de
X-Gm-Message-State: ALoCoQkDVtM2PtnyoQG7uFXsagk0RmhWxoyAKrZv9Vy/8BvRPZacL045xIkv7LURyTfm66hz4msEYYyGQnopIF8ip2sChC87R603smjxE90syOYisek8YCpVQ/smhcG6/V90PJtoEhJTxtyJE7V9in8LwQHxxy1RkKfr1QoeIkirOG4SRj6xokY6Kp1emq6h2tejvNFk37el
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 00:17:44 -0000

--089e013c66d2c3e26c04d83c08de
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 18, 2013 at 2:05 PM, Harald Alvestrand wrote:

>  On 03/18/2013 04:59 PM, Justin Uberti wrote:
>
> You're looking at the handling of a=mid, not a=group.
>
>  Section 9.2 indicates the handling of a=group, which seems to indicate a
> subset is allowed:
>
>     A SIP entity that receives an offer that contains an "a=group" line
>    with semantics that are understood MUST return an answer that
>    contains an "a=group" line with the same semantics.  The
>    identification-tags contained in this "a=group" line MUST be the same
>    as those received in the offer, or a subset of them (zero
>    identification-tags is a valid subset).  When the identification-tags
>    in the answer are a subset, the "group" value to be used in the
>    session MUST be the one present in the answer.
>
>
> Aha, I misinterpreted the phrase "BUNDLE mids in the answer doesn't match".
>
> This is, in some sense, a subset of the question "is unbundling possible".
> I don't have a strong opinion on this.
>
> The key issue here is whether the remote side can reject a BUNDLE. IOW, if
caller has A and B bundled, and adds m= line C (BUNDLEd), does the caller
need to allocate a new port, so that it can handle the case where the
callee decides only A and B should be BUNDLEd? Or can the caller offer C on
the existing A+B BUNDLEd port?

I think life would be simpler if we enforced the rule that the callee could
only accept C as BUNDLEd, or reject C entirely. IOW, any difference in the
a=group answer (other than removal of rejected mids) is fatal.

--089e013c66d2c3e26c04d83c08de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Mon, Mar 18, 2013 at 2:05 PM, Harald Alvestrand <harald@alve=
strand.no> wrote:




 =20
   =20
 =20
  

    
On 03/18/2013 04:59 PM, Justin Uberti
      wrote:

    

    

      
You're looking at the handling of a=3Dmid, not
        a=3Dgroup.
        


        

        
Section 9.2 indicates the handling of a=3Dgroup, which seems
          to indicate a subset is allowed:

        


        

        

          
   =
A SIP entity that receives an offer that contains an "a=3Dgroup" =
line
   with semantics that are understood MUST return an answer that
   contains an "a=3Dgroup" line with the same semantics.  The
   identification-tags contained in this "a=3Dgroup" line MUST be=
 the same
   as those received in the offer, or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in th=
e
   session MUST be the one present in the answer.

        

      

    

    

    Aha, I misinterpreted the phrase "BUNDLE mids in the answer doesn&=
#39;t
    match".

    

    This is, in some sense, a subset of the question "is unbundling
    possible". I don't have a strong opinion on this.

The key issue here is whether =
the remote side can reject a BUNDLE. IOW, if caller has A and B bundled, an=
d adds m=3D line C (BUNDLEd), does the caller need to allocate a new port, =
so that it can handle the case where the callee decides only A and B should=
 be BUNDLEd? Or can the caller offer C on the existing A+B BUNDLEd port?


I think life would be simpler if we enforced the rule =
that the callee could only accept C as BUNDLEd, or reject C entirely. IOW, =
any difference in the a=3Dgroup answer (other than removal of rejected mids=
) is fatal.





--089e013c66d2c3e26c04d83c08de--

From mzanaty@cisco.com  Mon Mar 18 21:19:09 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C84421F856E; Mon, 18 Mar 2013 21:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 I1-TlMHC9BCg; Mon, 18 Mar 2013 21:19:07 -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 7BF4821F855A; Mon, 18 Mar 2013 21:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5853; q=dns/txt; s=iport; t=1363666747; x=1364876347; h=from:to:subject:date:message-id:mime-version; bh=m3S1vU7QO9mraHl+fuS23/CnhSAni1VntemfZ+wo9zw=; b=L4Wd7OzyngHSwjqbbuol5QCh01Wa6YLo2WDxL/VNSwLDSBAC/FWyPdLh r3PFRHh8w0CLtvupKl2Znr6OFn2L4Fj+nTMGFGRfua461xz/VJ5XQjOYr L/RsUVcadVMqtHcNb3ZvzGX+r/6LJMtc0UTsJh8du3PKLGArByCLbbCIf I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADXmR1GtJXG+/2dsb2JhbABDhCS+M4JugWMWdIImAQQnBl4BKlYmAQQBGogMsjKQEokDhVyDF2EDp2CCfQ2CKA
X-IronPort-AV: E=Sophos;i="4.84,870,1355097600";  d="scan'208,217";a="188937431"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 19 Mar 2013 04:19:06 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2J4J6fY023184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 04:19:06 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 23:19:06 -0500
From: "Mo Zanaty (mzanaty)" 
To: "mmusic@ietf.org" , "rtcweb@ietf.org" 
Thread-Topic: Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQ==
Date: Tue, 19 Mar 2013 04:19:06 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.248.224]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F6942C3xmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 04:19:09 -0000

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F6942C3xmbrcdx14ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Does bundle imply anything beyond a simple port override of the m-line port=
? If not, then why not just directly signal the port override in an attribu=
te without any grouping semantics?

Offer to mux audio and video on the same port:
m=3Daudio 10000 RTP/AVP 0
m=3Dvideo 10002 RTP/AVP 31
a=3Dport 10000
i=3DI really want 10000, but lied on the m-line for fear of confusing you. =
Confused yet?

Answer supports the port override attribute and agrees to mux audio and vid=
eo:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40000 RTP/AVP 31
a=3Dport 40000
...so audio and video ports are 10000<->40000.

Answer supports the port override attribute but doesn't want to demux on hi=
s end:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40002 RTP/AVP 31
a=3Dport 40002
...so audio ports are 10000<->40000 and video ports are 10000<->40002.

Answer doesn't support the port override attribute, or doesn't want either =
end to mux:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40002 RTP/AVP 31
...so audio ports are 10000<->40000 and video ports are 10002<->40002.

Either end can re-offer without lies about ports on the m-line after confir=
ming the peer is not confused by muxing, if they want to avoid confusing in=
termediaries.

Has this approach been tried yet? Dismissed?

Mo


--_000_3879D71E758A7E4AA99A35DD8D41D3D90F6942C3xmbrcdx14ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Does bundle imply anything beyond a simple port over=
ride of the m-line port? If not, then why not just directly signal the port=
 override in an attribute without any grouping semantics?


 


Offer to mux audio and video on the same port:<=
/o:p>


m=3Daudio 10000 RTP/AVP 0


m=3Dvideo 10002 RTP/AVP 31


a=3Dport 10000


i=3DI really want 10000, but lied on the m-line for =
fear of confusing you. Confused yet?


 


Answer supports the port override attribute and agre=
es to mux audio and video:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40000 RTP/AVP 31


a=3Dport 40000


…so audio and video ports are 10000<->40=
000.


 


Answer supports the port override attribute but does=
n’t want to demux on his end:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40002 RTP/AVP 31


a=3Dport 40002


…so audio ports are 10000<->40000 and vi=
deo ports are 10000<->40002.


 


Answer doesn’t support the port override attri=
bute, or doesn’t want either end to mux:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40002 RTP/AVP 31


…so audio ports are 10000<->40000 and vi=
deo ports are 10002<->40002.


 


Either end can re-offer without lies about ports on =
the m-line after confirming the peer is not confused by muxing, if they wan=
t to avoid confusing intermediaries.


 


Has this approach been tried yet? Dismissed?


 


Mo


 






--_000_3879D71E758A7E4AA99A35DD8D41D3D90F6942C3xmbrcdx14ciscoc_--

From prvs=47904a88b6=aallen@blackberry.com  Mon Mar 18 18:04:07 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F121F856E for ; Mon, 18 Mar 2013 18:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.849
X-Spam-Level: 
X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 XsIS71x9cbhT for ; Mon, 18 Mar 2013 18:04:05 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB021F84CC for ; Mon, 18 Mar 2013 18:04:04 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-4b-5147b9772423
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id FF.5E.09265.779B7415; Mon, 18 Mar 2013 20:03:52 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Mon, 18 Mar 2013 20:03:50 -0500
From: Andrew Allen 
To: "fandreas@cisco.com" , "Simo.Veikkolainen@nokia.com" 
Thread-Topic: [MMUSIC] RE : I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOI52wgVCmbJ7LhEeP+nfIOrusspisM/+q
Date: Tue, 19 Mar 2013 01:03:50 +0000
Message-ID: 
In-Reply-To: <514690F2.700@cisco.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D2D92FXMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBKsWRmVeSWpSXmKPExsXC5ZyvpVux0z3Q4O0sFov3F3Qt9i8+z2wx dfljFovDb5+yW5z7dJfFgdVjyu+NrB5Llvxk8rh76xKTR8uzk2webc/usAewRjUw2iQllpQF Z6bn6dvZJObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm5qYWKSlkptgqmSgp FOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0tdQyU73YRO nozeRf3sBVtms1SsXXuJpYFxSy9LFyMHh4SAicSRX1ldjJxAppjEhXvr2boYuTiEBFYySixY 08UK4WxmlOi/tpIFpIpNQEti/+HpTCC2iECOxN2WXYwgRcwCUxklZq47ywqSEBaIkPi34T4z yAYRgUiJPddLIeqNJN696WcGsVkEVCUe354OZvMKeEg07vkH1soJFD9y7BwbiM0oICux++x1 sF3MAuISt57MZ4K4VEBiyZ7zzBC2qMTLxxC9EgKKEn/3fmeFqM+XaJ0+E2q+oMTJmU9YJjCK zEIyahaSsllIymYBXc0soCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzEK5mYUG5gZJOcl 6xVl5urlpZZsYgSlHkcN/R2Mb99bHGIU4GBU4uHNWO0eKMSaWFZcmXuIUYKDWUmEN9gfKMSb klhZlVqUH19UmpNafIgxCBhAE5mluJPzgWkxryTe2MCASI6SOG+ZplOgkEA6MJFlp6YWpBbB DGXi4ARZyiUlUgxMR6lFiaUlGfGgpBlfDEybUg2MO2v/hsyx+KwyPfXvwr/T1f5Pr1WIrRX9 fvTJlRuTM/R9GiWWztZ8eo8/x7f71c2cO8dC5+4wsLLi2RB+c/vpOf5573L0Kzg9Ps46t/bi 1xWVer9YRYOaloXLzbi5TFlxNVPtrKOaYUWFiq9fR8ybefk23/P9bll6OW47NVevu347UY1B qC7WV4mlOCPRUIu5qDgRAB0IwO+LAwAA
X-Mailman-Approved-At: Mon, 18 Mar 2013 22:45:41 -0700
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 01:04:07 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2D92FXMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpGbGVtbWluZw0KDQpXaGF0IGlzIHRoZSBwcm9wb3NlZCB3YXkgZm9yd2FyZCBub3c/DQoN
CkRvZXMgdGhpcyBoYXZlIHRvIGdvIGJhY2sgdG8gdGhlIFdHIGFuZCByZWRvIFdHTEMgb3Ig
aXMgdGhpcyBzb21ldGhpbmcgdGhhdCBjYW4gYmUgcmVzb2x2ZWQgd2l0aG91dCB0aGF0Pw0K
DQpJTUhPIGl0cyBhIG1hdHRlciBvZiBnZXR0aW5nIHRoZSB3b3JkaW5nIHJpZ2h0LiBJIGRv
bid0IHNlZSBhIHByb2JsZW0gd2l0aCBjb250aW51aW5nIHRvIHVzZSBDQ0FQIGZvciB0aGlz
IGFuZCBoYXZpbmcgdGV4dCB0aGF0IHB1dHMgYSBwcm9oaWJpdGlvbiBvbiB1c2luZyB0aGlz
IHRvIG5lZ290aWF0ZSBhbHRlcm5hdGUgSU4gdHlwZXMgYmVjYXVzZSB0aGlzIHdvdWxkIGR1
cGxpY2F0ZSB0aGF0IGNhcGFiaWxpdHkgYWxyZWFkeSBwcm92aWRlZCBieSBJQ0UuDQoNCkFu
ZHJldw0KDQoNCkZyb206IEZsZW1taW5nIEFuZHJlYXNlbiBbbWFpbHRvOmZhbmRyZWFzQGNp
c2NvLmNvbV0NClNlbnQ6IFN1bmRheSwgTWFyY2ggMTcsIDIwMTMgMTA6NTggUE0gQ2VudHJh
bCBTdGFuZGFyZCBUaW1lDQpUbzogU2ltby5WZWlra29sYWluZW5Abm9raWEuY29tIDxTaW1v
LlZlaWtrb2xhaW5lbkBub2tpYS5jb20+DQpDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEFuZHJldyBBbGxlbjsgam9u
YXRoYW5AdmlkeW8uY29tIDxqb25hdGhhbkB2aWR5by5jb20+OyBtbXVzaWNAaWV0Zi5vcmcg
PG1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBSRSA6IEktRCBBY3Rp
b246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMtMDQudHh0DQoN
CkFzIG5vdGVkIGluIG15IGUtbWFpbCBiZWxvdywgdGhlIEFuYWhlaW0gZGlzY3Vzc2lvbiB3
YXMgYmFzZWQgb24gdGhlIG9yaWdpbmFsIGRyYWZ0LWdhcmNpYS1tbXVzaWMtc2RwLW1pc2Mt
Y2FwPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhcmNpYS1tbXVzaWMtc2Rw
LW1pc2MtY2FwPiBkb2N1bWVudCwgd2hpY2ggZGlkIGluZGVlZCBwb3NpdGlvbiAiY2NhcCIg
YXMgYW4gYWx0ZXJuYXRpdmUgdG8gSUNFLiBUaGUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtZ2FyY2lhLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzIHdoaWNoIHdh
cyBhZG9wdGVkIGJ5IHRoZSBXRyBjaGFuZ2VkIHRoZSB3b3JkaW5nIHRvIHdoYXQgaXMgYmVp
bmcgZGlzY3Vzc2VkIG5vdyBhbmQgd2FzIGFkb3B0ZWQgYnkgdGhlIFdHLg0KDQpJZiBwZW9w
bGUgd2FudGVkIHRvIGV4cGxpY2l0bHkgcHJldmVudCB0aGlzIG1lY2hhbmlzbSBmcm9tIGJl
aW5nIHVzZWQgZm9yIElQNCBhbmQvb3IgSVA2IGFkZHJlc3NlcywgdGhlbiBJIm0gYXQgYSBs
b3NzIHRvIHVuZGVyc3RhbmQgd2h5IHRoZSBjdXJyZW50IHdvcmRpbmcgd2FzIGNob3NlbiBh
bmQgYWdyZWVkIHRvIGFzIHdlbGwgYXMgdG8gd2h5IGEgZ2VuZXJhbCBtZWNoYW5pc20gbGlr
ZSAiY29ubmVjdGlvbiBkYXRhIGNhcGFiaWxpdHkiIGFzIHBhcnQgb2YgdGhlIG92ZXJhbGwg
Y2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBmcmFtZXdvcmsgd2FzIGNob3NlbiBhbmQgYWdyZWVk
IHRvLiBIb3dldmVyLCBpbiBzcGl0ZSBvZiB0aGUgZG9jdW1lbnQgcmV2aWV3cywgbG9uZyBj
b21wbGV0ZWQgV0dMQywgYW5kIHRoZSBleHRlcm5hbCAzR1BQIGRlcGVuZGVuY3ksIGl0IGlz
IG9idmlvdXMgZnJvbSB0aGUgZS1tYWlsIHRocmVhZCB0aGF0IG1vcmUgZGlzY3Vzc2lvbiBp
cyBuZWVkZWQgb24gdGhpcywgYW5kIGhlbmNlIHdlIHdpbGwgaGF2ZSB0byBkZWFsIHdpdGgg
dGhhdCBiZWZvcmUgd2UgY2FuIHByb2dyZXNzIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzDQoN
Ci0tIEZsZW1taW5nIChNTVVTSUMgY28tY2hhaXIpDQoNCg0KT24gMy8xNS8xMyA4OjA0IEFN
LCBTaW1vLlZlaWtrb2xhaW5lbkBub2tpYS5jb208bWFpbHRvOlNpbW8uVmVpa2tvbGFpbmVu
QG5va2lhLmNvbT4gd3JvdGU6DQpJIHRoaW5rIHRoaXMgZ29lcyBhbGwgdGhlIHdheSBiYWNr
IHRvIElFVEY2OCwgd2hlcmUgYW4gYWdyZWVtZW50IHdhcyBtYWRlIHRvIHVzZSBJQ0UgZm9y
IGZ1dHVyZSBhZGRyZXNzIHR5cGUgc2VsZWN0aW9uIChkZXByZWNhdGluZyBBTkFUKS4NCg0K
SSBjb3VsZG7igJl0IGZpbmQgYSB3cml0dGVuIHN0YXRlbWVudCBpbiBtaW51dGVzIG9uIGNj
YXAgYmVpbmcgZXhwbGljaXRseSBmb3JiaWRkZW4gdG8gZXhwcmVzcyBJUDQgYW5kL29yIElQ
NiBhZGRyZXNzZXMgYXMgYWx0ZXJuYXRpdmVzIOKAkyBidXQgbXkgdGhvdWdodCBoYXMgYmVl
biB0aGF0IGFsdGVybmF0aXZlIElQIGFkZHJlc3NlcyBtYXkgb25seSBiZSBvZmZlcmVkIHdp
dGggSUNFLiBUaGlzIHdhcyBhbHNvIHJlZmxlY3RlZCBpbiBieSBKZWFuLUZyYW5jb2lzICho
dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNn
MDc5MTYuaHRtbCkgd2hlcmUgaGUgc2F5cyDigJ0gQXMgZm9yIHByb3Bvc2luZyBJUHY0L0lQ
djYgYWx0ZXJuYXRpdmVzLCBJQ0UgZGVwcmVjYXRlcyBBTkFUIGFuZCBpcyB0aGUgcHJlZmVy
cmVkIHNvbHV0aW9uIHRoZSBXRyBoYXMgY2hvc2VuIHNvIGZhciBwZXIgSUVURiM2OC4g4oCc
DQoNClNpbW8NCg0KDQpGcm9tOiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11
c2ljLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBleHQgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86
bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNlbnQ6IDE1LiBtYWFsaXNrdXV0YSAy
MDEzIDg6MzYNClRvOiBGbGVtbWluZyBBbmRyZWFzZW47IEFuZHJldyBBbGxlbg0KQ2M6IGpv
bmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPjsgbW11c2ljQGll
dGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10g
UkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1j
YXBzLTA0LnR4dA0KDQpGZWxtbWluZywNCg0KSWYgeW91IGFyZSBsb29raW5nIGZvciBzb21l
dGhpbmcgd3JpdHRlbiwgeW91IGNhbiByZWFkIHRoZSBtaW51dGVzIGluIHRoZSBBbmFoZWlt
IG1lZXRpbmcgKEluIGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9tbXVzaWMvbWludXRlcz9p
dGVtPW1pbnV0ZXM3Ny5odG1sKSwgeW91IGNhbiByZWFkIHRoZSBmb2xsb3dpbmc6DQoNCiAg
ICAgICAgICAgICAgVG8gY29uY2x1ZGUgdGhlIFdHIGNoYWlyIHJlcG9ydCwgSmVhbi1GcmFu
Y29pcyBjbGFyaWZpZWQgdGhlDQoNCiAgICAgICAgICAgICAgc3RhdHVzIG9mIGRyYWZ0LWll
dGYtbW11c2ljLXNkcC1taXNjLWNhcC0wMDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbD9y
ZXBvc2l0b3J5PWh0dHA6Ly90b29scy5pZXRmLm9yZyZkcmFmdD1kcmFmdC1pZXRmLW1tdXNp
Yy1zZHAtbWlzYy1jYXAtMDA+IChzZWUgdGhlIGNoYWlyJ3MNCg0KICAgICAgICAgICAgICBz
bGlkZXMgIzkpLg0KDQogICAgICAgICAgICAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2FzIG1p
c3Rha2VubHkgYWNjZXB0ZWQgYXMgYSBXRyBkb2N1bWVudA0KDQogICAgICAgICAgICAgIHdp
dGhvdXQgY29uZmlybWF0aW9uIG9uIHRoZSBsaXN0Lg0KDQoNCg0KICAgICAgICAgICAgICBB
ZnRlciBhIGJyaWVmIHJlY2FwIG9mIHRoZSBJLUQgaGlzdG9yeSBhbmQgc2NvcGUsIHNldmVy
YWwNCg0KICAgICAgICAgICAgICBjb21tZW50cyB3ZXJlIG1hZGUgaW4gc3VwcG9ydCBvZiBj
b250aW51aW5nIHRoZSB3b3JrIGFzIHBhcnQgb2YNCg0KICAgICAgICAgICAgICBhIFdHIGl0
ZW0gYXMgbG9uZyBhcyB0aGUgc2NvcGUgZG9lcyBub3Qgb3ZlcmxhcCB3aXRoIElDRSBmb3IN
Cg0KICAgICAgICAgICAgICBJUHY0LUlQdjYgY29ubmVjdGlvbiBhZGRyZXNzIG5lZ290aWF0
aW9uczoNCg0KICAgICAgICAgICAgICAgIC0gUm9uaSBFdmVuIGluZGljYXRlZCBzdXBwb3J0
IGZvciB0aGUgd29yayBhbmQgbm90ZWQgdGhhdCB0aGUNCg0KICAgICAgICAgICAgICAgICAg
YiBwYXJhbWV0ZXIgd2FzIHBhcnQgb2YgdGhlIG9yaWdpbmFsIFNEUCBjYXBhYmlsaXR5DQoN
CiAgICAgICAgICAgICAgICAgIG5lZ290aWF0aW9uIGZyYW1ld29yay4NCg0KICAgICAgICAg
ICAgICAgIC0gSm9obiBFbHdlbGwsIEdvbnphbG8gQ2FtYXJpbGxvLCBKb25hdGhhbiBMZW5u
b3ggYW5kIEN1bGxlbg0KDQogICAgICAgICAgICAgICAgICBKZW5uaW5ncyBhcmUgaW4gZmF2
b3Igb2YgdGhlIHdvcmsgaXRlbSBhcyBsb25nIGFzIGl0cyBzY29wZQ0KDQogICAgICAgICAg
ICAgICAgICBpcyBjbGFyaWZpZWQgdG8gbm90IG92ZXJsYXAgd2l0aCBJQ0UgZm9yIElQdjQt
SVB2NiBhZGRyZXNzDQoNCiAgICAgICAgICAgICAgICAgIG5lZ290aWF0aW9uLg0KDQogICAg
ICAgICAgICAgICAgLSBJbmdlbWFyIEpvaGFuc3NvbiBhbHNvIGV4cHJlc3NlZCBzdXBwb3J0
IGZvciBpdA0KDQogICAgICAgICAgICAgICBUaGVyZSB3YXMgc3Ryb25nIHN1cHBvcnQgZm9y
IGNvbnRpbnVpbmcgdG8gZGVmaW5lIGEgY2FwYWJpbGl0eQ0KDQogICAgICAgICAgICAgICBw
YXJhbWV0ZXIgZm9yIGIsIGkgYW5kIHNvbWUgY29uY2VybnMgd2l0aCB0aGUgY2NhcCBwYXJh
bWV0ZXIuDQoNCiAgICAgICAgICAgICAgIE1vcmUgZGlzY3Vzc2lvbnMgb2NjdXJyZWQgYXQg
dGhlIGVuZCBvZiB0aGUgbWVldGluZyB3aGVuIHRoZQ0KDQogICAgICAgICAgICAgICBkb2N1
bWVudCB3YXMgcHJlc2VudGVkLCBzZWUgbm90ZXMgYmVsb3cuDQoNCg0KDQogICAgICAgICAg
ICAgICBKZWFuLUZyYW5jb2lzIHByb3Bvc2VkIHRoZSBuZXh0IHN0ZXBzOg0KDQogICAgICAg
ICAgICAgICAgLSB0aGUgV0cgY2hhaXJzIHdpbGwgY29uZmlybSB0aGUgaW50ZXJlc3QgZm9y
IGEgV0cgaXRlbSB0bw0KDQogICAgICAgICAgICAgICAgICBkZWZpbmUgYWRkaXRpb25hbCBT
RFAgY2FwIG5lZyBwYXJhbWV0ZXJzIChiIGFuZCBpIGxpbmVzKQ0KDQogICAgICAgICAgICAg
ICAgLSBQZW5kaW5nIEFEIGFwcHJvdmFsLCB0aGUgV0cgaXRlbSB3aWxsIGJlIGNoYXJ0ZXJl
ZA0KDQogICAgICAgICAgICAgICAgLSBTaW1vIFYuIHdpbGwgcmUtc3VibWl0IGFuIHVwZGF0
ZWQgSW50ZXJuZXQtRHJhZnQgYXMgYW4NCg0KICAgICAgICAgICAgICAgICAgaW5kaXZpZHVh
bCBzdWJtaXNzaW9uDQoNCiAgICAgICAgICAgICAgICAtIHRoZW4gdGhlIGNoYWlycyB3aWxs
IGFzayB0aGUgbGlzdCBpZiB0aGUgV29ya2luZyBHcm91cA0KDQogICAgICAgICAgICAgICAg
ICBzdXBwb3J0cyBtYWtpbmcgU2ltbydzIGluZGl2aWR1YWwgc3VibWlzc2lvbiBhcyB0aGUg
V0cNCg0KICAgICAgICAgICAgICAgICAgZHJhZnQuDQoNClRoZSBjdXJyZW50IGRpc2N1c3Np
b24gc2hvd3MgdGhlcmUgaXMgYSBjb25mdXNpb24gaW4gdGhlIGN1cnJlbnQgdGV4dCBhbmQg
aXQgaXMgd29ydGggdG8gYmUgY2xhcmlmaWVkLg0KDQpDaGVlcnMsDQoNCk1lZA0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUgOiBtbXVzaWMtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bW11c2ljLWJv
dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgRmxlbW1pbmcgQW5kcmVhc2VuDQpFbnZv
ecOpIDogamV1ZGkgMTQgbWFycyAyMDEzIDIxOjM5DQrDgCA6IEFuZHJldyBBbGxlbg0KQ2Mg
OiBqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT47IG1tdXNp
Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW01NVVNJ
Q10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91
cy1jYXBzLTA0LnR4dA0KDQpPbiAzLzE0LzEzIDM6NTAgUE0sIEFuZHJldyBBbGxlbiB3cm90
ZToNCg0KSSBhbSBub3Qgc3VyZSBpZiBhbnl0aGluZyBpcyByZWNvcmRlZCBpbiBhbnkgbWlu
dXRlcyBidXQgd2UgaGFkIGFuIG9mZmxpbmUgZGlzY3Vzc2lvbiB0byByZW1vdmUgdGhlIHJv
YWRibG9jayBvbiB0aGlzIHdpdGggSm9uYXRoYW4gdG8gYWRkcmVzcyBoaXMgY29uY2VybiB0
aGF0IHRoaXMgd2FzIGEgcG90ZW50aWFsIGFsdGVybmF0aXZlIHRvIElDRSBhbmQgYWRkcmVz
c2VkIHRoaXMgd2l0aCB0aGUgY3VycmVudCB0ZXh0LiBUaGlzIHRleHQgYW5kIHRoZSByZWFz
b24gYmVoaW5kIGl0IEkgdGhpbmsgd2FzIHBvaW50ZWQgb3V0IG9uIHRoZSBsaXN0IGR1cmlu
ZyBRdWViZWMgb3Igc2hvcnRseSBhZnRlci4NCkNhbiB5b3UgZmluZCB0aGUgbWVzc2FnZSBv
ciByZWNhbGwgd2hvIHNlbnQgaXQgPw0KDQpBbHNvLCB0aGUgUXVlYmVjIG1lZXRpbmcgd2Fz
IGluIEp1bHkgMjAxMS4gVHJhY2luZyBiYWNrIHdlIGhhdmU6DQoNCmEpIFRoZSBpbml0aWFs
ICg/KSBpbmRpdmlkdWwgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0ICgyMDA4LzIwMDkpOiAgICAg
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FyY2lhLW1tdXNpYy1zZHAtbWlz
Yy1jYXANCmIpIEFub3RoZXIgaW5kaXZpZHVhbCB0YWtlIG9uIHRoZSBkcmFmdCAoQXVndXN0
IDIwMTErKTogICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nYXJj
aWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMNCmMpIFRoZSBpbnRpYWwgV0cgdmVy
c2lvbiBvZiB0aGUgZHJhZnQgKE1hcmNoIDIwMTIrKTogICAgICAgICAgICAgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMt
Y2Fwcw0KDQpUaGUgImEpIiB2ZXJzaW9uIGRpZCBpbmRlZWQgcG9zaXRpb24gdGhlIGRyYWZ0
IGFzIGFuIGFsdGVybmF0aXZlIHRvIElDRSwgaG93ZXZlciBhbGwgImIpIiBhbmQgImMpIiB2
ZXJzaW9ucyBjaGFuZ2VkIHRoaXMgYXMgcGVyIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uLg0K
DQpJJ20gc3RpbGwgbG9va2luZyBmb3IgYW55dGhpbmcgd3JpdHRlbiBhbnl3aGVyZSB0aGF0
IHN1Z2dlc3RzIHRoYXQgdGhlIHRleHQgaW4gImIpIiBhbmQgImMpIiBkb2VzIG5vdCByZXBy
ZXNlbnQgY29uc2Vuc3VzIGFuZC9vciB0aGF0IGNvbnNlbnN1cyBpcyB0aGF0IHRoZSBtZWNo
YW5pc20gTVVTVCBhbHdheXMgYmUgcHJvaGliaXRlZCBmcm9tIG5lZ290aWF0aW5nIElQNC9J
UDYgYWRkcmVzc2VzIChhcyBvcHBvc2VkIHRvIGp1c3Qgd2hlbiBJQ0UgaXMgbm90IGF2YWls
YWJsZSkuDQoNClRoYW5rcw0KDQotLSBGbGVtbWluZw0KDQoNCg0KRnJvbTogRmxlbW1pbmcg
QW5kcmVhc2VuIFttYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tXQ0KU2VudDogVGh1cnNkYXks
IE1hcmNoIDE0LCAyMDEzIDAyOjQ1IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86IFN0
YWNoLCBUaG9tYXMgPHRob21hcy5zdGFjaEBzaWVtZW5zLWVudGVycHJpc2UuY29tPjxtYWls
dG86dGhvbWFzLnN0YWNoQHNpZW1lbnMtZW50ZXJwcmlzZS5jb20+DQpDYzogQW5kcmV3IEFs
bGVuOyBqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4gPGpv
bmF0aGFuQHZpZHlvLmNvbT48bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT47IG1tdXNpY0Bp
ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPiA8bW11c2ljQGlldGYub3JnPjxtYWls
dG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEFXOiBbTU1VU0lDXSBSRSA6IEkt
RCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMtMDQu
dHh0DQoNCkFzIHRvIGNjYXAgbm90IGJlaW5nIGFuIGFsdGVybmF0aXZlIHRvIElDRSB3ZSBh
cmUgYWxsIGluIGFncmVlbWVudCBvbiB0aGF0IC0gdGhlIGxhY2sgb2YgcG9ydCBuZWdvdGlh
dGlvbiBhbG9uZSBtYWtlcyB0aGF0IGNsZWFyIChpdCBzaW1wbHkgZG9lc24ndCB3b3JrIHdp
dGhvdXQgdGhhdCkuDQoNCkFzIHRvIGNjYXAgYmVpbmcgZXhwbGljaXRseSBmb3JiaWRkZW4g
dG8gZXhwcmVzcyBJUDQgYW5kL29yIElQNiBhZGRyZXNzZXMgYXMgYWx0ZXJuYXRpdmVzLCBj
YW4gc29tZWJvZHkgcGxlYXNlIHBvaW50IG1lIHRvIGVpdGhlciBtZWV0aW5nIG1pbnV0ZXMg
b3IgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gdG8gdGhhdCBlZmZlY3QgPyBUaGUgb25seSB0
aGluZyBJIGhhdmUgZm91bmQgaXMgdGhlIHBvcnQgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gVGFp
cGVpLCB3aGVyZSB3ZSBhZ3JlZWQgbm90IHRvIGFkZCBhIHBvcnQgY2FwYWJpbGl0eS4gRnJv
bSBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL21pbnV0ZXMvbW11c2ljLmh0
bToNCjxxdW90ZT4NCg0KTWlzY2VsbGFuZW91cyBDYXBhYmlsaXRpZXMgTmVnb3RpYXRpb24g
aW4gU0RQIChTaW1vIFZlaWtrb2xhaW5lbiwgMTApDQo9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCmRyYWZ0
LWdhcmNpYS1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wMC50eHQ8aHR0cDovL3d3
dy5pZXRmLm9yZy9pZC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNh
cHMtMDAudHh0Pg0KU2ltbyBwcmVzZW50ZWQgaGlzIHNsaWRlczxodHRwOi8vd3d3LmlldGYu
b3JnL3Byb2NlZWRpbmdzLzgyL3NsaWRlcy9tbXVzaWMtOC5wcHR4Pi4NClNpbW8gZXhwbGFp
bmVkIHRoZSBuZWVkIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgYWx0ZXJuYXRpdmUgcG9ydCBu
dW1iZXJzLCBidXQgUFNUTiBtZWRpYSwgcG9ydCBudW1iZXIgZG9lc24ndCBtYWtlIHNlbnNl
LiBUaGUgQ1MgZHJhZnQgc2F5cyB1c2UgcG9ydCBudW1iZXIgOSAodGhlIGRpc2NhcmQgcG9y
dCkuIFdlIGhhdmUgdG8gcHV0IHNvbWV0aGluZyB0aGVyZSBiZWNhdXNlIHJlcXVpcmVkIGJ5
IFNEUCBzeW50YXguIElmIGFuIFJUUCBzdHJlYW0gaXMgb2ZmZXJlZCwgdGhlbiBhIHJlZ3Vs
YXIgcG9ydCBudW1iZXIgc2hvdWxkIGJlIHdyaXR0ZW4gaW5zdGVhZC4gVGhlIHByb2JsZW0g
YXJpc2VzIHdoZW4gYm90aCBDUyBhbmQgUlRQIHN0cmVhbXMgYXJlIG9mZmVyZWQgYXQgdGhl
IHNhbWUgdGltZSwgb25lIGFzIGFuIGFsdGVybmF0aXZlIG9mIHRoZSBvdGhlci4gVGhlbiwg
dGhlIHBvcnQgbnVtYmVyIG1ha2VzIHNlbnNlIGZvciBSVFAgYnV0IG5vdCBmb3IgQ1MsIGJ1
dCBzdGlsbCwgdGhlcmUgaXMgYSBzaW5nbGUgcGxhY2UgdG8gd3JpdGUgdGhlIHBvcnQgbnVt
YmVyIGluIHRoZSBTRFAsIHNvLCBoYXMgdG8gYmUgc2hhcmVkIGJ5IGJvdGggYWx0ZXJuYXRp
dmUgbWVkaWEgc3RyZWFtcy4NClBvc3NpYmxlIHNvbHV0aW9uczoNCjEuIENpcmN1aXQtc3dp
dGNoZWQgbWVkaWEgdXNlcyB0aGUgc2FtZSBwb3J0IGFzIFJUUCBtZWRpYSBldmVuIHRob3Vn
aCB0aGUgcG9ydCBpcyBub3QgcmVhbGx5IHVzZWQNCjIuIEV4dGVuZCBjYXBuZWcgd2l0aCBh
IHBvcnQgbnVtYmVyIGNhcGFiaWxpdHkgYXR0cmlidXRlLCByZXN0cmljdGluZyBpdHMgdXNl
IHRvIGNhc2VzIHdoZXJlIElDRSBjYW5ub3QgYmUgdXNlZC4NCjMuICBTZWxlY3QgYW55dGhp
bmcgYXMgYSBwb3J0IG51bWJlciBhbmQgc2F5ICJkbyBub3QgY2FyZSBvbiByZWNlcHRpb24i
Lg0KSm9uYXRoYW4gTGVubm94IHN1Z2dlc3RlZCBzYXlpbmcgdGhhdCBwb3J0IG51bWJlcnMg
bm90IGVxdWFsIDAgaGF2ZSB0byBiZSBpZ25vcmVkLg0KSGFkcmllbCBLYXBsYW4gYXNrZWQg
aWYgbWlkZGxlIGJveGVzIG5vdCBzdXBwb3J0aW5nIHRoaXMgc3R1ZmYgY2FuIGJlIGJyb2tl
bi4gVGhlIGRpc2N1c3Npb24gaXMgbW92ZWQgb2ZmbGluZS4NClRoZXJlIGFyZSBxdWVzdGlv
bnMgb24gaG93IGNvdWxkIGJlIHBvc3NpYmxlIHRvIGluZGljYXRlIHByZWZlcmVuY2UgZm9y
IG9uZSBtZWRpYSBzdHJlYW0gYWJvdmUgdGhlIGFsdGVybmF0aXZlLg0KTWlndWVsIEdhcmNp
YSBzdWdnZXN0ZWQgdXNpbmcgcG9ydCA5IGlmIGl0IHdvcmtzLiBJZiBub3QgdGFrZSBhbnl0
aGluZyBub3QgZXF1YWwgMC4gUmVjZWl2ZXIgaGFzIHRvIGlnbm9yZS4NCkluIGdlbmVyYWws
IHRoZXJlIHdhcyBwdXNoYmFjayBvbiB0aGUgcG9ydCBuZWdvdGlhdGlvbiBhcHByb2FjaC4g
VGhlIGF1dGhvcnMgc2hvdWxkIGV4cGxvcmUgYSBzb2x1dGlvbiBhbG9uZyB0aGUgdGhpcmQg
b3B0aW9uOiB3cml0ZSB0aGUgUlRQIHBvcnQgbnVtYmVyIGluIHRoZSAibT0iIGxpbmUuIElm
IENTIGFsdGVybmF0aXZlIGlzIGNob3NlbiwgZGlzY2FyZCB0aGUgcG9ydCBudW1iZXIgb24g
cmVjZXB0aW9uLg0KPC9xdW90ZT4NCg0KQXBhcnQgZnJvbSB0aGF0LCB0aGUgb25seSB0aGlu
ZyBJJ20gYXdhcmUgb2YgaXMgdGhlIDQgV0cgdmVyc2lvbnMgb2YgdGhpcyBkcmFmdCB3aGlj
aCBoYXZlIGFsbCBzYWlkIHRoZSBzYW1lIGFib3V0IElQNC9JUDYgYW5kIElDRSwgYW5kIGFn
YWluLCB0aGF0IHRleHQgd2FzIGJvdGggV0dMQydlZCBhbmQgcmV2aWV3ZWQgYnkgMiB2b2x1
bnRlZXJzIHdpdGhvdXQgYW55IGNvbmNlcm5zLiBXaGVyZSBkb2VzIHRoZSBhbHRlcm5hdGUg
dW5kZXJzdGFuZGluZyBjb21lIGZyb20gPw0KDQpUaGFua3MNCg0KLS0gRmxlbW1pbmcNCg0K
DQpPbiAzLzE0LzEzIDI6MTYgUE0sIFN0YWNoLCBUaG9tYXMgd3JvdGU6DQpUaGlzIGlzIGFs
c28gbXkgdW5kZXJzdGFuZGluZw0KLi4uIGFsdGhvdWdoIG15IGluaXRpYWxseSBwcm9wb3Nl
ZCB0ZXh0IGRvZXMgbm90IHJlZmxlY3QgdGhpcyBjb3JyZWN0bHkuDQoNClJlZ2FyZHMNClRo
b21hcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpWb246IG1tdXNp
Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4gW21h
aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQW5kcmV3IEFs
bGVuDQpHZXNlbmRldDogRG9ubmVyc3RhZywgMTQuIE3DpHJ6IDIwMTMgMTQ6MTANCkFuOiBq
b25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT47IGZhbmRyZWFz
QGNpc2NvLmNvbTxtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tPg0KQ2M6IG1tdXNpY0BpZXRm
Lm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFtNTVVTSUNdIFJF
IDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fw
cy0wNC50eHQNCg0KTXkgdW5kZXJzdGFuZGluZyBhbHNvIHdhcyB0aGF0IHdlIGFncmVlZCB0
aGF0IENDQVAgd2FzIG5vdCBhbiBhbHRlcm5hdGl2ZSB0byBJQ0UuDQoNCg0KRnJvbTogSm9u
YXRoYW4gTGVubm94IFttYWlsdG86am9uYXRoYW5AdmlkeW8uY29tXQ0KU2VudDogVGh1cnNk
YXksIE1hcmNoIDE0LCAyMDEzIDAxOjA2IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86
IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjxtYWlsdG86ZmFuZHJl
YXNAY2lzY28uY29tPg0KQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv
Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu
Z2UuY29tPjxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEFuZHJldyBB
bGxlbjsgbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+IDxtbXVzaWNA
aWV0Zi5vcmc+PG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJ
Q10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91
cy1jYXBzLTA0LnR4dA0KDQoNCk9uIE1hciAxNCwgMjAxMywgYXQgMTo0MyBQTSwgRmxlbW1p
bmcgQW5kcmVhc2VuIHdyb3RlOg0KDQoNCk9uIDMvMTQvMTMgMTE6NDAgQU0sIG1vaGFtZWQu
Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j
b20+IHdyb3RlOg0KUmUtLA0KDQpXaGF0IGlzIGltcG9ydGFudCBpcyB0aGUgcXVhbGl0eSBv
ZiBwcm9kdWNlZCBkb2N1bWVudHMuIFRoZSBjb250ZW50IG9mIHRoZSBkb2N1bWVudCBpcyBu
b3QgZnJvemVuIGFuZCB1bmxlc3MgSSdtIG1pc3Rha2VuIHRoZXJlIGlzIG5vdCBJRVRGIExD
Lg0KDQpDb3JyZWN0Lg0KDQpXaGF0IEkgdW5kZXJzdGFuZCBmcm9tIHRoZSB0ZXh0IGluIHRo
ZSBkcmFmdCBpczogY2NhcCBpcyBhbGxvd2VkIHRvIHNpZ25hbCBhbiBJUHY0QCBhbmQgSVB2
NkAgaWYgSUNFIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCmNjYXAgaXMgbm90IHByb2hpYml0ZWQg
ZnJvbSBkb2luZyBzbyBpbiB0aGUgYWJzZW5jZSBvZiBJQ0UsIGhvd2V2ZXIgYXMgZXhwbGFp
bmVkIGluIHRoZSBkb2N1bWVudA0KMSkgV2hlbiB0aGUgSUVURiBTdGFuZGFyZCBUcmFjayBt
ZWNoYW5pc20gSUNFIGlzIGF2YWlsYWJsZSwgY2NhcCBNVVNUIE5PVCBzaWduYWwgYW4gSVB2
NC9JUFY2IGFkZHJlc3MgYWx0ZXJuYXRpdmUuDQoyKSBUaGUgZHJhZnQgZG9lcyAoaW50ZW50
aW9uYWxseSkgbm90IHByb3ZpZGUgYSBmdWxsIHNvbHV0aW9uIGZvciBuZWdvdGlhdGluZyBh
bHRlcm5hdGl2ZSBJUC1hZGRyZXNzZXMgc2luY2Ugd2UgaGF2ZSBhIFN0YW5kYXJkcyBUcmFj
ayBtZWNoYW5pc20gZm9yIGRvaW5nIHNvIChJQ0UpLg0KDQpIaSwgRmxlbWluZyAtLQ0KDQpN
eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBXRyBjb25zZW5zdXMgLS0gYW5kIG15IGludGVycHJl
dGF0aW9uIG9mIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCAtLSB3YXMgc3Ryb25nZXIgdGhhbiB0
aGlzOiBjY2FwIE1VU1QgTk9UIGJlIHVzZWQgZm9yIHRoZSBraW5kcyBvZiBhbHRlcm5hdGl2
ZXMgSUNFIGNhbiBleHByZXNzLCB3aGV0aGVyIG9yIG5vdCBJQ0UgaXMgYWN0dWFsbHkgYmVp
bmcgdXNlZCBpbiBhIHBhcnRpY3VsYXIgb2ZmZXIvYW5zd2VyLg0KDQpJZiB3ZSdyZSBnZXR0
aW5nIGRpdmVyZ2VudCBpbnRlcnByZXRhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCwgd2UgcHJv
YmFibHkgZG8gbmVlZCB0byB1cGRhdGUgaXRzIHRleHQuDQoNCi0tDQpKb25hdGhhbiBMZW5u
b3gNCmpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPg0KDQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFj
aG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVn
ZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGlj
aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3Rp
dHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRp
b24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9o
aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv
ciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0
aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwg
ZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkg
dW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5s
YXdmdWwuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu
ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv
biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi
eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp
LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp
cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz
aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh
bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz
ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z
bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k
IG1heSBiZSB1bmxhd2Z1bC4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21p
c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy
aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh
YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u
IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg
dG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5
c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlv
biBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90
IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg==

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2D92FXMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9
IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkZsZW1taW5nPGJyPg0KPGJyPg0KV2hhdCBpcyB0
aGUgcHJvcG9zZWQgd2F5IGZvcndhcmQgbm93Pzxicj4NCjxicj4NCkRvZXMgdGhpcyBoYXZl
IHRvIGdvIGJhY2sgdG8gdGhlIFdHIGFuZCByZWRvIFdHTEMgb3IgaXMgdGhpcyBzb21ldGhp
bmcgdGhhdCBjYW4gYmUgcmVzb2x2ZWQgd2l0aG91dCB0aGF0Pzxicj4NCjxicj4NCklNSE8g
aXRzIGEgbWF0dGVyIG9mIGdldHRpbmcgdGhlIHdvcmRpbmcgcmlnaHQuIEkgZG9uJ3Qgc2Vl
IGEgcHJvYmxlbSB3aXRoIGNvbnRpbnVpbmcgdG8gdXNlIENDQVAgZm9yIHRoaXMgYW5kIGhh
dmluZyB0ZXh0IHRoYXQgcHV0cyBhIHByb2hpYml0aW9uIG9uIHVzaW5nIHRoaXMgdG8gbmVn
b3RpYXRlIGFsdGVybmF0ZSBJTiB0eXBlcyBiZWNhdXNlIHRoaXMgd291bGQgZHVwbGljYXRl
IHRoYXQgY2FwYWJpbGl0eSBhbHJlYWR5IHByb3ZpZGVkIGJ5DQogSUNFLjxicj4NCjxicj4N
CkFuZHJldzxicj4NCjwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
aW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwv
Yj46IEZsZW1taW5nIEFuZHJlYXNlbiBbbWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbV0NCjxi
cj4NCjxiPlNlbnQ8L2I+OiBTdW5kYXksIE1hcmNoIDE3LCAyMDEzIDEwOjU4IFBNIENlbnRy
YWwgU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvPC9iPjogU2ltby5WZWlra29sYWluZW5Abm9r
aWEuY29tICZsdDtTaW1vLlZlaWtrb2xhaW5lbkBub2tpYS5jb20mZ3Q7IDxicj4NCjxiPkNj
PC9iPjogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSAmbHQ7bW9oYW1lZC5ib3VjYWRh
aXJAb3JhbmdlLmNvbSZndDs7IEFuZHJldyBBbGxlbjsgam9uYXRoYW5AdmlkeW8uY29tICZs
dDtqb25hdGhhbkB2aWR5by5jb20mZ3Q7OyBtbXVzaWNAaWV0Zi5vcmcgJmx0O21tdXNpY0Bp
ZXRmLm9yZyZndDsNCjxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW01NVVNJQ10gUkUgOiBJ
LUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzLTA0
LnR4dA0KPGJyPg0KPC9mb250PiZuYnNwOzxicj4NCjwvZGl2Pg0KQXMgbm90ZWQgaW4gbXkg
ZS1tYWlsIGJlbG93LCB0aGUgQW5haGVpbSBkaXNjdXNzaW9uIHdhcyBiYXNlZCBvbiB0aGUg
b3JpZ2luYWwgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjLWNhcCI+DQpkcmFm
dC1nYXJjaWEtbW11c2ljLXNkcC1taXNjLWNhcDwvYT4gZG9jdW1lbnQsIHdoaWNoIGRpZCBp
bmRlZWQgcG9zaXRpb24gJnF1b3Q7Y2NhcCZxdW90OyBhcyBhbiBhbHRlcm5hdGl2ZSB0byBJ
Q0UuIFRoZQ0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNh
cHMiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2FyY2lhLW1tdXNpYy1z
ZHAtbWlzY2VsbGFuZW91cy1jYXBzPC9hPiB3aGljaCB3YXMgYWRvcHRlZCBieSB0aGUgV0cg
Y2hhbmdlZCB0aGUgd29yZGluZyB0byB3aGF0IGlzIGJlaW5nIGRpc2N1c3NlZCBub3cgYW5k
IHdhcyBhZG9wdGVkIGJ5IHRoZSBXRy4NCjxicj4NCjxicj4NCklmIHBlb3BsZSB3YW50ZWQg
dG8gZXhwbGljaXRseSBwcmV2ZW50IHRoaXMgbWVjaGFuaXNtIGZyb20gYmVpbmcgdXNlZCBm
b3IgSVA0IGFuZC9vciBJUDYgYWRkcmVzc2VzLCB0aGVuIEkmcXVvdDttIGF0IGEgbG9zcyB0
byB1bmRlcnN0YW5kIHdoeSB0aGUgY3VycmVudCB3b3JkaW5nIHdhcyBjaG9zZW4gYW5kIGFn
cmVlZCB0byBhcyB3ZWxsIGFzIHRvIHdoeSBhIGdlbmVyYWwgbWVjaGFuaXNtIGxpa2UgJnF1
b3Q7Y29ubmVjdGlvbiBkYXRhIGNhcGFiaWxpdHkmcXVvdDsgYXMNCiBwYXJ0IG9mIHRoZSBv
dmVyYWxsIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gZnJhbWV3b3JrIHdhcyBjaG9zZW4gYW5k
IGFncmVlZCB0by4gSG93ZXZlciwgaW4gc3BpdGUgb2YgdGhlIGRvY3VtZW50IHJldmlld3Ms
IGxvbmcgY29tcGxldGVkIFdHTEMsIGFuZCB0aGUgZXh0ZXJuYWwgM0dQUCBkZXBlbmRlbmN5
LCBpdCBpcyBvYnZpb3VzIGZyb20gdGhlIGUtbWFpbCB0aHJlYWQgdGhhdCBtb3JlIGRpc2N1
c3Npb24gaXMgbmVlZGVkIG9uIHRoaXMsIGFuZA0KIGhlbmNlIHdlIHdpbGwgaGF2ZSB0byBk
ZWFsIHdpdGggdGhhdCBiZWZvcmUgd2UgY2FuIHByb2dyZXNzIHRoZSBkb2N1bWVudC4gPGJy
Pg0KPGJyPg0KVGhhbmtzIDxicj4NCjxicj4NCi0tIEZsZW1taW5nIChNTVVTSUMgY28tY2hh
aXIpPGJyPg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAz
LzE1LzEzIDg6MDQgQU0sIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhy
ZWY9Im1haWx0bzpTaW1vLlZlaWtrb2xhaW5lbkBub2tpYS5jb20iPg0KU2ltby5WZWlra29s
YWluZW5Abm9raWEuY29tPC9hPiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNp
dGU9Im1pZDpEMDlEQUU2QjYzNjg1MTQ1OUY3NTc1RDE0NkVGQjU0QjIxMDk5NTkwQDAwOC1B
TTFNUE4xLTAyNi5tZ2Rub2subm9raWEuY29tIiB0eXBlPSJjaXRlIj4NCjxtZXRhIG5hbWU9
IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkDQogICAg
ICAgIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJs
KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K
d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1
cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZl
dGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7
DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K
CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uYXBwbGUtY29u
dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9
DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUt
c3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlz
IGdvZXMgYWxsIHRoZSB3YXkgYmFjayB0byBJRVRGNjgsIHdoZXJlIGFuIGFncmVlbWVudCB3
YXMgbWFkZSB0byB1c2UgSUNFIGZvciBmdXR1cmUgYWRkcmVzcyB0eXBlIHNlbGVjdGlvbiAo
ZGVwcmVjYXRpbmcgQU5BVCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNvdWxkbuKA
mXQgZmluZCBhIHdyaXR0ZW4gc3RhdGVtZW50IGluIG1pbnV0ZXMgb24gY2NhcCBiZWluZyBl
eHBsaWNpdGx5IGZvcmJpZGRlbiB0byBleHByZXNzIElQNCBhbmQvb3IgSVA2IGFkZHJlc3Nl
cyBhcyBhbHRlcm5hdGl2ZXMg4oCTIGJ1dCBteSB0aG91Z2h0IGhhcyBiZWVuDQogdGhhdCBh
bHRlcm5hdGl2ZSBJUCBhZGRyZXNzZXMgbWF5IG9ubHkgYmUgb2ZmZXJlZCB3aXRoIElDRS4g
VGhpcyB3YXMgYWxzbyByZWZsZWN0ZWQgaW4gYnkgSmVhbi1GcmFuY29pcyAoPGEgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2
ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNnMDc5MTYuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzA3OTE2Lmh0bWw8L2E+KQ0K
IHdoZXJlIGhlIHNheXMg4oCdPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+DQpBcyBmb3IgcHJvcG9zaW5nIElQdjQvSVB2NiBhbHRlcm5h
dGl2ZXMsIElDRSBkZXByZWNhdGVzIEFOQVQgYW5kIGlzIHRoZSBwcmVmZXJyZWQgc29sdXRp
b24gdGhlIFdHIGhhcyBjaG9zZW4gc28gZmFyIHBlciBJRVRGIzY4LiDigJwmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2ltbzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAg
ICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIG5hbWU9Il9fX19fcmVwbHlz
ZXBhcmF0b3IiPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3
aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh
dGVkIiBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3Vu
Y2VzQGlldGYub3JnPC9hPiBbPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl
Zj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bW11c2ljLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgPGEgY2xhc3M9Im1v
ei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly
QG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8
Yj5TZW50OjwvYj4gMTUuIG1hYWxpc2t1dXRhIDIwMTMgODozNjxicj4NCjxiPlRvOjwvYj4g
RmxlbW1pbmcgQW5kcmVhc2VuOyBBbmRyZXcgQWxsZW48YnI+DQo8Yj5DYzo8L2I+IDxhIGNs
YXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2
aWR5by5jb20iPmpvbmF0aGFuQHZpZHlvLmNvbTwvYT47DQo8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBSRSA6IEkt
RCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMtMDQu
dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
cg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPkZlbG1taW5nLDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2Nv
bG9yOmJsdWUiPklmIHlvdSBhcmUgbG9va2luZyBmb3Igc29tZXRoaW5nIHdyaXR0ZW4sIHlv
dSBjYW4gcmVhZCB0aGUgbWludXRlcyBpbiB0aGUgQW5haGVpbSBtZWV0aW5nIChJbg0KPGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv
bW11c2ljL21pbnV0ZXM/aXRlbT1taW51dGVzNzcuaHRtbCI+DQpodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvd2cvbW11c2ljL21pbnV0ZXM/aXRlbT1taW51dGVzNzcuaHRtbDwvYT4pLCB5b3Ug
Y2FuIHJlYWQgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxz
cGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG8gY29u
Y2x1ZGUgdGhlIFdHIGNoYWlyIHJlcG9ydCwgSmVhbi1GcmFuY29pcyBjbGFyaWZpZWQgdGhl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVl
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RhdHVzIG9mIDwvc3Bhbj48YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sP3JlcG9z
aXRvcnk9aHR0cDovL3Rvb2xzLmlldGYub3JnJmFtcDtkcmFmdD1kcmFmdC1pZXRmLW1tdXNp
Yy1zZHAtbWlzYy1jYXAtMDAiPmRyYWZ0LWlldGYtbW11c2ljLXNkcC1taXNjLWNhcC0wMDwv
YT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+IChzZWUgdGhlIGNoYWlyJ3M8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBzbGlkZXMgIzkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2FzIG1pc3Rha2VubHkgYWNjZXB0ZWQgYXMgYSBXRyBk
b2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhvdXQgY29uZmlybWF0aW9u
IG9uIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWZ0ZXIg
YSBicmllZiByZWNhcCBvZiB0aGUgSS1EIGhpc3RvcnkgYW5kIHNjb3BlLCBzZXZlcmFsPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tbWVudHMgd2VyZSBtYWRlIGluIHN1cHBvcnQg
b2YgY29udGludWluZyB0aGUgd29yayBhcyBwYXJ0IG9mPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgYSBXRyBpdGVtIGFzIGxvbmcgYXMgdGhlIHNjb3BlIGRvZXMgbm90IG92ZXJsYXAg
d2l0aCBJQ0UgZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVB2NC1JUHY2IGNvbm5l
Y3Rpb24gYWRkcmVzcyBuZWdvdGlhdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLSBSb25pIEV2ZW4gaW5kaWNhdGVkIHN1cHBvcnQgZm9yIHRoZSB3b3Jr
IGFuZCBub3RlZCB0aGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGIgcGFyYW1ldGVyIHdhcyBwYXJ0IG9mIHRoZSBvcmlnaW5hbCBT
RFAgY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IG5lZ290aWF0aW9uIGZyYW1ld29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAtIEpvaG4gRWx3ZWxsLCBHb256YWxvIENhbWFyaWxsbywgSm9u
YXRoYW4gTGVubm94IGFuZCBDdWxsZW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBKZW5uaW5ncyBhcmUgaW4gZmF2b3Igb2YgdGhlIHdvcmsg
aXRlbSBhcyBsb25nIGFzIGl0cyBzY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIGNsYXJpZmllZCB0byBub3Qgb3ZlcmxhcCB3aXRo
IElDRSBmb3IgSVB2NC1JUHY2IGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtIEluZ2VtYXIgSm9oYW5zc29uIGFsc28gZXhwcmVzc2Vk
IHN1cHBvcnQgZm9yIGl0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUg
d2FzIHN0cm9uZyBzdXBwb3J0IGZvciBjb250aW51aW5nIHRvIGRlZmluZSBhIGNhcGFiaWxp
dHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
dWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgZm9yIGIsIGkg
YW5kIHNvbWUgY29uY2VybnMgd2l0aCB0aGUgY2NhcCBwYXJhbWV0ZXIuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgTW9yZSBkaXNjdXNzaW9ucyBvY2N1cnJlZCBhdCB0aGUg
ZW5kIG9mIHRoZSBtZWV0aW5nIHdoZW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgZG9jdW1lbnQgd2FzIHByZXNlbnRlZCwgc2VlIG5vdGVzIGJlbG93LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SmVhbi1GcmFuY29pcyBwcm9wb3Nl
ZCB0aGUgbmV4dCBzdGVwczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAtIHRoZSBXRyBjaGFpcnMgd2lsbCBjb25maXJtIHRoZSBpbnRlcmVzdCBmb3IgYSBXRyBp
dGVtIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv
cjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgZGVmaW5lIGFkZGl0aW9uYWwgU0RQIGNhcCBuZWcgcGFyYW1ldGVycyAoYiBhbmQgaSBs
aW5lcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFBlbmRpbmcg
QUQgYXBwcm92YWwsIHRoZSBXRyBpdGVtIHdpbGwgYmUgY2hhcnRlcmVkPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBTaW1vIFYuIHdpbGwgcmUtc3VibWl0IGFu
IHVwZGF0ZWQgSW50ZXJuZXQtRHJhZnQgYXMgYW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpdmlkdWFsIHN1Ym1pc3Npb248bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIHRoZW4gdGhlIGNoYWlycyB3aWxs
IGFzayB0aGUgbGlzdCBpZiB0aGUgV29ya2luZyBHcm91cDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBvcnRzIG1ha2luZyBTaW1vJ3Mg
aW5kaXZpZHVhbCBzdWJtaXNzaW9uIGFzIHRoZSBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+VGhlIGN1cnJlbnQgZGlzY3Vz
c2lvbiBzaG93cyB0aGVyZSBpcyBhIGNvbmZ1c2lvbiBpbiB0aGUgY3VycmVudCB0ZXh0IGFu
ZCBpdCBpcyB3b3J0aCB0byBiZSBjbGFyaWZpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5DaGVlcnMsPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5NZWQ8L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbQ0K
NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0
OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h
bGlnbjpjZW50ZXIiIGFsaWduPSJjZW50ZXIiPjxzcGFuIGxhbmc9IkZSIj4NCjxociBhbGln
bj0iY2VudGVyIiBzaXplPSIyIiB3aWR0aD0iMTAwJSI+DQo8L3NwYW4+PC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7IiBsYW5nPSJGUiI+RGUmbmJzcDs6PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyIgbGFuZz0iRlIiPg0KPGEgY2xhc3M9
Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2Vz
QGlldGYub3JnIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQg
ZGU8L2I+IEZsZW1taW5nIEFuZHJlYXNlbjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBq
ZXVkaSAxNCBtYXJzIDIwMTMgMjE6Mzk8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEFuZHJldyBB
bGxlbjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy
ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSI+DQpqb25hdGhhbkB2
aWR5by5jb208L2E+OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm
PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj4NCm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8
Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbTU1VU0lDXSBSRSA6IEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMtMDQudHh0PC9zcGFuPjxzcGFu
IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biAzLzE0LzEzIDM6NTAgUE0sIEFuZHJldyBBbGxlbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48YnI+DQpJIGFtIG5vdCBzdXJlIGlmIGFueXRoaW5nIGlzIHJlY29yZGVkIGluIGFueSBt
aW51dGVzIGJ1dCB3ZSBoYWQgYW4gb2ZmbGluZSBkaXNjdXNzaW9uIHRvIHJlbW92ZSB0aGUg
cm9hZGJsb2NrIG9uIHRoaXMgd2l0aCBKb25hdGhhbiB0byBhZGRyZXNzIGhpcyBjb25jZXJu
IHRoYXQgdGhpcyB3YXMgYSBwb3RlbnRpYWwgYWx0ZXJuYXRpdmUgdG8gSUNFIGFuZCBhZGRy
ZXNzZWQgdGhpcyB3aXRoIHRoZSBjdXJyZW50IHRleHQuIFRoaXMgdGV4dCBhbmQgdGhlDQog
cmVhc29uIGJlaGluZCBpdCBJIHRoaW5rIHdhcyBwb2ludGVkIG91dCBvbiB0aGUgbGlzdCBk
dXJpbmcgUXVlYmVjIG9yIHNob3J0bHkgYWZ0ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBmaW5kIHRoZSBt
ZXNzYWdlIG9yIHJlY2FsbCB3aG8gc2VudCBpdCA/IDxicj4NCjxicj4NCkFsc28sIHRoZSBR
dWViZWMgbWVldGluZyB3YXMgaW4gSnVseSAyMDExLiBUcmFjaW5nIGJhY2sgd2UgaGF2ZTo8
YnI+DQo8YnI+DQphKSBUaGUgaW5pdGlhbCAoPykgaW5kaXZpZHVsIHZlcnNpb25zIG9mIHRo
ZSBkcmFmdCAoMjAwOC8yMDA5KTombmJzcDsmbmJzcDsgJm5ic3A7IDxhIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2Fy
Y2lhLW1tdXNpYy1zZHAtbWlzYy1jYXAiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtZ2FyY2lhLW1tdXNpYy1zZHAtbWlzYy1jYXA8L2E+PGJyPg0KYikgQW5vdGhlciBp
bmRpdmlkdWFsIHRha2Ugb24gdGhlIGRyYWZ0IChBdWd1c3QgMjAxMSYjNDM7KTombmJzcDsm
bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyA8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdhcmNpYS1tbXVz
aWMtc2RwLW1pc2NlbGxhbmVvdXMtY2FwcyI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHM8L2E+PGJyPg0K
YykgVGhlIGludGlhbCBXRyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCAoTWFyY2ggMjAxMiYjNDM7
KTogJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91cy1jYXBzIj4N
Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1taXNj
ZWxsYW5lb3VzLWNhcHM8L2E+PGJyPg0KPGJyPg0KVGhlICZxdW90O2EpJnF1b3Q7IHZlcnNp
b24gZGlkIGluZGVlZCBwb3NpdGlvbiB0aGUgZHJhZnQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8g
SUNFLCBob3dldmVyIGFsbCAmcXVvdDtiKSZxdW90OyBhbmQgJnF1b3Q7YykmcXVvdDsgdmVy
c2lvbnMgY2hhbmdlZCB0aGlzIGFzIHBlciB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbi4NCjxi
cj4NCjxicj4NCkknbSBzdGlsbCBsb29raW5nIGZvciBhbnl0aGluZyB3cml0dGVuIGFueXdo
ZXJlIHRoYXQgc3VnZ2VzdHMgdGhhdCB0aGUgdGV4dCBpbiAmcXVvdDtiKSZxdW90OyBhbmQg
JnF1b3Q7YykmcXVvdDsgZG9lcyBub3QgcmVwcmVzZW50IGNvbnNlbnN1cyBhbmQvb3IgdGhh
dCBjb25zZW5zdXMgaXMgdGhhdCB0aGUgbWVjaGFuaXNtIE1VU1QgYWx3YXlzIGJlIHByb2hp
Yml0ZWQgZnJvbSBuZWdvdGlhdGluZyBJUDQvSVA2IGFkZHJlc3NlcyAoYXMgb3Bwb3NlZCB0
byBqdXN0IHdoZW4gSUNFIGlzDQogbm90IGF2YWlsYWJsZSkuIDxicj4NCjxicj4NClRoYW5r
cyA8YnI+DQo8YnI+DQotLSBGbGVtbWluZyA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGDQogICAgICAg
ICAgICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OiBGbGVtbWluZyBBbmRyZWFzZW4g
WzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2Nv
LmNvbSI+bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50PC9i
PjogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDAyOjQ1IFBNIENlbnRyYWwgU3RhbmRhcmQg
VGltZTxicj4NCjxiPlRvPC9iPjogU3RhY2gsIFRob21hcyA8YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGhyZWY9Im1haWx0bzp0aG9tYXMuc3RhY2hAc2llbWVucy1lbnRlcnByaXNlLmNv
bSI+DQombHQ7dGhvbWFzLnN0YWNoQHNpZW1lbnMtZW50ZXJwcmlzZS5jb20mZ3Q7PC9hPiA8
YnI+DQo8Yj5DYzwvYj46IEFuZHJldyBBbGxlbjsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj4NCmpvbmF0aGFuQHZpZHlvLmNv
bTwvYT4gPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86am9uYXRoYW5A
dmlkeW8uY29tIj4NCiZsdDtqb25hdGhhbkB2aWR5by5jb20mZ3Q7PC9hPjsgPGEgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj4NCm1tdXNp
Y0BpZXRmLm9yZzwvYT4gPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86
bW11c2ljQGlldGYub3JnIj4mbHQ7bW11c2ljQGlldGYub3JnJmd0OzwvYT4NCjxicj4NCjxi
PlN1YmplY3Q8L2I+OiBSZTogQVc6IFtNTVVTSUNdIFJFIDogSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi1tbXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50eHQNCjxicj4NCjwvc3Bh
bj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QXMgdG8gY2NhcCBub3QgYmVpbmcgYW4gYWx0ZXJuYXRpdmUgdG8gSUNFIHdlIGFyZSBhbGwg
aW4gYWdyZWVtZW50IG9uIHRoYXQgLSB0aGUgbGFjayBvZiBwb3J0IG5lZ290aWF0aW9uIGFs
b25lIG1ha2VzIHRoYXQgY2xlYXIgKGl0IHNpbXBseSBkb2Vzbid0IHdvcmsgd2l0aG91dCB0
aGF0KS4NCjxicj4NCjxicj4NCkFzIHRvIGNjYXAgYmVpbmcgZXhwbGljaXRseSBmb3JiaWRk
ZW4gdG8gZXhwcmVzcyBJUDQgYW5kL29yIElQNiBhZGRyZXNzZXMgYXMgYWx0ZXJuYXRpdmVz
LCBjYW4gc29tZWJvZHkgcGxlYXNlIHBvaW50IG1lIHRvIGVpdGhlciBtZWV0aW5nIG1pbnV0
ZXMgb3IgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gdG8gdGhhdCBlZmZlY3QgPyBUaGUgb25s
eSB0aGluZyBJIGhhdmUgZm91bmQgaXMgdGhlIHBvcnQgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4g
VGFpcGVpLA0KIHdoZXJlIHdlIGFncmVlZCBub3QgdG8gYWRkIGEgcG9ydCBjYXBhYmlsaXR5
LiBGcm9tIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3d3dy5pZXRm
Lm9yZy9wcm9jZWVkaW5ncy84Mi9taW51dGVzL21tdXNpYy5odG0iPg0KaHR0cDovL3d3dy5p
ZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9taW51dGVzL21tdXNpYy5odG08L2E+Ojxicj4NCiZs
dDtxdW90ZSZndDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgIE5ldyZx
dW90OyI+TWlzY2VsbGFuZW91cyBDYXBhYmlsaXRpZXMgTmVnb3RpYXRpb24gaW4gU0RQIChT
aW1vIFZlaWtrb2xhaW5lbiwgMTApPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu
NXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZTstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6DQogICAgICAg
ICAgICBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6
MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXINCiAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij49PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlOy13ZWJr
aXQtdGV4dC1zaXplLWFkanVzdDoNCiAgICAgICAgICAgIGF1dG87LXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMy41cHQiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9pZC9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNh
cHMtMDAudHh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6cHVycGxl
Ij5kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjZWxsYW5lb3VzLWNhcHMtMDAudHh0PC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZTstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6DQogICAg
ICAgICAgICBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp
bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXINCiAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij5TaW1vIHByZXNlbnRlZCBo
aXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij48YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvc2xpZGVz
L21tdXNpYy04LnBwdHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpw
dXJwbGUiPnNsaWRlczwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgTmV3JnF1
b3Q7Ij4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZTstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6DQogICAgICAgICAgICBhdXRvOy13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAg
ICAgICAgICAgTmV3JnF1b3Q7Ij5TaW1vIGV4cGxhaW5lZCB0aGUgbmVlZCB0byBiZSBhYmxl
IHRvIGluZGljYXRlIGFsdGVybmF0aXZlIHBvcnQgbnVtYmVycywgYnV0IFBTVE4gbWVkaWEs
IHBvcnQgbnVtYmVyIGRvZXNuJ3QgbWFrZSBzZW5zZS4gVGhlIENTIGRyYWZ0IHNheXMgdXNl
IHBvcnQgbnVtYmVyIDkgKHRoZSBkaXNjYXJkIHBvcnQpLiBXZSBoYXZlDQogdG8gcHV0IHNv
bWV0aGluZyB0aGVyZSBiZWNhdXNlIHJlcXVpcmVkIGJ5IFNEUCBzeW50YXguIElmIGFuIFJU
UCBzdHJlYW0gaXMgb2ZmZXJlZCwgdGhlbiBhIHJlZ3VsYXIgcG9ydCBudW1iZXIgc2hvdWxk
IGJlIHdyaXR0ZW4gaW5zdGVhZC4gVGhlIHByb2JsZW0gYXJpc2VzIHdoZW4gYm90aCBDUyBh
bmQgUlRQIHN0cmVhbXMgYXJlIG9mZmVyZWQgYXQgdGhlIHNhbWUgdGltZSwgb25lIGFzIGFu
IGFsdGVybmF0aXZlIG9mIHRoZSBvdGhlci4gVGhlbiwNCiB0aGUgcG9ydCBudW1iZXIgbWFr
ZXMgc2Vuc2UgZm9yIFJUUCBidXQgbm90IGZvciBDUywgYnV0IHN0aWxsLCB0aGVyZSBpcyBh
IHNpbmdsZSBwbGFjZSB0byB3cml0ZSB0aGUgcG9ydCBudW1iZXIgaW4gdGhlIFNEUCwgc28s
IGhhcyB0byBiZSBzaGFyZWQgYnkgYm90aCBhbHRlcm5hdGl2ZSBtZWRpYSBzdHJlYW1zLjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7LXdl
YmtpdC10ZXh0LXNpemUtYWRqdXN0Og0KICAgICAgICAgICAgYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAg
IE5ldyZxdW90OyI+UG9zc2libGUgc29sdXRpb25zOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEzLjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0
Og0KICAgICAgICAgICAgYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y
ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgIE5ldyZxdW90OyI+MS4gQ2lyY3Vp
dC1zd2l0Y2hlZCBtZWRpYSB1c2VzIHRoZSBzYW1lIHBvcnQgYXMgUlRQIG1lZGlhIGV2ZW4g
dGhvdWdoIHRoZSBwb3J0IGlzIG5vdCByZWFsbHkgdXNlZDwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEzLjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7LXdlYmtpdC10ZXh0LXNpemUtYWRq
dXN0Og0KICAgICAgICAgICAgYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgIE5ldyZxdW90OyI+Mi4gRXh0
ZW5kIGNhcG5lZyB3aXRoIGEgcG9ydCBudW1iZXIgY2FwYWJpbGl0eSBhdHRyaWJ1dGUsIHJl
c3RyaWN0aW5nIGl0cyB1c2UgdG8gY2FzZXMgd2hlcmUgSUNFIGNhbm5vdCBiZSB1c2VkLjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7LXdl
YmtpdC10ZXh0LXNpemUtYWRqdXN0Og0KICAgICAgICAgICAgYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAg
IE5ldyZxdW90OyI+My4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+U2VsZWN0IGFueXRoaW5nIGFzIGEgcG9ydCBudW1iZXIgYW5kIHNh
eSAmcXVvdDtkbyBub3QgY2FyZSBvbiByZWNlcHRpb24mcXVvdDsuPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTMuNXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTstd2Via2l0LXRleHQtc2l6
ZS1hZGp1c3Q6DQogICAgICAgICAgICBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij5K
b25hdGhhbiBMZW5ub3ggc3VnZ2VzdGVkIHNheWluZyB0aGF0IHBvcnQgbnVtYmVycyBub3Qg
ZXF1YWwgMCBoYXZlIHRvIGJlIGlnbm9yZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTMuNXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6DQog
ICAgICAgICAgICBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw
YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgTmV3JnF1b3Q7Ij5IYWRyaWVsIEthcGxh
biBhc2tlZCBpZiBtaWRkbGUgYm94ZXMgbm90IHN1cHBvcnRpbmcgdGhpcyBzdHVmZiBjYW4g
YmUgYnJva2VuLiBUaGUgZGlzY3Vzc2lvbiBpcyBtb3ZlZCBvZmZsaW5lLjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7LXdlYmtpdC10ZXh0
LXNpemUtYWRqdXN0Og0KICAgICAgICAgICAgYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgIE5ldyZxdW90
OyI+VGhlcmUgYXJlIHF1ZXN0aW9ucyBvbiBob3cgY291bGQgYmUgcG9zc2libGUgdG8gaW5k
aWNhdGUgcHJlZmVyZW5jZSBmb3Igb25lIG1lZGlhIHN0cmVhbSBhYm92ZSB0aGUgYWx0ZXJu
YXRpdmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZTstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6DQogICAgICAgICAgICBhdXRvOy13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAg
ICAgICAgICAgTmV3JnF1b3Q7Ij5NaWd1ZWwgR2FyY2lhIHN1Z2dlc3RlZCB1c2luZyBwb3J0
IDkgaWYgaXQgd29ya3MuIElmIG5vdCB0YWtlIGFueXRoaW5nIG5vdCBlcXVhbCAwLiBSZWNl
aXZlciBoYXMgdG8gaWdub3JlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw
dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGU7LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Og0KICAgICAgICAg
ICAgYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw
eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyDQogICAgICAgICAgICAgIE5ldyZxdW90OyI+SW4gZ2VuZXJhbCwgdGhlcmUgd2Fz
IHB1c2hiYWNrIG9uIHRoZSBwb3J0IG5lZ290aWF0aW9uIGFwcHJvYWNoLiBUaGUgYXV0aG9y
cyBzaG91bGQgZXhwbG9yZSBhIHNvbHV0aW9uIGFsb25nIHRoZSB0aGlyZCBvcHRpb246IHdy
aXRlIHRoZSBSVFAgcG9ydCBudW1iZXIgaW4gdGhlICZxdW90O209JnF1b3Q7IGxpbmUuIElm
IENTIGFsdGVybmF0aXZlDQogaXMgY2hvc2VuLCBkaXNjYXJkIHRoZSBwb3J0IG51bWJlciBv
biByZWNlcHRpb24uPGJyPg0KJmx0Oy9xdW90ZSZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMy41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQXBhcnQgZnJvbSB0
aGF0LCB0aGUgb25seSB0aGluZyBJJ20gYXdhcmUgb2YgaXMgdGhlIDQgV0cgdmVyc2lvbnMg
b2YgdGhpcyBkcmFmdCB3aGljaCBoYXZlIGFsbCBzYWlkIHRoZSBzYW1lIGFib3V0IElQNC9J
UDYgYW5kIElDRSwgYW5kIGFnYWluLCB0aGF0IHRleHQgd2FzIGJvdGggV0dMQydlZCBhbmQg
cmV2aWV3ZWQgYnkgMiB2b2x1bnRlZXJzIHdpdGhvdXQgYW55IGNvbmNlcm5zLiBXaGVyZSBk
b2VzIHRoZSBhbHRlcm5hdGUgdW5kZXJzdGFuZGluZw0KIGNvbWUgZnJvbSA/IDxicj4NCjxi
cj4NClRoYW5rcyA8YnI+DQo8YnI+DQotLSBGbGVtbWluZyA8YnI+DQo8YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzE0LzEz
IDI6MTYgUE0sIFN0YWNoLCBUaG9tYXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPlRoaXMgaXMgYWxzbyBteSB1bmRlcnN0YW5kaW5nDQo8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uLi4gYWx0aG91Z2ggbXkgaW5pdGlhbGx5IHByb3Bv
c2VkIHRleHQgZG9lcyBub3QgcmVmbGVjdCB0aGlzIGNvcnJlY3RseS48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHM8YnI+DQpUaG9tYXMgPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgIDEuNXB0O3Bh
ZGRpbmc6MGNtIDBjbSAwY20NCjQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIiBhbGlnbj0iY2VudGVyIj48c3BhbiBs
YW5nPSJERSI+DQo8aHIgYWxpZ249ImNlbnRlciIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiPg0K
PC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyIgbGFuZz0iREUi
PlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7IiBsYW5nPSJE
RSI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzptbXVzaWMtYm91
bmNlc0BpZXRmLm9yZyI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkltIEF1ZnRyYWcgdm9u
IDwvYj5BbmRyZXcgQWxsZW48YnI+DQo8Yj5HZXNlbmRldDo8L2I+IERvbm5lcnN0YWcsIDE0
LiBNw6RyeiAyMDEzIDE0OjEwPGJyPg0KPGI+QW46PC9iPiA8YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iPmpvbmF0aGFuQHZpZHlv
LmNvbTwvYT47DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpmYW5k
cmVhc0BjaXNjby5jb20iPmZhbmRyZWFzQGNpc2NvLmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+
IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y
ZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxiPkJldHJlZmY6PC9iPiBSZTogW01NVVNJ
Q10gUkUgOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbWlzY2VsbGFuZW91
cy1jYXBzLTA0LnR4dDwvc3Bhbj48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCk15IHVuZGVyc3RhbmRpbmcgYWxzbyB3YXMgdGhh
dCB3ZSBhZ3JlZWQgdGhhdCBDQ0FQIHdhcyBub3QgYW4gYWx0ZXJuYXRpdmUgdG8gSUNFLjxi
cj4NCjwvc3Bhbj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAgICAgICAgICAgICAgIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb208L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46IEpvbmF0aGFuIExlbm5veCBbPGEgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5tYWls
dG86am9uYXRoYW5AdmlkeW8uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ8L2I+OiBUaHVyc2Rh
eSwgTWFyY2ggMTQsIDIwMTMgMDE6MDYgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0K
PGI+VG88L2I+OiBGbGVtbWluZyBBbmRyZWFzZW4gPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBocmVmPSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIj4NCiZsdDtmYW5kcmVhc0BjaXNj
by5jb20mZ3Q7PC9hPiA8YnI+DQo8Yj5DYzwvYj46IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSIgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu
Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhy
ZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4mbHQ7bW9oYW1lZC5i
b3VjYWRhaXJAb3JhbmdlLmNvbSZndDs8L2E+OyBBbmRyZXcgQWxsZW47DQo8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0Bp
ZXRmLm9yZzwvYT4gPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86bW11
c2ljQGlldGYub3JnIj4NCiZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7PC9hPiA8YnI+DQo8Yj5T
dWJqZWN0PC9iPjogUmU6IFtNTVVTSUNdIFJFIDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1t
bXVzaWMtc2RwLW1pc2NlbGxhbmVvdXMtY2Fwcy0wNC50eHQNCjxicj4NCjwvc3Bhbj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IE1hciAxNCwgMjAxMywgYXQgMTo0MyBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuIHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gMy8xNC8xMyAxMTo0MCBBTSwgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJt
YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFp
ckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVv
dDs7Y29sb3I6Ymx1ZSI+UmUtLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
cg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPldoYXQg
aXMgaW1wb3J0YW50IGlzIHRoZSBxdWFsaXR5IG9mIHByb2R1Y2VkIGRvY3VtZW50cy4gVGhl
IGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50IGlzIG5vdCBmcm96ZW4gYW5kIHVubGVzcyBJJ20g
bWlzdGFrZW4gdGhlcmUgaXMgbm90IElFVEYgTEMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3JyZWN0LiA8YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAg
ICBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+V2hhdCBJIHVuZGVyc3RhbmQgZnJvbSB0aGUgdGV4
dCBpbiB0aGUgZHJhZnQgaXM6IGNjYXAgaXMgYWxsb3dlZCB0byBzaWduYWwgYW4gSVB2NEAg
YW5kIElQdjZAIGlmIElDRSBpcyBub3Qgc3VwcG9ydGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Y2NhcCBpcyBub3QgcHJvaGliaXRlZCBmcm9tIGRvaW5nIHNvIGlu
IHRoZSBhYnNlbmNlIG9mIElDRSwgaG93ZXZlciBhcyBleHBsYWluZWQgaW4gdGhlIGRvY3Vt
ZW50PGJyPg0KMSkgV2hlbiB0aGUgSUVURiBTdGFuZGFyZCBUcmFjayBtZWNoYW5pc20gSUNF
IGlzIGF2YWlsYWJsZSwgY2NhcCBNVVNUIE5PVCBzaWduYWwgYW4gSVB2NC9JUFY2IGFkZHJl
c3MgYWx0ZXJuYXRpdmUuPGJyPg0KMikgVGhlIGRyYWZ0IGRvZXMgKGludGVudGlvbmFsbHkp
IG5vdCBwcm92aWRlIGEgZnVsbCBzb2x1dGlvbiBmb3IgbmVnb3RpYXRpbmcgYWx0ZXJuYXRp
dmUgSVAtYWRkcmVzc2VzIHNpbmNlIHdlIGhhdmUgYSBTdGFuZGFyZHMgVHJhY2sgbWVjaGFu
aXNtIGZvciBkb2luZyBzbyAoSUNFKS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgRmxlbWluZyAtLTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRl
cnN0YW5kaW5nIG9mIHRoZSBXRyBjb25zZW5zdXMgLS0gYW5kIG15IGludGVycHJldGF0aW9u
IG9mIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCAtLSB3YXMgc3Ryb25nZXIgdGhhbiB0aGlzOiBj
Y2FwIE1VU1QgTk9UIGJlIHVzZWQgZm9yIHRoZSBraW5kcyBvZiBhbHRlcm5hdGl2ZXMgSUNF
IGNhbiBleHByZXNzLCB3aGV0aGVyIG9yIG5vdCBJQ0UgaXMgYWN0dWFsbHkgYmVpbmcgdXNl
ZCBpbiBhIHBhcnRpY3VsYXINCiBvZmZlci9hbnN3ZXIuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlJ3JlIGdldHRpbmcg
ZGl2ZXJnZW50IGludGVycHJldGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50LCB3ZSBwcm9iYWJs
eSBkbyBuZWVkIHRvIHVwZGF0ZSBpdHMgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuNXB0Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Sm9uYXRoYW4gTGVubm94PGJyPg0KPGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29t
Ij5qb25hdGhhbkB2aWR5by5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8
YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFs
IChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50
IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1
YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uDQogYnkgYW55
b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJ
ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl
IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9y
bWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0
aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24NCiBieSB1bmludGVu
ZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21p
c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy
aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh
YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u
IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo
ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs
eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg
c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0
aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlz
IG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+
DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNv
bnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChp
bmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9y
IG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1Ymxp
YyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBv
dGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l
ZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlv
biBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg
b3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVj
aXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2D92FXMB104ADSrimnet_--

From fandreas@cisco.com  Mon Mar 18 23:24:06 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E3621F8A0D for ; Mon, 18 Mar 2013 23:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.081
X-Spam-Level: 
X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 qsAQBZuyEnFy for ; Mon, 18 Mar 2013 23:24:05 -0700 (PDT)
Received: from p2322.superclick.com (50-200-68-226-static.hfc.comcastbusiness.net [50.200.68.226]) by ietfa.amsl.com (Postfix) with ESMTP id B87B121F8A09 for ; Mon, 18 Mar 2013 23:24:05 -0700 (PDT)
Received: from Flemmings-MacBook-Pro.local ([172.20.6.116]) by p2322.superclick.com (8.13.1/8.13.1) with ESMTP id r2J6O3Kr002184; Mon, 18 Mar 2013 23:24:03 -0700
Message-ID: <51480483.8030501@cisco.com>
Date: Tue, 19 Mar 2013 02:24:03 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Andrew Allen 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040902000901040103020005"
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RE : I-D	Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 06:24:06 -0000

This is a multi-part message in MIME format.
--------------040902000901040103020005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 3/18/13 9:03 PM, Andrew Allen wrote:
>
> Flemming
>
> What is the proposed way forward now?
>
> Does this have to go back to the WG and redo WGLC or is this something 
> that can be resolved without that?
>
I guess that depends on the discussion and where we end up. At worst, 
we'd redo WGLC on the ccap part - the rest of the document is unaffected.

> IMHO its a matter of getting the wording right. I don't see a problem 
> with continuing to use CCAP for this and having text that puts a 
> prohibition on using this to negotiate alternate IN types because this 
> would duplicate that capability already provided by ICE.
>
I think we are talking about more than just wording changes here, which 
is why I'd like more discussion. We'll start a new thread on it.

Thanks

-- Flemming


> Andrew
>
>
> *From*: Flemming Andreasen [mailto:fandreas@cisco.com]
> *Sent*: Sunday, March 17, 2013 10:58 PM Central Standard Time
> *To*: Simo.Veikkolainen@nokia.com 
> *Cc*: mohamed.boucadair@orange.com ; 
> Andrew Allen; jonathan@vidyo.com ; mmusic@ietf.org 
> 
> *Subject*: Re: [MMUSIC] RE : I-D Action: 
> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
> As noted in my e-mail below, the Anaheim discussion was based on the 
> original draft-garcia-mmusic-sdp-misc-cap 
>  
> document, which did indeed position "ccap" as an alternative to ICE. 
> The 
> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps 
> which was adopted by the WG changed the wording to what is being 
> discussed now and was adopted by the WG.
>
> If people wanted to explicitly prevent this mechanism from being used 
> for IP4 and/or IP6 addresses, then I"m at a loss to understand why the 
> current wording was chosen and agreed to as well as to why a general 
> mechanism like "connection data capability" as part of the overall 
> capability negotiation framework was chosen and agreed to. However, in 
> spite of the document reviews, long completed WGLC, and the external 
> 3GPP dependency, it is obvious from the e-mail thread that more 
> discussion is needed on this, and hence we will have to deal with that 
> before we can progress the document.
>
> Thanks
>
> -- Flemming (MMUSIC co-chair)
>
>
> On 3/15/13 8:04 AM, Simo.Veikkolainen@nokia.com wrote:
>>
>> I think this goes all the way back to IETF68, where an agreement was 
>> made to use ICE for future address type selection (deprecating ANAT).
>>
>> I couldn’t find a written statement in minutes on ccap being 
>> explicitly forbidden to express IP4 and/or IP6 addresses as 
>> alternatives – but my thought has been that alternative IP addresses 
>> may only be offered with ICE. This was also reflected in by 
>> Jean-Francois 
>> (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html) 
>> where he says †As for proposing IPv4/IPv6 alternatives, ICE 
>> deprecates ANAT and is the preferred solution the WG has chosen so 
>> far per IETF#68. “
>>
>> Simo
>>
>>


--------------040902000901040103020005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 3/18/13 9:03 PM, Andrew Allen wrote:

    

    

      
      

        Flemming

        

        What is the proposed way forward now?

        

        Does this have to go back to the WG and redo WGLC or is this
        something that can be resolved without that?

        

      

    I guess that depends on the discussion and where we end up. At
    worst, we'd redo WGLC on the ccap part - the rest of the document is
    unaffected. 

    

    
IMHO
        its a matter of getting the wording right. I don't see a problem
        with continuing to use CCAP for this and having text that puts a
        prohibition on using this to negotiate alternate IN types
        because this would duplicate that capability already provided by
        ICE.

        

      

    I think we are talking about more than just wording changes here,
    which is why I'd like more discussion. We'll start a new thread on
    it. 

    

    Thanks 

    

    -- Flemming 

    

    

    
Andrew

      

       

      

        From:
          Flemming Andreasen [mailto:fandreas@cisco.com]
          

          Sent: Sunday, March 17, 2013 10:58 PM Central Standard
          Time

          To: Simo.Veikkolainen@nokia.com
          <Simo.Veikkolainen@nokia.com> 

          Cc: mohamed.boucadair@orange.com
          <mohamed.boucadair@orange.com>; Andrew Allen;
          jonathan@vidyo.com <jonathan@vidyo.com>; mmusic@ietf.org
          <mmusic@ietf.org>
          

          Subject: Re: [MMUSIC] RE : I-D Action:
          draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
          

         

      

      As noted in my e-mail below, the Anaheim discussion was based on
      the original 
        draft-garcia-mmusic-sdp-misc-cap document, which did indeed
      position "ccap" as an alternative to ICE. The
      http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
      which was adopted by the WG changed the wording to what is being
      discussed now and was adopted by the WG.
      

      

      If people wanted to explicitly prevent this mechanism from being
      used for IP4 and/or IP6 addresses, then I"m at a loss to
      understand why the current wording was chosen and agreed to as
      well as to why a general mechanism like "connection data
      capability" as part of the overall capability negotiation
      framework was chosen and agreed to. However, in spite of the
      document reviews, long completed WGLC, and the external 3GPP
      dependency, it is obvious from the e-mail thread that more
      discussion is needed on this, and hence we will have to deal with
      that before we can progress the document. 

      

      Thanks 

      

      -- Flemming (MMUSIC co-chair)

      

      

      
On 3/15/13 8:04 AM, 
          Simo.Veikkolainen@nokia.com wrote:

      

      

        
        
        
        

          
I
              think this goes all the way back to IETF68, where an
              agreement was made to use ICE for future address type
              selection (deprecating ANAT).

          
 

          
I
              couldn’t find a written statement in minutes on ccap being
              explicitly forbidden to express IP4 and/or IP6 addresses
              as alternatives – but my thought has been that alternative
              IP addresses may only be offered with ICE. This was also
              reflected in by Jean-Francois (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html)
              where he says †As
              for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT
              and is the preferred solution the WG has chosen so far per
              IETF#68. “             
              

          
 

          
Simo

          
 

          

        

      

    

    

  


--------------040902000901040103020005--

From fandreas@cisco.com  Mon Mar 18 23:24:27 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF721F8A52 for ; Mon, 18 Mar 2013 23:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.219
X-Spam-Level: 
X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=-0.299,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=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 OfGhmkAg6THC for ; Mon, 18 Mar 2013 23:24:26 -0700 (PDT)
Received: from p2322.superclick.com (50-200-68-226-static.hfc.comcastbusiness.net [50.200.68.226]) by ietfa.amsl.com (Postfix) with ESMTP id B495C21F8A18 for ; Mon, 18 Mar 2013 23:24:26 -0700 (PDT)
Received: from Flemmings-MacBook-Pro.local ([172.20.6.116]) by p2322.superclick.com (8.13.1/8.13.1) with ESMTP id r2J6OQLs006995 for ; Mon, 18 Mar 2013 23:24:26 -0700
Message-ID: <5148049B.6090205@cisco.com>
Date: Tue, 19 Mar 2013 02:24:27 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 06:24:27 -0000

Greetings

As you may have seen, there has recently been some list discussion on 
the "connection data capability" defined in 
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in 
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability 
negotiation capabilities for what amounts to the "c=" line in regular 
SDP, and as such enables negotiation of network type (such as "IN") and 
IP-address information (v4 and v6 addresses). The Standards Track 
mechanism for negotiating and determining alternative IP-address 
information today is ICE, and hence the draft currently includes the 
following wording:

The 'ccap' capability attribute is intended to
    be used only when there is no other mechanism available for
    negotiating alternative connection address information, such as when
    the  is different among the alternative addresses (e.g.
    "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
    situations where an existing mechanism (such as Interactive
    Connectivity Establishment (ICE) [RFC5245]) can be used to select
    between different connection addresses (e.g.  "IP4" and "IP6" or
    different IP addresses within the same IP address family).


The above text has led to some confusion as to exactly when and what 
"ccap" can be used for. More specifically, is it/should it ever be 
allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under 
what circumstances ?

If you have an opinion, please let us know.

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that 
dependency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be 
generally useful in line with the overall capability negotiation 
framework (as opposed to targeted at one specific use case with one 
specific value)
- There are scenarios where ICE cannot be used, even if implemented 
(e.g. ice-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of 
ICE support


Thanks

-- Flemming


From abegen@cisco.com  Mon Mar 18 23:49:22 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7421F88DB for ; Mon, 18 Mar 2013 23:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level: 
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 A58N5I+R+G5o for ; Mon, 18 Mar 2013 23:49:21 -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 3F55F21F851F for ; Mon, 18 Mar 2013 23:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9898; q=dns/txt; s=iport; t=1363675761; x=1364885361; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f9KEy9Yz5Usn3YoqnLkjfnRGLnYOdEekBAzQwoxYKI4=; b=M4M3RZPaF/x5I0jjEBnOnlMEA1dlNZJbJyGF8TDnW3noN3vmTE5AnXFb w4Mfjt4BzVd6IAfGcO1BOCQJAPBGkXWzTiBMuyp23G0MQ37LJ7zvLS0CO jAEepgStbEh7UQ8Y9r6LeCOc0KmYASgopUPmHj6BNBZ9fB184rCyieSX9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAB8JSFGtJV2d/2dsb2JhbABDDoQzg228dWlzFnSCJAEBAQMBIxFFDAYBCA4DAwECAQICBiACBDAVCAgCBA4FCIgGBgELr2mCQJAdgSONOgIWEAsHBoInMmEDkxiEZY9jgks/gig
X-IronPort-AV: E=Sophos;i="4.84,870,1355097600"; d="scan'208";a="188936906"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2013 06:49:20 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2J6nKEC024576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 06:49:20 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 01:49:20 -0500
From: "Ali C. Begen (abegen)" 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] The rtp-duplication related drafts
Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HJg41yeAgAAFCQCAAA8mgIAACswAgAW/cQCAbseDAA==
Date: Tue, 19 Mar 2013 06:48:57 +0000
Message-ID: 
In-Reply-To: <50EB2AD0.1080701@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.61.103.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D10F45FE4F43040B05A7D2E9D0D8346@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" 
Subject: Re: [MMUSIC] The rtp-duplication related drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 06:49:22 -0000

KFBpY2tpbmcgdXAgdGhpcyBvbGQgdGhyZWFkIGFzIEkgYW0gcGxhbm5pbmcgdG8gcmV2aXNlIGFs
bCB0aGUgZHVwbGljYXRpb24NCnJlbGF0ZWQgZHJhZnRzIHNob3J0bHkpDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQu
ZWR1Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDcsIDIwMTMgMTA6MDYgUE0NClRvOiAiQWxpIEMu
IEJlZ2VuIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCkNjOiAibW11c2ljQGlldGYub3JnIiA8bW11c2lj
QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFRoZSBydHAtZHVwbGljYXRpb24gcmVs
YXRlZCBkcmFmdHMNCg0KPk9uIDEvMy8xMyAxMToyMCBQTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4p
IHdyb3RlOg0KPj4NCj4+IE9uIEphbiAzLCAyMDEzLCBhdCAxMDo0MSBQTSwgUGF1bCBLeXppdmF0
IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPj4NCj4+PiBPbiAxLzMvMTMgOTo0NyBQ
TSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4+PiBUaGFua3MgZm9yIHRoZSByZXZp
ZXcuDQo+Pj4+DQo+Pj4+IE9uIEphbiAzLCAyMDEzLCBhdCA5OjI5IFBNLCBQYXVsIEt5eml2YXQg
PHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+Pj4+IEFsaSwNCj4+
Pj4+DQo+Pj4+PiBPbiAxLzMvMTMgNTozMSBQTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3Rl
Og0KPj4+Pj4+IEhpIGV2ZXJ5b25lLA0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIGZvbGxvd2luZyB0d28g
ZHJhZnRzIGhhdmUgYmVlbiBhZG9wdGVkIGJ5IE1NVVNJQyBhIHdoaWxlIGFnbw0KPj4+Pj4+YW5k
IHRoZSBtYWluIGRyYWZ0IGRpc2N1c3NpbmcgdGhlIFJUUCBkdXBsaWNhdGlvbiBpc3N1ZXMgaXMg
YmVpbmcNCj4+Pj4+PmZpbmFsaXplZCBpbiBBVlRFWFQgKHRoaXMgd2FzIGFsc28gYWRvcHRlZCBh
cyBhIFdHIGl0ZW0gYSB3aGlsZQ0KPj4+Pj4+YWdvKS4gSXQgaXMgc2ltcGx5IHdhaXRpbmcgZm9y
IHRoZSBXRyB0byBtYWtlIGEgZGVjaXNpb24gb24gdGhlDQo+Pj4+Pj5zcmNuYW1lIHByb3Bvc2Fs
Lg0KPj4+Pj4+DQo+Pj4+Pj4gDQo+Pj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWlldGYtbW11c2ljLWRlbGF5ZWQtZHVwbGljYXRpb24NCj4+Pj4+Pi8NCj4+Pj4+PiAN
Cj4+Pj4+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMt
ZHVwbGljYXRpb24tZ3JvdXBpbg0KPj4+Pj4+Zy8NCj4+Pj4+DQo+Pj4+PiBJIGhhdmUgYSBxdWVz
dGlvbiBhYm91dCB0aGVzZToNCj4+Pj4+DQo+Pj4+PiBFYWNoIGV4YW1wbGUgc2hvd3Mgb25seSBv
bmUgZ3JvdXAuIEJ1dCBjb3VsZG4ndCB0aGVyZSBiZSBtdWx0aXBsZQ0KPj4+Pj5kdXBsaWNhdGlv
biBncm91cHM/DQo+Pj4+Pg0KPj4+PiBUaGVyZSBjb3VsZCBiZS4NCj4+Pj4NCj4+Pj4+IElmIHNv
LCB0aGUgY3VycmVudCBwcm9wb3NhbCBoYXMgbm8gbWVjaGFuaXNtIGZvciBzcGVjaWZ5aW5nIHNl
cGFyYXRlDQo+Pj4+PmR1cGxpY2F0aW9uLWRlbGF5IGZvciBlYWNoIGdyb3VwLg0KPj4+Pj4NCj4+
Pj4NCj4+Pj4gYT1kdXBsaWNhdGlvbi1kZWxheTpYIGNvdWxkIGJlIHNwZWNpZmllZCBpbiBlYWNo
IG1lZGlhIHNlc3Npb24uIEZvcg0KPj4+PmV4YW1wbGU6DQo+Pj4+DQo+Pj4+IAlhPXJ0cG1hcDox
MDAgTVAyVC85MDAwMA0KPj4+PiAgICAgICAgICBhPXNzcmM6MTAwMCBjbmFtZTpjaDFAZXhhbXBs
ZS5jb20NCj4+Pj4gICAgICAgICAgYT1zc3JjOjEwMTAgY25hbWU6Y2gxQGV4YW1wbGUuY29tDQo+
Pj4+ICAgICAgICAgIGE9c3NyYy1ncm91cDpEVVAgMTAwMCAxMDEwDQo+Pj4+ICAgICAgICAgIGE9
ZHVwbGljYXRpb24tZGVsYXk6MTAwDQo+Pj4+ICAgICAgICAgIGE9bWlkOkdyb3VwMQ0KPj4+PiAJ
YT1ydHBtYXA6MTAxIE1QMlQvOTAwMDANCj4+Pj4gICAgICAgICAgYT1zc3JjOjIwMDAgY25hbWU6
Y2gyQGV4YW1wbGUuY29tDQo+Pj4+ICAgICAgICAgIGE9c3NyYzoyMDEwIGNuYW1lOmNoMkBleGFt
cGxlLmNvbQ0KPj4+PiAgICAgICAgICBhPXNzcmMtZ3JvdXA6RFVQIDIwMDAgMjAxMA0KPj4+PiAg
ICAgICAgICBhPWR1cGxpY2F0aW9uLWRlbGF5OjE1MA0KPj4+PiAgICAgICAgICBhPW1pZDpHcm91
cDINCj4+Pg0KPj4+IFRoaXMgbWFrZXMgdGhlIGF0dHJpYnV0ZXMgdmVyeSBvcmRlciBkZXBlbmRl
bnQuIElmIHRoaXMgaXMgaW50ZW5kZWQsDQo+Pj50aGVuIEkgdGhpbmsgeW91IG5lZWQgbW9yZSB3
b3JkcyB0byBzYXkgdGhhdC4gQ3VycmVudGx5IGl0IHNheXM6DQo+Pj4NCj4+PiAgICBJZiB1c2Vk
IGFzIGEgbWVkaWEtbGV2ZWwNCj4+PiAgICBhdHRyaWJ1dGUsIGl0IE1VU1QgYmUgdXNlZCB3aXRo
IHRoZSAnc3NyYy1ncm91cCcgYXR0cmlidXRlIGFuZCAiRFVQIg0KPj4+ICAgIGdyb3VwaW5nIHNl
bWFudGljcy4uLg0KPj4NCj4+IE15IG1pc3Rha2UsIGRpZCBub3QgY29weS9wYXN0ZSB0aGUgd2hv
bGUgdGhpbmcuDQo+Pg0KPj4gCW09dmlkZW8gMzAwMDAgUlRQL0FWUCAxMDANCj4+ICAgICAgICAg
IGM9SU4gSVA0IDIzMy4yNTIuMC4xLzEyNw0KPj4gICAgICAgICAgYT1zb3VyY2UtZmlsdGVyOmlu
Y2wgSU4gSVA0IDIzMy4yNTIuMC4xIDE5OC41MS4xMDAuMQ0KPj4gICAgICAgICAgYT1ydHBtYXA6
MTAwIE1QMlQvOTAwMDANCj4+ICAgICAgICAgIGE9c3NyYzoxMDAwIGNuYW1lOmNoMUBleGFtcGxl
LmNvbQ0KPj4gICAgICAgICAgYT1zc3JjOjEwMTAgY25hbWU6Y2gxQGV4YW1wbGUuY29tDQo+PiAg
ICAgICAgICBhPXNzcmMtZ3JvdXA6RFVQIDEwMDAgMTAxMA0KPj4gICAgICAgICAgYT1kdXBsaWNh
dGlvbi1kZWxheToxMDANCj4+ICAgICAgICAgIGE9bWlkOkdyb3VwMQ0KPj4gCW09dmlkZW8gNDAw
MDAgUlRQL0FWUCAxMDENCj4+ICAgICAgICAgIGM9SU4gSVA0IDIzMy4yNTIuMC4yLzEyNw0KPj4g
ICAgICAgICAgYT1zb3VyY2UtZmlsdGVyOmluY2wgSU4gSVA0IDIzMy4yNTIuMC4yIDE5OC41MS4x
MDAuMQ0KPj4gICAgICAgICAgYT1ydHBtYXA6MTAxIE1QMlQvOTAwMDANCj4+ICAgICAgICAgIGE9
c3NyYzoyMDAwIGNuYW1lOmNoMkBleGFtcGxlLmNvbQ0KPj4gICAgICAgICAgYT1zc3JjOjIwMTAg
Y25hbWU6Y2gyQGV4YW1wbGUuY29tDQo+PiAgICAgICAgICBhPXNzcmMtZ3JvdXA6RFVQIDIwMDAg
MjAxMA0KPj4gICAgICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheToxNTANCj4+ICAgICAgICAgIGE9
bWlkOkdyb3VwMg0KPj4NCj4+IHNvIHRoZXJlIGlzIG9uZSBkdXBsaWNhdGlvbi1kZWxheSBhdHRy
aWJ1dGUgaW4gZWFjaCBtZWRpYSBzZXNzaW9uDQo+PihzcGVjaWZpZWQgYnkgYSBtPSBsaW5lKS4g
SXQgZG9lcyBub3QgbWF0dGVyIHdoZXRoZXIgaXQgaXMgYmVmb3JlIG9yDQo+PmFmdGVyIHRoZSBz
c3JjLWdyb3VwIGxpbmUuIEl0IGlzIE9LIGFzIGxvbmcgYXMgaXQgaXMgc29tZXdoZXJlIGJlZm9y
ZQ0KPj50aGUgbmV4dCBtIGxpbmUuDQo+DQo+QnV0IHRoZW4sIGR1cGxpY2F0aW9uLWRlbGF5IGFw
cGxpZXMgdG8gYT1zc3JjLWdyb3VwOkRVUCBncm91cHMgd2l0aGluDQo+dGhhdCBtZWRpYSBzZWN0
aW9uLiBZb3UgY291bGQgaGF2ZSB0d28gZ3JvdXBzIG9mIHNzcmNzIGluIHRoZXJlLiBTbyB0aGUN
Cj5wcm9ibGVtIGlzIHRoZSBzYW1lIGFzIHRoZSBwcm9ibGVtIGFjcm9zcyBkaWZmZXJlbnQgbS1s
aW5lcy4gRS5nLg0KPg0KPgltPXZpZGVvIDMwMDAwIFJUUC9BVlAgMTAwDQo+ICAgICAgICAgYz1J
TiBJUDQgMjMzLjI1Mi4wLjEvMTI3DQo+ICAgICAgICAgYT1zb3VyY2UtZmlsdGVyOmluY2wgSU4g
SVA0IDIzMy4yNTIuMC4xIDE5OC41MS4xMDAuMQ0KPiAgICAgICAgIGE9cnRwbWFwOjEwMCBNUDJU
LzkwMDAwDQo+ICAgICAgICAgYT1zc3JjOjEwMDAgY25hbWU6Y2gxQGV4YW1wbGUuY29tDQo+ICAg
ICAgICAgYT1zc3JjOjEwMTAgY25hbWU6Y2gxQGV4YW1wbGUuY29tDQo+ICAgICAgICAgYT1zc3Jj
OjEwMjAgY25hbWU6Y2gxQGV4YW1wbGUuY29tDQo+ICAgICAgICAgYT1zc3JjOjEwMzAgY25hbWU6
Y2gxQGV4YW1wbGUuY29tDQo+ICAgICAgICAgYT1zc3JjLWdyb3VwOkRVUCAxMDAwIDEwMTANCj4g
ICAgICAgICBhPWR1cGxpY2F0aW9uLWRlbGF5OjEwMA0KPiAgICAgICAgIGE9c3NyYy1ncm91cDpE
VVAgMTAyMCAxMDMwDQo+ICAgICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheToyMDANCj4JbT12aWRl
byA0MDAwMCBSVFAvQVZQIDEwMQ0KPiAgICAgICAgIGM9SU4gSVA0IDIzMy4yNTIuMC4yLzEyNw0K
PiAgICAgICAgIGE9c291cmNlLWZpbHRlcjppbmNsIElOIElQNCAyMzMuMjUyLjAuMiAxOTguNTEu
MTAwLjENCj4gICAgICAgICBhPXJ0cG1hcDoxMDEgTVAyVC85MDAwMA0KPiAgICAgICAgIGE9c3Ny
YzoyMDAwIGNuYW1lOmNoMkBleGFtcGxlLmNvbQ0KPiAgICAgICAgIGE9c3NyYzoyMDEwIGNuYW1l
OmNoMkBleGFtcGxlLmNvbQ0KPiAgICAgICAgIGE9c3NyYy1ncm91cDpEVVAgMjAwMCAyMDEwDQo+
ICAgICAgICAgYT1zc3JjOjIwMjAgY25hbWU6Y2gyQGV4YW1wbGUuY29tDQo+ICAgICAgICAgYT1z
c3JjOjIwMzAgY25hbWU6Y2gyQGV4YW1wbGUuY29tDQo+ICAgICAgICAgYT1zc3JjLWdyb3VwOkRV
UCAyMDIwIDIwMzANCj4gICAgICAgICBhPWR1cGxpY2F0aW9uLWRlbGF5OjI1MA0KPg0KPiBGcm9t
IHdoYXQgeW91IHNheSwgdGhlIHR3byBkdXBsaWNhdGlvbi1kZWxheSBhdHRyaWJ1dGVzIGluIG9u
ZSBtZWRpYQ0KPnNlY3Rpb24gd291bGQgbWFrZSBubyBzZW5zZS4NCg0KDQpGcmFua2x5LCBJIGNh
bid0IHRoaW5rIG9mIGFuIGFwcGxpY2F0aW9uIHdoZXJlIHlvdSB3b3VsZCBoYXZlIG11bHRpLXBh
aXINCnN0cmVhbXMgaW4gYW4gUlRQIHNlc3Npb24gYW5kIHJlcXVpcmUgZGlmZmVyZW50IGR1cGxp
Y2F0aW9uIGRlbGF5cyBiZXR3ZWVuDQplYWNoIHBhaXIuIFNvLCB0aGF0J3Mgd2h5IEkgbmV2ZXIg
Ym90aGVyZWQgd2l0aCB0aGlzLiBEb2VzIGFueWJvZHkNCmFjdHVhbGx5IG5lZWQgdGhpcyB1c2Ug
Y2FzZT8gT3RoZXJ3aXNlLCBJIHRoaW5rIHdlIGNhbiBpZ25vcmUgaXQgYW5kIGxldA0KYWxsIHRo
ZSBwYWlycyB1c2UgdGhlIHNhbWUgZGVsYXkuDQoNCg0KPg0KPj4+IFdoYXQgZG9lcyAidXNlZCB3
aXRoIiBtZWFuPyBJIGFzc3VtZWQgaXQgc2ltcGx5IG1lYW50IHRoYXQgYm90aA0KPj4+YXR0cmli
dXRlcyBoYWQgdG8gYmUgcHJlc2VudCBpbiB0aGUgbWVkaWEgc2VjdGlvbi4gQnV0IHdoYXQgeW91
IGFyZQ0KPj4+c2F5aW5nIG5vdyBzYXlzIHRoYXQgdGhlcmUgaXMgc29tZSB2ZXJ5IHNwZWNpZmlj
IG9yZGVyaW5nIHJlcXVpcmVkLg0KPj4+RS5nLiB0aGF0IHRoZSBhPWR1cGxpY2FhdGlvbi1kZWxh
eSBtdXN0IGZvbGxvdyB0aGUgYT1zc3JjLWdyb3VwOkRVUCB0bw0KPj4+d2hpY2ggaXQgYXBwbGll
cywgYW5kIHByZWNlZGUgYW55IG90aGVyIGE9c3NyYy1ncm91cDpEVVAuIFRoaXMgaXMNCj4+PnBv
c3NpYmxlLCBidXQgdWdseSB0byBzcGVjaWZ5Lg0KPj4NCj4+IEkgaG9wZSBpdCBpcyBjbGVhciBu
b3c/DQo+Pg0KPj4+DQo+Pj4+IChUaGUgU1NSQyBuZWVkIG5vdCBiZSBkaWZmZXJlbnQgYXMgU1NS
QyBvbmx5IG5lZWQgdG8gYmUgdW5pcXVlIHdpdGhpbg0KPj4+PmVhY2ggbWVkaWEgc2Vzc2lvbikN
Cj4+Pj4NCj4+Pj4gRm9yIHRoZSBub24tc3NyYyBncm91cGluZywgeW91ciBjb21tZW50IGhvbGRz
LiBJdCBkb2VzIG5vdCBzdXBwb3J0DQo+Pj4+c3BlY2lmeWluZyBkaWZmZXJlbnQgZGVsYXkgdmFs
dWVzIGZvciBkaWZmZXJlbnQgZ3JvdXBzLiBEbyB5b3UgdGhpbmsNCj4+Pj53ZSBzaG91bGQgc3Vw
cG9ydCBkaXN0aW5jdCBkZWxheSB2YWx1ZXMgZm9yIGRpZmZlcmVudCBncm91cHMgKHdoaWNoDQo+
Pj4+cHJvYmFibHkgbWVhbnMgZHVwbGljYXRpb24tZGVsYXkgYXR0cmlidXRlIGhhcyB0byBiZSBt
ZWRpYS1sZXZlbCBvbmx5KT8NCj4NCj5XZWxsLCBmb3IgdGhlIG5vbi1zc3JjIGdyb3VwaW5nIHlv
dSBjb3VsZCBwdXQgdGhlIGdyb3VwIG5hbWUgaW4gdGhlDQo+YT1kdXBsaWNhdGlvbi1kZWxheSBh
dHRyaWJ1dGUgdmFsdWUuDQoNClRoZXJlIGlzIG5vIGdyb3VwIG5hbWUgaW4gdGhlICJhPWdyb3Vw
OkRVUCIgbGluZSwganVzdCB0aGUgbGlzdCBvZiBtaWRzKQ0Kc28gdGhlcmUgaXMgbm8gdW5pcXVl
IGlkZW50aWZpZXIgZm9yIGVhY2ggZ3JvdXAuIEFueXdheSwgSSB0aG91Z2h0IG9mIHRoaXMNCmFu
ZCBob25lc3RseSwgSSB0aGluayB3ZSBiZXR0ZXIgc3RhdGUgdGhpcyAibGltaXRhdGlvbiIgZXhw
bGljaXRseSBhbmQNCmZvcmJpZCB0aGUgdXNlIG9mIGRpZmZlcmVudCBzZXNzaW9uLWxldmVsIGRl
bGF5cyBpbiBhIHNpbmdsZSBTRFANCmRlc2NyaXB0aW9uLiBJbiBvdGhlciB3b3JkcywgaWYgdGhl
cmUgd2lsbCBiZSBhIHNlc3Npb24tbGV2ZWwgZGVsYXkNCmF0dHJpYnV0ZSwgaXQgd2lsbCBhcHBs
eSB0byBhbGwgRFVQIGdyb3Vwcy4gSWYgeW91IG5lZWQgZGlmZmVyZW50DQpkdXBsaWNhdGlvbiBk
ZWxheXMgZm9yIGRpZmZlcmVudCBncm91cHMsIHRoZW4gc2ltcGx5IHVzZSBkaWZmZXJlbnQgU0RQ
DQpkZXNjcmlwdGlvbnMgZm9yIHRoYXQgKG9yIHVzZSB0aGUgbWVkaWEtbGV2ZWwgZGVsYXkgYXR0
cmlidXRlKS4NCg0KPg0KPkFuZCBmb3IgdGhlIHNzcmMtZ3JvdXBpbmcgY2FzZSB5b3UgY291bGQg
cHV0IG9uZSBvZiB0aGUgZ3JvdXBlZCBzc3JjcyBpbg0KPnRoZSBhPWR1cGxpY2F0aW9uLWRlbGF5
IGF0dHIgdmFsdWUuDQoNCkFzIEkgc2FpZCBhYm92ZSwgSSBjYW4ndCB0aGluayBvZiBhbnkgdXNl
IGNhc2Ugd2hlcmUgdGhpcyB3aWxsIGJlDQpuZWVkZWQvdXNlZnVsLiBJZiB0aGVyZSBhcmUgbXVs
dGlwbGUgU1NSQyBwYWlyaW5ncyBpbnNpZGUgYW4gbSBsaW5lLCB0aGV5DQpzaW1wbHkgaGF2ZSB0
byB1c2UgdGhlIHNhbWUgZGVsYXkgdmFsdWUuIEkgY2FuIGNsYXJpZnkgdGhpcyBpbiB0aGUgZHJh
ZnQuDQoNCk15IGdvYWwgaXMgdG8gY29tcGxldGUgdGhpcyB3b3JrIGZvciB0aGUgdXNlIGNhc2Vz
IHdlIG5lZWQgbm93LiBGb3INCnBvc3NpYmxlIGJ1dCByYXRoZXIgdW5yZWFsaXN0aWMgdXNlIGNh
c2VzLCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZA0KY29tcGxpY2F0ZSB0aGUgYXR0cmlidXRlLiBQ
bGVhc2UgY29tbWVudCBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGVzZQ0KY2hhbmdlcy4NCg0KVGhh
bmtzLA0KLWFjYmVnZW4NCg0KPg0KPglUaGFua3MsDQo+CVBhdWwNCj4NCj4NCg0KDQo=

From harald@alvestrand.no  Tue Mar 19 02:03:16 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2E621F88A0; Tue, 19 Mar 2013 02:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.498
X-Spam-Level: 
X-Spam-Status: No, score=-109.498 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 oDjY2lRMiC85; Tue, 19 Mar 2013 02:03:14 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2064321F88C6; Tue, 19 Mar 2013 02:03:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E48E139E16F; Tue, 19 Mar 2013 10:03:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jhcvenrtCol; Tue, 19 Mar 2013 10:03:11 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1A9FC39E04C; Tue, 19 Mar 2013 10:03:11 +0100 (CET)
Message-ID: <514829CE.4010004@alvestrand.no>
Date: Tue, 19 Mar 2013 10:03:10 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" 
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
Content-Type: multipart/alternative; boundary="------------070403010200000102090802"
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 09:03:16 -0000

This is a multi-part message in MIME format.
--------------070403010200000102090802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
>
> Does bundle imply anything beyond a simple port override of the m-line 
> port? If not, then why not just directly signal the port override in 
> an attribute without any grouping semantics?
>

No, it's not just a port override.

BUNDLE shoves things into the same RTP session, which means that one has 
to obey the rules for being in the same RTP session:
- Security done consistently
- RTCP-mux done consistently
- No SSRC collision
- No payload type collision
So it's a good deal more than just a port override.

Magnus argued in favour of a solution that inserted a multiplex layer, 
so that one could use the same ports but still have stuff in different 
RTP sessions, but that did not appeal to many.

> Offer to mux audio and video on the same port:
>
> m=audio 10000 RTP/AVP 0
>
> m=video 10002 RTP/AVP 31
>
> a=port 10000
>
> i=I really want 10000, but lied on the m-line for fear of confusing 
> you. Confused yet?
>
> Answer supports the port override attribute and agrees to mux audio 
> and video:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40000 RTP/AVP 31
>
> a=port 40000
>
> ...so audio and video ports are 10000<->40000.
>
> Answer supports the port override attribute but doesn't want to demux 
> on his end:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40002 RTP/AVP 31
>
> a=port 40002
>
> ...so audio ports are 10000<->40000 and video ports are 10000<->40002.
>
> Answer doesn't support the port override attribute, or doesn't want 
> either end to mux:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40002 RTP/AVP 31
>
> ...so audio ports are 10000<->40000 and video ports are 10002<->40002.
>
> Either end can re-offer without lies about ports on the m-line after 
> confirming the peer is not confused by muxing, if they want to avoid 
> confusing intermediaries.
>
> Has this approach been tried yet? Dismissed?
>
> Mo
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------070403010200000102090802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/19/2013 05:19 AM, Mo Zanaty
      (mzanaty) wrote:

    

    

      
      
      
      

        
Does bundle imply anything beyond a simple
          port override of the m-line port? If not, then why not just
          directly signal the port override in an attribute without any
          grouping semantics?

      

    

    

    No, it's not just a port override.

    

    BUNDLE shoves things into the same RTP session, which means that one
    has to obey the rules for being in the same RTP session:

    - Security done consistently

    - RTCP-mux done consistently

    - No SSRC collision

    - No payload type collision

    So it's a good deal more than just a port override.

    

    Magnus argued in favour of a solution that inserted a multiplex
    layer, so that one could use the same ports but still have stuff in
    different RTP sessions, but that did not appeal to many.

    

    

      

        

        
 

        
Offer to mux audio and video on the same
          port:

        
m=audio 10000 RTP/AVP 0

        
m=video 10002 RTP/AVP 31

        
a=port 10000

        
i=I really want 10000, but lied on the
          m-line for fear of confusing you. Confused yet?

        
 

        
Answer supports the port override attribute
          and agrees to mux audio and video:

        
m=audio 40000 RTP/AVP 0

        
m=video 40000 RTP/AVP 31

        
a=port 40000

        
…so audio and video ports are
          10000<->40000.

        
 

        
Answer supports the port override attribute
          but doesn’t want to demux on his end:

        
m=audio 40000 RTP/AVP 0

        
m=video 40002 RTP/AVP 31

        
a=port 40002

        
…so audio ports are 10000<->40000 and
          video ports are 10000<->40002.

        
 

        
Answer doesn’t support the port override
          attribute, or doesn’t want either end to mux:

        
m=audio 40000 RTP/AVP 0

        
m=video 40002 RTP/AVP 31

        
…so audio ports are 10000<->40000 and
          video ports are 10002<->40002.

        
 

        
Either end can re-offer without lies about
          ports on the m-line after confirming the peer is not confused
          by muxing, if they want to avoid confusing intermediaries.

        
 

        
Has this approach been tried yet?
          Dismissed?

        
 

        
Mo

        
 

      

      

      

      

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


    

    

  


--------------070403010200000102090802--

From prvs=7790f47612=aallen@blackberry.com  Tue Mar 19 05:27:45 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363E821F8951 for ; Tue, 19 Mar 2013 05:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.285
X-Spam-Level: 
X-Spam-Status: No, score=-4.285 tagged_above=-999 required=5 tests=[AWL=0.318,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396,  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 9H0lWvmMssoC for ; Tue, 19 Mar 2013 05:27:44 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7EA21F89D8 for ; Tue, 19 Mar 2013 05:27:44 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-06-514859b05d03
Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CC.49.13213.0B958415; Tue, 19 Mar 2013 07:27:29 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Tue, 19 Mar 2013 07:27:28 -0500
From: Andrew Allen 
To: "fandreas@cisco.com" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJGputCjuJ1Z4YUGk72Cnji+Gkpis8WYH
Date: Tue, 19 Mar 2013 12:27:27 +0000
Message-ID: 
In-Reply-To: <5148049B.6090205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsXC5Zyvq7sx0iPQ4OYSdov3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEU1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifbKvmkpifmKAQUZZYl JlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk /JTMvHRbJc9gf10LC1NLXUMlO92ETp6M7V8usRU0ileseTSbtYHxi1AXIyeHhICJxL83jUwQ tpjEhXvr2boYuTiEBNqYJGb3TmGEcDYzSiy68I4ZpIpNQEti/+HpYB0iAiESVzYuYwWxhQUq JF51rGeBiFdKvOj8CBTnALKNJH7dtwEJswioSsw70MQGYvMKeEgs+nMDzOYU0JToOd4E1soI dMT3U2vAxjMLiEvcejIf6jgBiSV7zjND2KISLx//Y4WwFSX+7v3OClGvJ3Fj6hQ2CFtbYtnC 18wQuwQlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyCuRnFBmaGyXnJekWZuXp5qSWbGEFR 76hhsIPx/XuLQ4wCHIxKPLyrvT0ChVgTy4orcw8xSnAwK4nwxrkChXhTEiurUovy44tKc1KL DzG6AkNiIrMUd3I+MCHllcQbGxjg5iiJ85ZpOgUKCaQDk0x2ampBahHMHCYOTpA9XFIixcBU kVqUWFqSEQ9KaPHFwJQm1cDopZcrpz/5cvSJtUcaxfXsfv17/N7lyOVPruXmF26fyvJg+z2j WqWt+tHCN653c+e93BD95qWPRfeBw7eaj1bpXNwa9ueO41XGOXFhkfHc3683Ked1pyleujJv r5/rtL6i5GpbJz7reBPlOzt9U7a0H9PbfOyvLmug0NVYnnPJT6c1xN/jDtVSYinOSDTUYi4q TgQA55ES9DsDAAA=
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 12:27:45 -0000

Flemming

CCAP is the essential feature required by 3GPP. It is used by 3GPP to negoti=
ate the use of CS SDP to set up a CS call as an alternative to a packet swit=
ched audio stream.

Andrew

----- Original Message -----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, March 19, 2013 01:24 AM Central Standard Time=0A=
To: mmusic 
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-=
ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

As you may have seen, there has recently been some list discussion on 
the "connection data capability" defined in 
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in 
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability 
negotiation capabilities for what amounts to the "c=3D" line in regular 
SDP, and as such enables negotiation of network type (such as "IN") and 
IP-address information (v4 and v6 addresses). The Standards Track 
mechanism for negotiating and determining alternative IP-address 
information today is ICE, and hence the draft currently includes the 
following wording:

The 'ccap' capability attribute is intended to
    be used only when there is no other mechanism available for
    negotiating alternative connection address information, such as when
    the  is different among the alternative addresses (e.g.
    "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
    situations where an existing mechanism (such as Interactive
    Connectivity Establishment (ICE) [RFC5245]) can be used to select
    between different connection addresses (e.g.  "IP4" and "IP6" or
    different IP addresses within the same IP address family).


The above text has led to some confusion as to exactly when and what 
"ccap" can be used for. More specifically, is it/should it ever be 
allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under 
what circumstances ?

If you have an opinion, please let us know.

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that 
dependency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be 
generally useful in line with the overall capability negotiation 
framework (as opposed to targeted at one specific use case with one 
specific value)
- There are scenarios where ICE cannot be used, even if implemented 
(e.g. ice-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of 
ICE support


Thanks

-- Flemming

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From pkyzivat@alum.mit.edu  Tue Mar 19 07:02:28 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0721B21F8BBB for ; Tue, 19 Mar 2013 07:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.163
X-Spam-Level: 
X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=-0.600,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_12=0.6, 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 1Mc0DQq6qz1E for ; Tue, 19 Mar 2013 07:02:27 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id C564621F8BDE for ; Tue, 19 Mar 2013 07:02:26 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id DPB81l0091GhbT85FS2SiS; Tue, 19 Mar 2013 14:02:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id DS2R1l01D3ZTu2S3TS2SHf; Tue, 19 Mar 2013 14:02:26 +0000
Message-ID: <51486FF1.6010808@alum.mit.edu>
Date: Tue, 19 Mar 2013 22:02:25 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" 
References: 
In-Reply-To: 
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=1363701746; bh=JGCse8WtDIGXBjUIakhnusR3usAOaixLQQIdAjno3Yo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k0wqiuaDcubszSw0oy6Y0/rCxM6DOC2h6FE4pa5GmhZ9J5j5hvPra2kNFtfDYDAL9 LNcfBkj4k0ePykYnNUwW4wYG+pMR3GzMnlu7PMxZirX3d2G0RJrLLoatHdtsjpS8aW PIR4a2LrpMHsi7QOrqKEMozkRugoufHYUSAztmI6pVCQuQtUrR9QQRz5vRifa3J5Rh Gss518t/Ymu6wQ3SVvbOHu+g5THeaqLWT6+kmiEVSEmr/O3/wmPIppYyKphECzo8cD pEPqN2meV8ZJ5HofysJ/Jwima122fjF0CcJHaWtClctxuuhL1QHlolXrh54GkJXQCT b7TaA00SfC3Aw==
Cc: "" 
Subject: Re: [MMUSIC] The rtp-duplication related drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 14:02:28 -0000

Ali,

In my review I simply identified areas that seemed incomplete/ambiguous.
The existing syntax is inadequate to represent a full range of 
possibilities in the presence of multiple duplication groups.

I don't have any particular preferences here.
While I suggested some possible syntax changes that would allow coverage 
of all possibilities, I am in no position to know if the added cases 
that would cover make any sense in practice. I am satisfied to accept 
your judgement that they don't.

If that is so, then simply pointing out that the other cases considered 
out of scope will satisfy me.

	Thanks,
	Paul

On 3/19/13 2:48 PM, Ali C. Begen (abegen) wrote:
> (Picking up this old thread as I am planning to revise all the duplication
> related drafts shortly)
>
>
> -----Original Message-----
> From: Paul Kyzivat 
> Date: Monday, January 7, 2013 10:06 PM
> To: "Ali C. Begen" 
> Cc: "mmusic@ietf.org" 
> Subject: Re: [MMUSIC] The rtp-duplication related drafts
>
>> On 1/3/13 11:20 PM, Ali C. Begen (abegen) wrote:
>>>
>>> On Jan 3, 2013, at 10:41 PM, Paul Kyzivat  wrote:
>>>
>>>> On 1/3/13 9:47 PM, Ali C. Begen (abegen) wrote:
>>>>> Thanks for the review.
>>>>>
>>>>> On Jan 3, 2013, at 9:29 PM, Paul Kyzivat 
>>>>> wrote:
>>>>>
>>>>>> Ali,
>>>>>>
>>>>>> On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> The following two drafts have been adopted by MMUSIC a while ago
>>>>>>> and the main draft discussing the RTP duplication issues is being
>>>>>>> finalized in AVTEXT (this was also adopted as a WG item a while
>>>>>>> ago). It is simply waiting for the WG to make a decision on the
>>>>>>> srcname proposal.
>>>>>>>
>>>>>>>
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication
>>>>>>> /
>>>>>>>
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-groupin
>>>>>>> g/
>>>>>>
>>>>>> I have a question about these:
>>>>>>
>>>>>> Each example shows only one group. But couldn't there be multiple
>>>>>> duplication groups?
>>>>>>
>>>>> There could be.
>>>>>
>>>>>> If so, the current proposal has no mechanism for specifying separate
>>>>>> duplication-delay for each group.
>>>>>>
>>>>>
>>>>> a=duplication-delay:X could be specified in each media session. For
>>>>> example:
>>>>>
>>>>> 	a=rtpmap:100 MP2T/90000
>>>>>           a=ssrc:1000 cname:ch1@example.com
>>>>>           a=ssrc:1010 cname:ch1@example.com
>>>>>           a=ssrc-group:DUP 1000 1010
>>>>>           a=duplication-delay:100
>>>>>           a=mid:Group1
>>>>> 	a=rtpmap:101 MP2T/90000
>>>>>           a=ssrc:2000 cname:ch2@example.com
>>>>>           a=ssrc:2010 cname:ch2@example.com
>>>>>           a=ssrc-group:DUP 2000 2010
>>>>>           a=duplication-delay:150
>>>>>           a=mid:Group2
>>>>
>>>> This makes the attributes very order dependent. If this is intended,
>>>> then I think you need more words to say that. Currently it says:
>>>>
>>>>     If used as a media-level
>>>>     attribute, it MUST be used with the 'ssrc-group' attribute and "DUP"
>>>>     grouping semantics...
>>>
>>> My mistake, did not copy/paste the whole thing.
>>>
>>> 	m=video 30000 RTP/AVP 100
>>>           c=IN IP4 233.252.0.1/127
>>>           a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
>>>           a=rtpmap:100 MP2T/90000
>>>           a=ssrc:1000 cname:ch1@example.com
>>>           a=ssrc:1010 cname:ch1@example.com
>>>           a=ssrc-group:DUP 1000 1010
>>>           a=duplication-delay:100
>>>           a=mid:Group1
>>> 	m=video 40000 RTP/AVP 101
>>>           c=IN IP4 233.252.0.2/127
>>>           a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
>>>           a=rtpmap:101 MP2T/90000
>>>           a=ssrc:2000 cname:ch2@example.com
>>>           a=ssrc:2010 cname:ch2@example.com
>>>           a=ssrc-group:DUP 2000 2010
>>>           a=duplication-delay:150
>>>           a=mid:Group2
>>>
>>> so there is one duplication-delay attribute in each media session
>>> (specified by a m= line). It does not matter whether it is before or
>>> after the ssrc-group line. It is OK as long as it is somewhere before
>>> the next m line.
>>
>> But then, duplication-delay applies to a=ssrc-group:DUP groups within
>> that media section. You could have two groups of ssrcs in there. So the
>> problem is the same as the problem across different m-lines. E.g.
>>
>> 	m=video 30000 RTP/AVP 100
>>          c=IN IP4 233.252.0.1/127
>>          a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
>>          a=rtpmap:100 MP2T/90000
>>          a=ssrc:1000 cname:ch1@example.com
>>          a=ssrc:1010 cname:ch1@example.com
>>          a=ssrc:1020 cname:ch1@example.com
>>          a=ssrc:1030 cname:ch1@example.com
>>          a=ssrc-group:DUP 1000 1010
>>          a=duplication-delay:100
>>          a=ssrc-group:DUP 1020 1030
>>          a=duplication-delay:200
>> 	m=video 40000 RTP/AVP 101
>>          c=IN IP4 233.252.0.2/127
>>          a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
>>          a=rtpmap:101 MP2T/90000
>>          a=ssrc:2000 cname:ch2@example.com
>>          a=ssrc:2010 cname:ch2@example.com
>>          a=ssrc-group:DUP 2000 2010
>>          a=ssrc:2020 cname:ch2@example.com
>>          a=ssrc:2030 cname:ch2@example.com
>>          a=ssrc-group:DUP 2020 2030
>>          a=duplication-delay:250
>>
>>  From what you say, the two duplication-delay attributes in one media
>> section would make no sense.
>
>
> Frankly, I can't think of an application where you would have multi-pair
> streams in an RTP session and require different duplication delays between
> each pair. So, that's why I never bothered with this. Does anybody
> actually need this use case? Otherwise, I think we can ignore it and let
> all the pairs use the same delay.
>
>
>>
>>>> What does "used with" mean? I assumed it simply meant that both
>>>> attributes had to be present in the media section. But what you are
>>>> saying now says that there is some very specific ordering required.
>>>> E.g. that the a=duplicaation-delay must follow the a=ssrc-group:DUP to
>>>> which it applies, and precede any other a=ssrc-group:DUP. This is
>>>> possible, but ugly to specify.
>>>
>>> I hope it is clear now?
>>>
>>>>
>>>>> (The SSRC need not be different as SSRC only need to be unique within
>>>>> each media session)
>>>>>
>>>>> For the non-ssrc grouping, your comment holds. It does not support
>>>>> specifying different delay values for different groups. Do you think
>>>>> we should support distinct delay values for different groups (which
>>>>> probably means duplication-delay attribute has to be media-level only)?
>>
>> Well, for the non-ssrc grouping you could put the group name in the
>> a=duplication-delay attribute value.
>
> There is no group name in the "a=group:DUP" line, just the list of mids)
> so there is no unique identifier for each group. Anyway, I thought of this
> and honestly, I think we better state this "limitation" explicitly and
> forbid the use of different session-level delays in a single SDP
> description. In other words, if there will be a session-level delay
> attribute, it will apply to all DUP groups. If you need different
> duplication delays for different groups, then simply use different SDP
> descriptions for that (or use the media-level delay attribute).
>
>>
>> And for the ssrc-grouping case you could put one of the grouped ssrcs in
>> the a=duplication-delay attr value.
>
> As I said above, I can't think of any use case where this will be
> needed/useful. If there are multiple SSRC pairings inside an m line, they
> simply have to use the same delay value. I can clarify this in the draft.
>
> My goal is to complete this work for the use cases we need now. For
> possible but rather unrealistic use cases, I don't think we should
> complicate the attribute. Please comment if you disagree with these
> changes.
>
> Thanks,
> -acbegen
>
>>
>> 	Thanks,
>> 	Paul
>>
>>
>
>


From btv1==79040205657==HKaplan@acmepacket.com  Tue Mar 19 07:22:29 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912321F8A6F for ; Tue, 19 Mar 2013 07:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level: 
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUyCyHiMQ5Ok for ; Tue, 19 Mar 2013 07:22:28 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 75EF721F8B74 for ; Tue, 19 Mar 2013 07:22:28 -0700 (PDT)
X-ASG-Debug-ID: 1363702945-03fc21726010f3890001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id wZgB69TeDcCJmbIx (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Mar 2013 10:22:25 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Tue, 19 Mar 2013 10:22:25 -0400
From: Hadriel Kaplan 
To: Andrew Allen 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-ASG-Orig-Subj: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJK0ttIOoBDZB2UmIZYImpYW3BA==
Date: Tue, 19 Mar 2013 14:22:25 +0000
Message-ID: <6290145A-C58E-47A8-B36F-43D066724370@acmepacket.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <07F26FA0E0DFFA4FA9C4F9CD7D089293@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363702945
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125647 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 14:22:56 -0000

On Mar 19, 2013, at 8:27 AM, Andrew Allen  wrote:

> CCAP is the essential feature required by 3GPP. It is used by 3GPP to neg=
otiate the use of CS SDP to set up a CS call as an alternative to a packet =
switched audio stream.

Does it also need to be able to go from CS to IP sometime during a call, or=
 once it's chosen to be CS it stays CS?

-hadriel


From mzanaty@cisco.com  Tue Mar 19 08:28:52 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BDF21F85F3; Tue, 19 Mar 2013 08:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 PprtoPGguo+d; Tue, 19 Mar 2013 08:28:49 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9216521F85E8; Tue, 19 Mar 2013 08:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13580; q=dns/txt; s=iport; t=1363706929; x=1364916529; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/tAWSd1xq53W164+bB0eaN/Fo+6u3Gn2tdf4SaBe/LM=; b=UraQMHQ1Nk8XMV773BY/PTjyDIq8IV52I4q0Q+Rx8zGjLVx6HR7N6cfK WmLlotUSoM/m8E/VB5NL7iznRWeZNwEK1ogclNRrkQBG88qvxGNbHTsr+ u99itRd57Uwwuyvnp1NgKzKo1p31vIwNQ6AnLAMxGXau79LE9YNhpF1qe w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFANKDSFGtJXHA/2dsb2JhbABDhBHAf4FXFnSCJAEBAQQBAQEkBkELEAIBCBEEAQELHQcnCxQJCAEBBA4FCBOHeQyyIpAZBIkBhVwmBwQGAYJfYQOSC5VWgwqBaiQa
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600";  d="scan'208,217";a="189152687"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 19 Mar 2013 15:28:49 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFSmSZ001237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:28:48 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 10:28:48 -0500
From: "Mo Zanaty (mzanaty)" 
To: Harald Alvestrand 
Thread-Topic: [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8A=
Date: Tue, 19 Mar 2013 15:28:48 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no>
In-Reply-To: <514829CE.4010004@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.255.46]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F694591xmbrcdx14ciscoc_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 15:28:52 -0000

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F694591xmbrcdx14ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I understand the RTP session rules, but they are a matter for AVTCORE, and =
several drafts already detail the RTP considerations for multiplexing strea=
ms, of potentially different media types, over the same port (using plain R=
TP not SHIM). Bundle does not need to solve that (solved) problem, it just =
needs to signal which port(s) to use. If we feel we should signal some sort=
 of human-level warning about RTP mux rules when signaling ports, the attri=
bute can be named a=3Drtp-mux: instead of a=3Dport .

I don't see how any grouping semantics help with any of the rules. Actually=
, I think grouping semantics hurt, not just due to complexity, but also due=
 to ambiguity about which attributes are inherited or overridden from other=
 m-blocks. Keeping all the m-block attributes independent seems simpler and=
 clearer. If an attribute needs to be consistent across m-blocks, repeating=
 it seems simpler and clearer than inheritance/override rules across m-bloc=
ks. (Of course, if all m-blocks need the same attribute, it can be defined =
at session level instead of repeating in all media levels.)

In my simple (perhaps too simple) mind, all we're trying to do in bundle is=
 temporarily lie on the m-line port to avoid confusing peers/intermediaries=
. In the process, I think we have confused ourselves about what is truly ne=
eded to accomplish this deception. Or maybe I'm the only one confused...

Mo

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Tuesday, March 19, 2013 5:03 AM
To: Mo Zanaty (mzanaty)
Cc: mmusic@ietf.org; rtcweb@ietf.org
Subject: Re: [MMUSIC] Is bundle just a port override?

On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
Does bundle imply anything beyond a simple port override of the m-line port=
? If not, then why not just directly signal the port override in an attribu=
te without any grouping semantics?

No, it's not just a port override.

BUNDLE shoves things into the same RTP session, which means that one has to=
 obey the rules for being in the same RTP session:
- Security done consistently
- RTCP-mux done consistently
- No SSRC collision
- No payload type collision
So it's a good deal more than just a port override.

Magnus argued in favour of a solution that inserted a multiplex layer, so t=
hat one could use the same ports but still have stuff in different RTP sess=
ions, but that did not appeal to many.



Offer to mux audio and video on the same port:
m=3Daudio 10000 RTP/AVP 0
m=3Dvideo 10002 RTP/AVP 31
a=3Dport 10000
i=3DI really want 10000, but lied on the m-line for fear of confusing you. =
Confused yet?

Answer supports the port override attribute and agrees to mux audio and vid=
eo:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40000 RTP/AVP 31
a=3Dport 40000
...so audio and video ports are 10000<->40000.

Answer supports the port override attribute but doesn't want to demux on hi=
s end:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40002 RTP/AVP 31
a=3Dport 40002
...so audio ports are 10000<->40000 and video ports are 10000<->40002.

Answer doesn't support the port override attribute, or doesn't want either =
end to mux:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40002 RTP/AVP 31
...so audio ports are 10000<->40000 and video ports are 10002<->40002.

Either end can re-offer without lies about ports on the m-line after confir=
ming the peer is not confused by muxing, if they want to avoid confusing in=
termediaries.

Has this approach been tried yet? Dismissed?

Mo





_______________________________________________

mmusic mailing list

mmusic@ietf.org

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


--_000_3879D71E758A7E4AA99A35DD8D41D3D90F694591xmbrcdx14ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I understand the RT=
P session rules, but they are a matter for AVTCORE, and several drafts alre=
ady detail the RTP considerations for multiplexing streams, of potentially =
different media types, over the same
 port (using plain RTP not SHIM). Bundle does not need to solve that (solve=
d) problem, it just needs to signal which port(s) to use. If we feel we sho=
uld signal some sort of human-level warning about RTP mux rules when signal=
ing ports, the attribute can be
 named a=3Drtp-mux:<port> instead of a=3Dport <port>.


 


I don’t see h=
ow any grouping semantics help with any of the rules. Actually, I think gro=
uping semantics hurt, not just due to complexity, but also due to ambiguity=
 about which attributes are inherited or overridden
 from other m-blocks. Keeping all the m-block attributes independent seems =
simpler and clearer. If an attribute needs to be consistent across m-blocks=
, repeating it seems simpler and clearer than inheritance/override rules ac=
ross m-blocks. (Of course, if all
 m-blocks need the same attribute, it can be defined at session level inste=
ad of repeating in all media levels.)


 


In my simple (perha=
ps too simple) mind, all we’re trying to do in bundle is temporarily =
lie on the m-line port to avoid confusing peers/intermediaries. In the proc=
ess, I think we have confused ourselves about
 what is truly needed to accomplish this deception. Or maybe I’m the =
only one confused…


 


Mo


 






From: Harald Alvestrand [mailto:harald@alvestrand.no]


Sent: Tuesday, March 19, 2013 5:03 AM

To: Mo Zanaty (mzanaty)

Cc: mmusic@ietf.org; rtcweb@ietf.org

Subject: Re: [MMUSIC] Is bundle just a port override?






 




On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:






Does bundle imply anything beyond a simple port over=
ride of the m-line port? If not, then why not just directly signal the port=
 override in an attribute without any grouping semantics?






No, it's not just a port override.



BUNDLE shoves things into the same RTP session, which means that one has to=
 obey the rules for being in the same RTP session:

- Security done consistently

- RTCP-mux done consistently

- No SSRC collision

- No payload type collision

So it's a good deal more than just a port override.



Magnus argued in favour of a solution that inserted a multiplex layer, so t=
hat one could use the same ports but still have stuff in different RTP sess=
ions, but that did not appeal to many.








 


Offer to mux audio and video on the same port:<=
/o:p>


m=3Daudio 10000 RTP/AVP 0


m=3Dvideo 10002 RTP/AVP 31


a=3Dport 10000


i=3DI really want 10000, but lied on the m-line for =
fear of confusing you. Confused yet?


 


Answer supports the port override attribute and agre=
es to mux audio and video:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40000 RTP/AVP 31


a=3Dport 40000


…so audio and video ports are 10000<->40=
000.


 


Answer supports the port override attribute but does=
n’t want to demux on his end:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40002 RTP/AVP 31


a=3Dport 40002


…so audio ports are 10000<->40000 and vi=
deo ports are 10000<->40002.


 


Answer doesn’t support the port override attri=
bute, or doesn’t want either end to mux:


m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 40002 RTP/AVP 31


…so audio ports are 10000<->40000 and vi=
deo ports are 10002<->40002.


 


Either end can re-offer without lies about ports on =
the m-line after confirming the peer is not confused by muxing, if they wan=
t to avoid confusing intermediaries.


 


Has this approach been tried yet? Dismissed?


 


Mo


 











_______________________________________________


mmusic mailing list


mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic


 






--_000_3879D71E758A7E4AA99A35DD8D41D3D90F694591xmbrcdx14ciscoc_--

From abegen@cisco.com  Tue Mar 19 08:31:18 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577921F8DB9 for ; Tue, 19 Mar 2013 08:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level: 
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 LrZ4io1wepZx for ; Tue, 19 Mar 2013 08:31:17 -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 DD39D21F8DB6 for ; Tue, 19 Mar 2013 08:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12354; q=dns/txt; s=iport; t=1363707076; x=1364916676; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VoBRduGMFNI5qdF3xd+4B5CVDeqSetc8lXgJ5DHkWD8=; b=JE66Qi4P+Kv51R6FWAmYISuVyEvb/ni5WWqq593QttX00rOf+JhbNCBC 0FGXYaoBc7p5m9vJZwhL0f7Jw/PvuI3RxfCeLZACr8PEKlXdyusWTAxUc TxVdS6Gf2UVdyvzH060PL2SxpTxPSeGL22+zPqfyDLvcYtA37A8js1ViK Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAA6ESFGtJXG//2dsb2JhbAA5Cg6EJoNtvG9obxZ0giQBAQEDASMRRQwGAQgOAwMBAgECAgYgAgQwFQgIAgQOBQiIBgYBC69lgkCQHYEjjDGBBwIWEAsHBoInMmEDkxmEZY9jgks/gig
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189143066"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 19 Mar 2013 15:31:13 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFVDkg027245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:31:13 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 10:31:13 -0500
From: "Ali C. Begen (abegen)" 
To: Paul Kyzivat 
Thread-Topic: [MMUSIC] The rtp-duplication related drafts
Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HJg41yeAgAAFCQCAAA8mgIAACswAgAW/cQCAbseDAIAAV3uAgAA6UoA=
Date: Tue, 19 Mar 2013 15:30:49 +0000
Message-ID: 
In-Reply-To: <51486FF1.6010808@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.61.103.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <506566582133AB4CA7540C0E0628C22D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" 
Subject: Re: [MMUSIC] The rtp-duplication related drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 15:31:18 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRA
YWx1bS5taXQuZWR1Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMTksIDIwMTMgNDowMiBQTQ0KVG86
ICJBbGkgQy4gQmVnZW4iIDxhYmVnZW5AY2lzY28uY29tPg0KQ2M6ICJtbXVzaWNAaWV0Zi5vcmci
IDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gVGhlIHJ0cC1kdXBsaWNh
dGlvbiByZWxhdGVkIGRyYWZ0cw0KDQo+QWxpLA0KPg0KPkluIG15IHJldmlldyBJIHNpbXBseSBp
ZGVudGlmaWVkIGFyZWFzIHRoYXQgc2VlbWVkIGluY29tcGxldGUvYW1iaWd1b3VzLg0KDQpUaGFu
a3MsIHlvdXIgcmV2aWV3IHdhcyBjZXJ0YWlubHkgaGVscGZ1bCB0byBpZGVudGlmeSB0aGVzZSBp
c3N1ZXMuDQoNCj5UaGUgZXhpc3Rpbmcgc3ludGF4IGlzIGluYWRlcXVhdGUgdG8gcmVwcmVzZW50
IGEgZnVsbCByYW5nZSBvZg0KPnBvc3NpYmlsaXRpZXMgaW4gdGhlIHByZXNlbmNlIG9mIG11bHRp
cGxlIGR1cGxpY2F0aW9uIGdyb3Vwcy4NCj4NCj5JIGRvbid0IGhhdmUgYW55IHBhcnRpY3VsYXIg
cHJlZmVyZW5jZXMgaGVyZS4NCj5XaGlsZSBJIHN1Z2dlc3RlZCBzb21lIHBvc3NpYmxlIHN5bnRh
eCBjaGFuZ2VzIHRoYXQgd291bGQgYWxsb3cgY292ZXJhZ2UNCj5vZiBhbGwgcG9zc2liaWxpdGll
cywgSSBhbSBpbiBubyBwb3NpdGlvbiB0byBrbm93IGlmIHRoZSBhZGRlZCBjYXNlcw0KPnRoYXQg
d291bGQgY292ZXIgbWFrZSBhbnkgc2Vuc2UgaW4gcHJhY3RpY2UuIEkgYW0gc2F0aXNmaWVkIHRv
IGFjY2VwdA0KPnlvdXIganVkZ2VtZW50IHRoYXQgdGhleSBkb24ndC4NCj4NCj5JZiB0aGF0IGlz
IHNvLCB0aGVuIHNpbXBseSBwb2ludGluZyBvdXQgdGhhdCB0aGUgb3RoZXIgY2FzZXMgY29uc2lk
ZXJlZA0KPm91dCBvZiBzY29wZSB3aWxsIHNhdGlzZnkgbWUuDQoNCk9LLCBib3RoIGRyYWZ0cyB3
aWxsIGJlIHJldmlzZWQgc2hvcnRseS4gUGxlYXNlIGxldCBtZSBrbm93IHdoZXRoZXIgeW91DQph
cmUgb2sgd2l0aCB0aGUgY2hhbmdlcyB3aGVuIHlvdSBoYXZlIGEgY2hhbmNlIHRvIGxvb2sgYXQg
dGhlIGRpZmYuDQoNCi1hY2JlZ2VuDQoNCj4NCj4JVGhhbmtzLA0KPglQYXVsDQo+DQo+T24gMy8x
OS8xMyAyOjQ4IFBNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+PiAoUGlja2luZyB1
cCB0aGlzIG9sZCB0aHJlYWQgYXMgSSBhbSBwbGFubmluZyB0byByZXZpc2UgYWxsIHRoZQ0KPj5k
dXBsaWNhdGlvbg0KPj4gcmVsYXRlZCBkcmFmdHMgc2hvcnRseSkNCj4+DQo+Pg0KPj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1
bS5taXQuZWR1Pg0KPj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDcsIDIwMTMgMTA6MDYgUE0NCj4+
IFRvOiAiQWxpIEMuIEJlZ2VuIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCj4+IENjOiAibW11c2ljQGll
dGYub3JnIiA8bW11c2ljQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIFRoZSBy
dHAtZHVwbGljYXRpb24gcmVsYXRlZCBkcmFmdHMNCj4+DQo+Pj4gT24gMS8zLzEzIDExOjIwIFBN
LCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+Pj4+DQo+Pj4+IE9uIEphbiAzLCAyMDEz
LCBhdCAxMDo0MSBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQo+Pj4+
d3JvdGU6DQo+Pj4+DQo+Pj4+PiBPbiAxLzMvMTMgOTo0NyBQTSwgQWxpIEMuIEJlZ2VuIChhYmVn
ZW4pIHdyb3RlOg0KPj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4NCj4+Pj4+Pg0KPj4+Pj4+
IE9uIEphbiAzLCAyMDEzLCBhdCA5OjI5IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0u
bWl0LmVkdT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+PiBBbGksDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IE9uIDEvMy8xMyA1OjMxIFBNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+
Pj4+Pj4+PiBIaSBldmVyeW9uZSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgZm9sbG93aW5nIHR3
byBkcmFmdHMgaGF2ZSBiZWVuIGFkb3B0ZWQgYnkgTU1VU0lDIGEgd2hpbGUgYWdvDQo+Pj4+Pj4+
PiBhbmQgdGhlIG1haW4gZHJhZnQgZGlzY3Vzc2luZyB0aGUgUlRQIGR1cGxpY2F0aW9uIGlzc3Vl
cyBpcyBiZWluZw0KPj4+Pj4+Pj4gZmluYWxpemVkIGluIEFWVEVYVCAodGhpcyB3YXMgYWxzbyBh
ZG9wdGVkIGFzIGEgV0cgaXRlbSBhIHdoaWxlDQo+Pj4+Pj4+PiBhZ28pLiBJdCBpcyBzaW1wbHkg
d2FpdGluZyBmb3IgdGhlIFdHIHRvIG1ha2UgYSBkZWNpc2lvbiBvbiB0aGUNCj4+Pj4+Pj4+IHNy
Y25hbWUgcHJvcG9zYWwuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj5o
dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLWRlbGF5ZWQt
ZHVwbGljYXRpDQo+Pj4+Pj4+Pm9uDQo+Pj4+Pj4+PiAvDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gDQo+
Pj4+Pj4+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMt
ZHVwbGljYXRpb24tZ3JvdXANCj4+Pj4+Pj4+aW4NCj4+Pj4+Pj4+IGcvDQo+Pj4+Pj4+DQo+Pj4+
Pj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZXNlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiBFYWNo
IGV4YW1wbGUgc2hvd3Mgb25seSBvbmUgZ3JvdXAuIEJ1dCBjb3VsZG4ndCB0aGVyZSBiZSBtdWx0
aXBsZQ0KPj4+Pj4+PiBkdXBsaWNhdGlvbiBncm91cHM/DQo+Pj4+Pj4+DQo+Pj4+Pj4gVGhlcmUg
Y291bGQgYmUuDQo+Pj4+Pj4NCj4+Pj4+Pj4gSWYgc28sIHRoZSBjdXJyZW50IHByb3Bvc2FsIGhh
cyBubyBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcNCj4+Pj4+Pj5zZXBhcmF0ZQ0KPj4+Pj4+PiBk
dXBsaWNhdGlvbi1kZWxheSBmb3IgZWFjaCBncm91cC4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+
IGE9ZHVwbGljYXRpb24tZGVsYXk6WCBjb3VsZCBiZSBzcGVjaWZpZWQgaW4gZWFjaCBtZWRpYSBz
ZXNzaW9uLiBGb3INCj4+Pj4+PiBleGFtcGxlOg0KPj4+Pj4+DQo+Pj4+Pj4gCWE9cnRwbWFwOjEw
MCBNUDJULzkwMDAwDQo+Pj4+Pj4gICAgICAgICAgIGE9c3NyYzoxMDAwIGNuYW1lOmNoMUBleGFt
cGxlLmNvbQ0KPj4+Pj4+ICAgICAgICAgICBhPXNzcmM6MTAxMCBjbmFtZTpjaDFAZXhhbXBsZS5j
b20NCj4+Pj4+PiAgICAgICAgICAgYT1zc3JjLWdyb3VwOkRVUCAxMDAwIDEwMTANCj4+Pj4+PiAg
ICAgICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheToxMDANCj4+Pj4+PiAgICAgICAgICAgYT1taWQ6
R3JvdXAxDQo+Pj4+Pj4gCWE9cnRwbWFwOjEwMSBNUDJULzkwMDAwDQo+Pj4+Pj4gICAgICAgICAg
IGE9c3NyYzoyMDAwIGNuYW1lOmNoMkBleGFtcGxlLmNvbQ0KPj4+Pj4+ICAgICAgICAgICBhPXNz
cmM6MjAxMCBjbmFtZTpjaDJAZXhhbXBsZS5jb20NCj4+Pj4+PiAgICAgICAgICAgYT1zc3JjLWdy
b3VwOkRVUCAyMDAwIDIwMTANCj4+Pj4+PiAgICAgICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheTox
NTANCj4+Pj4+PiAgICAgICAgICAgYT1taWQ6R3JvdXAyDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBtYWtl
cyB0aGUgYXR0cmlidXRlcyB2ZXJ5IG9yZGVyIGRlcGVuZGVudC4gSWYgdGhpcyBpcyBpbnRlbmRl
ZCwNCj4+Pj4+IHRoZW4gSSB0aGluayB5b3UgbmVlZCBtb3JlIHdvcmRzIHRvIHNheSB0aGF0LiBD
dXJyZW50bHkgaXQgc2F5czoNCj4+Pj4+DQo+Pj4+PiAgICAgSWYgdXNlZCBhcyBhIG1lZGlhLWxl
dmVsDQo+Pj4+PiAgICAgYXR0cmlidXRlLCBpdCBNVVNUIGJlIHVzZWQgd2l0aCB0aGUgJ3NzcmMt
Z3JvdXAnIGF0dHJpYnV0ZSBhbmQNCj4+Pj4+IkRVUCINCj4+Pj4+ICAgICBncm91cGluZyBzZW1h
bnRpY3MuLi4NCj4+Pj4NCj4+Pj4gTXkgbWlzdGFrZSwgZGlkIG5vdCBjb3B5L3Bhc3RlIHRoZSB3
aG9sZSB0aGluZy4NCj4+Pj4NCj4+Pj4gCW09dmlkZW8gMzAwMDAgUlRQL0FWUCAxMDANCj4+Pj4g
ICAgICAgICAgIGM9SU4gSVA0IDIzMy4yNTIuMC4xLzEyNw0KPj4+PiAgICAgICAgICAgYT1zb3Vy
Y2UtZmlsdGVyOmluY2wgSU4gSVA0IDIzMy4yNTIuMC4xIDE5OC41MS4xMDAuMQ0KPj4+PiAgICAg
ICAgICAgYT1ydHBtYXA6MTAwIE1QMlQvOTAwMDANCj4+Pj4gICAgICAgICAgIGE9c3NyYzoxMDAw
IGNuYW1lOmNoMUBleGFtcGxlLmNvbQ0KPj4+PiAgICAgICAgICAgYT1zc3JjOjEwMTAgY25hbWU6
Y2gxQGV4YW1wbGUuY29tDQo+Pj4+ICAgICAgICAgICBhPXNzcmMtZ3JvdXA6RFVQIDEwMDAgMTAx
MA0KPj4+PiAgICAgICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheToxMDANCj4+Pj4gICAgICAgICAg
IGE9bWlkOkdyb3VwMQ0KPj4+PiAJbT12aWRlbyA0MDAwMCBSVFAvQVZQIDEwMQ0KPj4+PiAgICAg
ICAgICAgYz1JTiBJUDQgMjMzLjI1Mi4wLjIvMTI3DQo+Pj4+ICAgICAgICAgICBhPXNvdXJjZS1m
aWx0ZXI6aW5jbCBJTiBJUDQgMjMzLjI1Mi4wLjIgMTk4LjUxLjEwMC4xDQo+Pj4+ICAgICAgICAg
ICBhPXJ0cG1hcDoxMDEgTVAyVC85MDAwMA0KPj4+PiAgICAgICAgICAgYT1zc3JjOjIwMDAgY25h
bWU6Y2gyQGV4YW1wbGUuY29tDQo+Pj4+ICAgICAgICAgICBhPXNzcmM6MjAxMCBjbmFtZTpjaDJA
ZXhhbXBsZS5jb20NCj4+Pj4gICAgICAgICAgIGE9c3NyYy1ncm91cDpEVVAgMjAwMCAyMDEwDQo+
Pj4+ICAgICAgICAgICBhPWR1cGxpY2F0aW9uLWRlbGF5OjE1MA0KPj4+PiAgICAgICAgICAgYT1t
aWQ6R3JvdXAyDQo+Pj4+DQo+Pj4+IHNvIHRoZXJlIGlzIG9uZSBkdXBsaWNhdGlvbi1kZWxheSBh
dHRyaWJ1dGUgaW4gZWFjaCBtZWRpYSBzZXNzaW9uDQo+Pj4+IChzcGVjaWZpZWQgYnkgYSBtPSBs
aW5lKS4gSXQgZG9lcyBub3QgbWF0dGVyIHdoZXRoZXIgaXQgaXMgYmVmb3JlIG9yDQo+Pj4+IGFm
dGVyIHRoZSBzc3JjLWdyb3VwIGxpbmUuIEl0IGlzIE9LIGFzIGxvbmcgYXMgaXQgaXMgc29tZXdo
ZXJlIGJlZm9yZQ0KPj4+PiB0aGUgbmV4dCBtIGxpbmUuDQo+Pj4NCj4+PiBCdXQgdGhlbiwgZHVw
bGljYXRpb24tZGVsYXkgYXBwbGllcyB0byBhPXNzcmMtZ3JvdXA6RFVQIGdyb3VwcyB3aXRoaW4N
Cj4+PiB0aGF0IG1lZGlhIHNlY3Rpb24uIFlvdSBjb3VsZCBoYXZlIHR3byBncm91cHMgb2Ygc3Ny
Y3MgaW4gdGhlcmUuIFNvIHRoZQ0KPj4+IHByb2JsZW0gaXMgdGhlIHNhbWUgYXMgdGhlIHByb2Js
ZW0gYWNyb3NzIGRpZmZlcmVudCBtLWxpbmVzLiBFLmcuDQo+Pj4NCj4+PiAJbT12aWRlbyAzMDAw
MCBSVFAvQVZQIDEwMA0KPj4+ICAgICAgICAgIGM9SU4gSVA0IDIzMy4yNTIuMC4xLzEyNw0KPj4+
ICAgICAgICAgIGE9c291cmNlLWZpbHRlcjppbmNsIElOIElQNCAyMzMuMjUyLjAuMSAxOTguNTEu
MTAwLjENCj4+PiAgICAgICAgICBhPXJ0cG1hcDoxMDAgTVAyVC85MDAwMA0KPj4+ICAgICAgICAg
IGE9c3NyYzoxMDAwIGNuYW1lOmNoMUBleGFtcGxlLmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYzox
MDEwIGNuYW1lOmNoMUBleGFtcGxlLmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYzoxMDIwIGNuYW1l
OmNoMUBleGFtcGxlLmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYzoxMDMwIGNuYW1lOmNoMUBleGFt
cGxlLmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYy1ncm91cDpEVVAgMTAwMCAxMDEwDQo+Pj4gICAg
ICAgICAgYT1kdXBsaWNhdGlvbi1kZWxheToxMDANCj4+PiAgICAgICAgICBhPXNzcmMtZ3JvdXA6
RFVQIDEwMjAgMTAzMA0KPj4+ICAgICAgICAgIGE9ZHVwbGljYXRpb24tZGVsYXk6MjAwDQo+Pj4g
CW09dmlkZW8gNDAwMDAgUlRQL0FWUCAxMDENCj4+PiAgICAgICAgICBjPUlOIElQNCAyMzMuMjUy
LjAuMi8xMjcNCj4+PiAgICAgICAgICBhPXNvdXJjZS1maWx0ZXI6aW5jbCBJTiBJUDQgMjMzLjI1
Mi4wLjIgMTk4LjUxLjEwMC4xDQo+Pj4gICAgICAgICAgYT1ydHBtYXA6MTAxIE1QMlQvOTAwMDAN
Cj4+PiAgICAgICAgICBhPXNzcmM6MjAwMCBjbmFtZTpjaDJAZXhhbXBsZS5jb20NCj4+PiAgICAg
ICAgICBhPXNzcmM6MjAxMCBjbmFtZTpjaDJAZXhhbXBsZS5jb20NCj4+PiAgICAgICAgICBhPXNz
cmMtZ3JvdXA6RFVQIDIwMDAgMjAxMA0KPj4+ICAgICAgICAgIGE9c3NyYzoyMDIwIGNuYW1lOmNo
MkBleGFtcGxlLmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYzoyMDMwIGNuYW1lOmNoMkBleGFtcGxl
LmNvbQ0KPj4+ICAgICAgICAgIGE9c3NyYy1ncm91cDpEVVAgMjAyMCAyMDMwDQo+Pj4gICAgICAg
ICAgYT1kdXBsaWNhdGlvbi1kZWxheToyNTANCj4+Pg0KPj4+ICBGcm9tIHdoYXQgeW91IHNheSwg
dGhlIHR3byBkdXBsaWNhdGlvbi1kZWxheSBhdHRyaWJ1dGVzIGluIG9uZSBtZWRpYQ0KPj4+IHNl
Y3Rpb24gd291bGQgbWFrZSBubyBzZW5zZS4NCj4+DQo+Pg0KPj4gRnJhbmtseSwgSSBjYW4ndCB0
aGluayBvZiBhbiBhcHBsaWNhdGlvbiB3aGVyZSB5b3Ugd291bGQgaGF2ZSBtdWx0aS1wYWlyDQo+
PiBzdHJlYW1zIGluIGFuIFJUUCBzZXNzaW9uIGFuZCByZXF1aXJlIGRpZmZlcmVudCBkdXBsaWNh
dGlvbiBkZWxheXMNCj4+YmV0d2Vlbg0KPj4gZWFjaCBwYWlyLiBTbywgdGhhdCdzIHdoeSBJIG5l
dmVyIGJvdGhlcmVkIHdpdGggdGhpcy4gRG9lcyBhbnlib2R5DQo+PiBhY3R1YWxseSBuZWVkIHRo
aXMgdXNlIGNhc2U/IE90aGVyd2lzZSwgSSB0aGluayB3ZSBjYW4gaWdub3JlIGl0IGFuZCBsZXQN
Cj4+IGFsbCB0aGUgcGFpcnMgdXNlIHRoZSBzYW1lIGRlbGF5Lg0KPj4NCj4+DQo+Pj4NCj4+Pj4+
IFdoYXQgZG9lcyAidXNlZCB3aXRoIiBtZWFuPyBJIGFzc3VtZWQgaXQgc2ltcGx5IG1lYW50IHRo
YXQgYm90aA0KPj4+Pj4gYXR0cmlidXRlcyBoYWQgdG8gYmUgcHJlc2VudCBpbiB0aGUgbWVkaWEg
c2VjdGlvbi4gQnV0IHdoYXQgeW91IGFyZQ0KPj4+Pj4gc2F5aW5nIG5vdyBzYXlzIHRoYXQgdGhl
cmUgaXMgc29tZSB2ZXJ5IHNwZWNpZmljIG9yZGVyaW5nIHJlcXVpcmVkLg0KPj4+Pj4gRS5nLiB0
aGF0IHRoZSBhPWR1cGxpY2FhdGlvbi1kZWxheSBtdXN0IGZvbGxvdyB0aGUgYT1zc3JjLWdyb3Vw
OkRVUA0KPj4+Pj50bw0KPj4+Pj4gd2hpY2ggaXQgYXBwbGllcywgYW5kIHByZWNlZGUgYW55IG90
aGVyIGE9c3NyYy1ncm91cDpEVVAuIFRoaXMgaXMNCj4+Pj4+IHBvc3NpYmxlLCBidXQgdWdseSB0
byBzcGVjaWZ5Lg0KPj4+Pg0KPj4+PiBJIGhvcGUgaXQgaXMgY2xlYXIgbm93Pw0KPj4+Pg0KPj4+
Pj4NCj4+Pj4+PiAoVGhlIFNTUkMgbmVlZCBub3QgYmUgZGlmZmVyZW50IGFzIFNTUkMgb25seSBu
ZWVkIHRvIGJlIHVuaXF1ZQ0KPj4+Pj4+d2l0aGluDQo+Pj4+Pj4gZWFjaCBtZWRpYSBzZXNzaW9u
KQ0KPj4+Pj4+DQo+Pj4+Pj4gRm9yIHRoZSBub24tc3NyYyBncm91cGluZywgeW91ciBjb21tZW50
IGhvbGRzLiBJdCBkb2VzIG5vdCBzdXBwb3J0DQo+Pj4+Pj4gc3BlY2lmeWluZyBkaWZmZXJlbnQg
ZGVsYXkgdmFsdWVzIGZvciBkaWZmZXJlbnQgZ3JvdXBzLiBEbyB5b3UgdGhpbmsNCj4+Pj4+PiB3
ZSBzaG91bGQgc3VwcG9ydCBkaXN0aW5jdCBkZWxheSB2YWx1ZXMgZm9yIGRpZmZlcmVudCBncm91
cHMgKHdoaWNoDQo+Pj4+Pj4gcHJvYmFibHkgbWVhbnMgZHVwbGljYXRpb24tZGVsYXkgYXR0cmli
dXRlIGhhcyB0byBiZSBtZWRpYS1sZXZlbA0KPj4+Pj4+b25seSk/DQo+Pj4NCj4+PiBXZWxsLCBm
b3IgdGhlIG5vbi1zc3JjIGdyb3VwaW5nIHlvdSBjb3VsZCBwdXQgdGhlIGdyb3VwIG5hbWUgaW4g
dGhlDQo+Pj4gYT1kdXBsaWNhdGlvbi1kZWxheSBhdHRyaWJ1dGUgdmFsdWUuDQo+Pg0KPj4gVGhl
cmUgaXMgbm8gZ3JvdXAgbmFtZSBpbiB0aGUgImE9Z3JvdXA6RFVQIiBsaW5lLCBqdXN0IHRoZSBs
aXN0IG9mIG1pZHMpDQo+PiBzbyB0aGVyZSBpcyBubyB1bmlxdWUgaWRlbnRpZmllciBmb3IgZWFj
aCBncm91cC4gQW55d2F5LCBJIHRob3VnaHQgb2YNCj4+dGhpcw0KPj4gYW5kIGhvbmVzdGx5LCBJ
IHRoaW5rIHdlIGJldHRlciBzdGF0ZSB0aGlzICJsaW1pdGF0aW9uIiBleHBsaWNpdGx5IGFuZA0K
Pj4gZm9yYmlkIHRoZSB1c2Ugb2YgZGlmZmVyZW50IHNlc3Npb24tbGV2ZWwgZGVsYXlzIGluIGEg
c2luZ2xlIFNEUA0KPj4gZGVzY3JpcHRpb24uIEluIG90aGVyIHdvcmRzLCBpZiB0aGVyZSB3aWxs
IGJlIGEgc2Vzc2lvbi1sZXZlbCBkZWxheQ0KPj4gYXR0cmlidXRlLCBpdCB3aWxsIGFwcGx5IHRv
IGFsbCBEVVAgZ3JvdXBzLiBJZiB5b3UgbmVlZCBkaWZmZXJlbnQNCj4+IGR1cGxpY2F0aW9uIGRl
bGF5cyBmb3IgZGlmZmVyZW50IGdyb3VwcywgdGhlbiBzaW1wbHkgdXNlIGRpZmZlcmVudCBTRFAN
Cj4+IGRlc2NyaXB0aW9ucyBmb3IgdGhhdCAob3IgdXNlIHRoZSBtZWRpYS1sZXZlbCBkZWxheSBh
dHRyaWJ1dGUpLg0KPj4NCj4+Pg0KPj4+IEFuZCBmb3IgdGhlIHNzcmMtZ3JvdXBpbmcgY2FzZSB5
b3UgY291bGQgcHV0IG9uZSBvZiB0aGUgZ3JvdXBlZCBzc3Jjcw0KPj4+aW4NCj4+PiB0aGUgYT1k
dXBsaWNhdGlvbi1kZWxheSBhdHRyIHZhbHVlLg0KPj4NCj4+IEFzIEkgc2FpZCBhYm92ZSwgSSBj
YW4ndCB0aGluayBvZiBhbnkgdXNlIGNhc2Ugd2hlcmUgdGhpcyB3aWxsIGJlDQo+PiBuZWVkZWQv
dXNlZnVsLiBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgU1NSQyBwYWlyaW5ncyBpbnNpZGUgYW4gbSBs
aW5lLA0KPj50aGV5DQo+PiBzaW1wbHkgaGF2ZSB0byB1c2UgdGhlIHNhbWUgZGVsYXkgdmFsdWUu
IEkgY2FuIGNsYXJpZnkgdGhpcyBpbiB0aGUNCj4+ZHJhZnQuDQo+Pg0KPj4gTXkgZ29hbCBpcyB0
byBjb21wbGV0ZSB0aGlzIHdvcmsgZm9yIHRoZSB1c2UgY2FzZXMgd2UgbmVlZCBub3cuIEZvcg0K
Pj4gcG9zc2libGUgYnV0IHJhdGhlciB1bnJlYWxpc3RpYyB1c2UgY2FzZXMsIEkgZG9uJ3QgdGhp
bmsgd2Ugc2hvdWxkDQo+PiBjb21wbGljYXRlIHRoZSBhdHRyaWJ1dGUuIFBsZWFzZSBjb21tZW50
IGlmIHlvdSBkaXNhZ3JlZSB3aXRoIHRoZXNlDQo+PiBjaGFuZ2VzLg0KPj4NCj4+IFRoYW5rcywN
Cj4+IC1hY2JlZ2VuDQo+Pg0KPj4+DQo+Pj4gCVRoYW5rcywNCj4+PiAJUGF1bA0KPj4+DQo+Pj4N
Cj4+DQo+Pg0KPg0KPg0KDQoNCg==

From internet-drafts@ietf.org  Tue Mar 19 08:59:04 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58121F8698; Tue, 19 Mar 2013 08:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.137
X-Spam-Level: 
X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=0.463, 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 JgRScYvmJqzh; Tue, 19 Mar 2013 08:59:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8745521F863C; Tue, 19 Mar 2013 08:59:03 -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.43
Message-ID: <20130319155903.26616.5363.idtracker@ietfa.amsl.com>
Date: Tue, 19 Mar 2013 08:59:03 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-delayed-duplication-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 15:59:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Delayed Duplication Attribute in the Session Description=
 Protocol
	Author(s)       : Ali Begen
                          Yiqun Cai
                          Heidi Ou
	Filename        : draft-ietf-mmusic-delayed-duplication-01.txt
	Pages           : 10
	Date            : 2013-03-19

Abstract:
   A straightforward approach to provide protection against packet
   losses due to network outages with a longest duration of T time units
   is to simply duplicate the original packets and send each copy
   separated in time by at least T time units.  This approach is
   commonly referred to as Time-shifted Redundancy, Temporal Redundancy
   or simply Delayed Duplication.  This document defines an attribute to
   indicate the presence of temporally redundant media streams and the
   duplication delay in the Session Description Protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-delayed-duplication-01


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


From internet-drafts@ietf.org  Tue Mar 19 08:59:24 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEEF21F8DE1; Tue, 19 Mar 2013 08:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.208
X-Spam-Level: 
X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=0.392, 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 dYEOoKEVdbkx; Tue, 19 Mar 2013 08:59:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5A21F8D5F; Tue, 19 Mar 2013 08:59:23 -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.43
Message-ID: <20130319155923.26581.76591.idtracker@ietfa.amsl.com>
Date: Tue, 19 Mar 2013 08:59:23 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-duplication-grouping-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 15:59:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Duplication Grouping Semantics in the Session Descriptio=
n Protocol
	Author(s)       : Ali Begen
                          Yiqun Cai
                          Heidi Ou
	Filename        : draft-ietf-mmusic-duplication-grouping-01.txt
	Pages           : 9
	Date            : 2013-03-19

Abstract:
   Packet loss is undesirable for real-time multimedia sessions, but can
   occur due to congestion, or other unplanned network outages.  This is
   especially true for IP multicast networks, where packet loss patterns
   can vary greatly between receivers.  One technique that can be used
   to recover from packet loss without incurring unbounded delay for all
   the receivers is to duplicate the packets and send them in separate
   redundant streams.  This document defines the semantics for grouping
   redundant streams in the Session Description Protocol (SDP).  The
   semantics defined in this document are to be used with the SDP
   Grouping Framework [RFC5888].  SSRC-level (Synchronization Source)
   grouping semantics are also defined in this document for RTP streams
   using SSRC multiplexing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-duplication-grouping-01


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


From emil@sip-communicator.org  Tue Mar 19 10:03:04 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4621F8D68 for ; Tue, 19 Mar 2013 10:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level: 
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RDNS_DYNAMIC=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 sLVtg-0xT3CN for ; Tue, 19 Mar 2013 10:03:03 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC121F8C7D for ; Tue, 19 Mar 2013 10:03:03 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm11so4630823wib.5 for ; Tue, 19 Mar 2013 10:03:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=/IjoHxcIkPskjykT1I+mN3lBj1oldEna3mZF6c9WJ7s=; b=GVVULYqUWI0+F+ooW3wA6dUDHqg4EgaUAZS622X9t64Au560SxgkW8XJ17+4QjNP4V jhWwDn8xvevPAVLP3VKq8y2XDLN7XajjqnKhObu9Hbys1MbbdKnuIPEVzwtIiraSZ37P suUgm3+hSDApIcYtC9fUxNa3SM7w89sQ5RtuKFPoNysUkXR7t+UosAvYa/7WhxtvPYas hnfmYcd0u+TBh2zfBcIRT1/oHCzlphik7wuBLnpxKxlj+nkyeZpk3GXApq0uM6zRmM/o gTJWsuKin/DUAjkEY5lb5oczHyrWyD/xCc/KwIi+7n0C7anBERtcs5TrJyUiAX+A6FZY PQ3w==
X-Received: by 10.180.12.48 with SMTP id v16mr4410656wib.1.1363712582382; Tue, 19 Mar 2013 10:03:02 -0700 (PDT)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id t7sm1850024wij.2.2013.03.19.10.03.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 10:03:01 -0700 (PDT)
Message-ID: <51489A43.3030109@jitsi.org>
Date: Tue, 19 Mar 2013 18:02:59 +0100
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" 
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmA8Bsn5F75RncitLzdgv4FNuOtkQBzQ8+3FEj0lG4Go+CR8JC8zUNxozlV40rwY10nffmY
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 17:03:05 -0000

Hey Mo,

On 19.03.13, 16:28, Mo Zanaty (mzanaty) wrote:
> I understand the RTP session rules, but they are a matter for AVTCORE,
> and several drafts already detail the RTP considerations for
> multiplexing streams, of potentially different media types, over the
> same port (using plain RTP not SHIM). Bundle does not need to solve tha=
t
> (solved) problem, it just needs to signal which port(s) to use. If we
> feel we should signal some sort of human-level warning about RTP mux
> rules when signaling ports, the attribute can be named a=3Drtp-mux:
> instead of a=3Dport .
>=20
> =20
>=20
> I don=92t see how any grouping semantics help with any of the rules.
> Actually, I think grouping semantics hurt, not just due to complexity,
> but also due to ambiguity about which attributes are inherited or
> overridden from other m-blocks. Keeping all the m-block attributes
> independent seems simpler and clearer. If an attribute needs to be
> consistent across m-blocks, repeating it seems simpler and clearer than=

> inheritance/override rules across m-blocks. (Of course, if all m-blocks=

> need the same attribute, it can be defined at session level instead of
> repeating in all media levels.)
>=20
> =20
>=20
> In my simple (perhaps too simple) mind, all we=92re trying to do in bun=
dle
> is temporarily lie on the m-line port to avoid confusing
> peers/intermediaries. In the process, I think we have confused ourselve=
s
> about what is truly needed to accomplish this deception. Or maybe I=92m=

> the only one confused=85

In your original mail you seemed to be suggesting something similar to:

http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-00

(Sometimes referred to Cundle for Cullen's Bundle)

or this

http://tools.ietf.org/html/draft-alvestrand-one-rtp-01

(Also known as One RTP)

Both would start by offering multiple ports and fall back to a single
port if bundling is supported.

The concern that has been expressed with them is that in case of
bundling, non-use of the discarded RTP ports would cause some SBCs to
believe that there's a problem with the session which may lead to the
SBC tearing down the call.

Hope this helps,
Emil

>=20
> =20
>=20
> Mo
>=20
> =20
>=20
> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Tuesday, March 19, 2013 5:03 AM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* mmusic@ietf.org; rtcweb@ietf.org
> *Subject:* Re: [MMUSIC] Is bundle just a port override?
>=20
> =20
>=20
> On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
>=20
>     Does bundle imply anything beyond a simple port override of the
>     m-line port? If not, then why not just directly signal the port
>     override in an attribute without any grouping semantics?
>=20
>=20
> No, it's not just a port override.
>=20
> BUNDLE shoves things into the same RTP session, which means that one ha=
s
> to obey the rules for being in the same RTP session:
> - Security done consistently
> - RTCP-mux done consistently
> - No SSRC collision
> - No payload type collision
> So it's a good deal more than just a port override.
>=20
> Magnus argued in favour of a solution that inserted a multiplex layer,
> so that one could use the same ports but still have stuff in different
> RTP sessions, but that did not appeal to many.
>=20
>=20
> =20
>=20
> Offer to mux audio and video on the same port:
>=20
> m=3Daudio 10000 RTP/AVP 0
>=20
> m=3Dvideo 10002 RTP/AVP 31
>=20
> a=3Dport 10000
>=20
> i=3DI really want 10000, but lied on the m-line for fear of confusing y=
ou.
> Confused yet?
>=20
> =20
>=20
> Answer supports the port override attribute and agrees to mux audio and=

> video:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40000 RTP/AVP 31
>=20
> a=3Dport 40000
>=20
> =85so audio and video ports are 10000<->40000.
>=20
> =20
>=20
> Answer supports the port override attribute but doesn=92t want to demux=
 on
> his end:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40002 RTP/AVP 31
>=20
> a=3Dport 40002
>=20
> =85so audio ports are 10000<->40000 and video ports are 10000<->40002.
>=20
> =20
>=20
> Answer doesn=92t support the port override attribute, or doesn=92t want=

> either end to mux:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40002 RTP/AVP 31
>=20
> =85so audio ports are 10000<->40000 and video ports are 10002<->40002.
>=20
> =20
>=20
> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries.
>=20
> =20
>=20
> Has this approach been tried yet? Dismissed?
>=20
> =20
>=20
> Mo
>=20
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
>=20
> mmusic mailing list
>=20
> mmusic@ietf.org 
>=20
> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> =20
>=20
>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20

--=20
https://jitsi.org


From mzanaty@cisco.com  Tue Mar 19 11:43:54 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DD821F8498; Tue, 19 Mar 2013 11:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.399
X-Spam-Level: 
X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 LJzQW5AwoxXy; Tue, 19 Mar 2013 11:43:53 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9052621F8319; Tue, 19 Mar 2013 11:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7765; q=dns/txt; s=iport; t=1363718633; x=1364928233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XyEM/tkGHiyeWeJdUVa+jPcbKOH6atmXnYQoJ7FZHRk=; b=SrD4vtfbTHoH57j5WlcXmwsj32snaZEf+eHat0s01PEj2GbxMgIjsWcV rd5walROPzzUX+HTbePQUSKRZK4rqvJN9OLzV4Jn0IK5E9Y0PPJXinUFJ 5rKgjTFfVhAlpf0rAnzMt234m+hcCv8csauq0eOO7MjcbiAik/wUVDsPi c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAGWwSFGtJXHA/2dsb2JhbABDxRuBWhZ0giQBAQEDAQEBASQTNAsFBwQCAQgOAwQBAQEKFAkHJwsUCQgBAQQOBQgTh3MGDLFwkBWNXn8mCwcGgllhA5ILhXOPY4MKgWoJFwQa
X-IronPort-AV: E=Sophos;i="4.84,873,1355097600"; d="scan'208";a="189200903"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 19 Mar 2013 18:43:53 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JIhqZ4023736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 18:43:52 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 13:43:52 -0500
From: "Mo Zanaty (mzanaty)" 
To: Emil Ivov 
Thread-Topic: [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXg
Date: Tue, 19 Mar 2013 18:43:52 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org>
In-Reply-To: <51489A43.3030109@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.239.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 18:43:55 -0000

Hi Emil,

Those drafts use the SDP grouping framework (a=3Dgroup:BUNDLE/TOGETHER), wh=
ich I think is unnecessary complexity and ambiguity for something which can=
 be solved in a much simpler and clearer way with a single attribute: a=3Dp=
ort . (Or, if we want to warn humans about RTP muxing, then name it a=
=3Drtp-mux:, but machines won't care about the name, and their RTP im=
plementations already know how to deal with muxing if they use this attribu=
te, so stronger warnings are unnecessary.)

Regarding the concern about non-use of the discarded RTP ports confusing SB=
Cs, see this part of my original message [with clarifications], which is wh=
at the current bundle draft also suggests:

> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries [that may monitor the unused ports].

To summarize the (long) history of RTP mux / bundle problems and solutions:

1. We want to multiplex everything on one port: audio/video/RTP/RTCP/SCTP.

2. But we hit a red light in RTP, which says we SHOULD NOT multiplex on the=
 same port using PT/SSRC, so drafts were written to relax the restrictions.=
 (Note that RFC 3550 RTP also says MUST NOT multiplex RTP and RTCP, so RFC =
5761 a=3Drtcp-mux was written. We should continue to remove obsolete and un=
necessary restrictions in old specs.)

3. With a green light from RTP, we now turn to SDP to signal the same port =
on multiple m-lines.

4. We hit a red light in SDP since this is technically undefined behavior, =
so we fear legacy peers or intermediaries will choke on it.

5. We lie about our desired ports on the m-line, using unique ports to avoi=
d confusing legacy peers or intermediaries.

6. We signal our truly desired ports in some way outside the m-line.

7. If the peer understands 6, it signals back in some way, and we think we'=
re good to mux.

8. We hit a red light in intermediaries that monitor ports but don't unders=
tand 6/7, so we re-offer with the actually used ports (not lies) in the m-l=
ine to avoid confusing them.

I'm just asking why 6/7 decided to use complex grouping semantics instead o=
f a simple attribute. Was a simple port override attribute already consider=
ed and dismissed? Or just overlooked?

Cheers,
Mo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]=20
Sent: Tuesday, March 19, 2013 1:03 PM
To: Mo Zanaty (mzanaty)
Cc: Harald Alvestrand; rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Is bundle just a port override?

Hey Mo,

On 19.03.13, 16:28, Mo Zanaty (mzanaty) wrote:
> I understand the RTP session rules, but they are a matter for AVTCORE,
> and several drafts already detail the RTP considerations for
> multiplexing streams, of potentially different media types, over the
> same port (using plain RTP not SHIM). Bundle does not need to solve that
> (solved) problem, it just needs to signal which port(s) to use. If we
> feel we should signal some sort of human-level warning about RTP mux
> rules when signaling ports, the attribute can be named a=3Drtp-mux:
> instead of a=3Dport .
>=20
> =20
>=20
> I don't see how any grouping semantics help with any of the rules.
> Actually, I think grouping semantics hurt, not just due to complexity,
> but also due to ambiguity about which attributes are inherited or
> overridden from other m-blocks. Keeping all the m-block attributes
> independent seems simpler and clearer. If an attribute needs to be
> consistent across m-blocks, repeating it seems simpler and clearer than
> inheritance/override rules across m-blocks. (Of course, if all m-blocks
> need the same attribute, it can be defined at session level instead of
> repeating in all media levels.)
>=20
> =20
>=20
> In my simple (perhaps too simple) mind, all we're trying to do in bundle
> is temporarily lie on the m-line port to avoid confusing
> peers/intermediaries. In the process, I think we have confused ourselves
> about what is truly needed to accomplish this deception. Or maybe I'm
> the only one confused...

In your original mail you seemed to be suggesting something similar to:

http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-00

(Sometimes referred to Cundle for Cullen's Bundle)

or this

http://tools.ietf.org/html/draft-alvestrand-one-rtp-01

(Also known as One RTP)

Both would start by offering multiple ports and fall back to a single
port if bundling is supported.

The concern that has been expressed with them is that in case of
bundling, non-use of the discarded RTP ports would cause some SBCs to
believe that there's a problem with the session which may lead to the
SBC tearing down the call.

Hope this helps,
Emil

>=20
> =20
>=20
> Mo
>=20
> =20
>=20
> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Tuesday, March 19, 2013 5:03 AM
> *To:* Mo Zanaty (mzanaty)
> *Cc:* mmusic@ietf.org; rtcweb@ietf.org
> *Subject:* Re: [MMUSIC] Is bundle just a port override?
>=20
> =20
>=20
> On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
>=20
>     Does bundle imply anything beyond a simple port override of the
>     m-line port? If not, then why not just directly signal the port
>     override in an attribute without any grouping semantics?
>=20
>=20
> No, it's not just a port override.
>=20
> BUNDLE shoves things into the same RTP session, which means that one has
> to obey the rules for being in the same RTP session:
> - Security done consistently
> - RTCP-mux done consistently
> - No SSRC collision
> - No payload type collision
> So it's a good deal more than just a port override.
>=20
> Magnus argued in favour of a solution that inserted a multiplex layer,
> so that one could use the same ports but still have stuff in different
> RTP sessions, but that did not appeal to many.
>=20
>=20
> =20
>=20
> Offer to mux audio and video on the same port:
>=20
> m=3Daudio 10000 RTP/AVP 0
>=20
> m=3Dvideo 10002 RTP/AVP 31
>=20
> a=3Dport 10000
>=20
> i=3DI really want 10000, but lied on the m-line for fear of confusing you=
.
> Confused yet?
>=20
> =20
>=20
> Answer supports the port override attribute and agrees to mux audio and
> video:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40000 RTP/AVP 31
>=20
> a=3Dport 40000
>=20
> ...so audio and video ports are 10000<->40000.
>=20
> =20
>=20
> Answer supports the port override attribute but doesn't want to demux on
> his end:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40002 RTP/AVP 31
>=20
> a=3Dport 40002
>=20
> ...so audio ports are 10000<->40000 and video ports are 10000<->40002.
>=20
> =20
>=20
> Answer doesn't support the port override attribute, or doesn't want
> either end to mux:
>=20
> m=3Daudio 40000 RTP/AVP 0
>=20
> m=3Dvideo 40002 RTP/AVP 31
>=20
> ...so audio ports are 10000<->40000 and video ports are 10002<->40002.
>=20
> =20
>=20
> Either end can re-offer without lies about ports on the m-line after
> confirming the peer is not confused by muxing, if they want to avoid
> confusing intermediaries.
>=20
> =20
>=20
> Has this approach been tried yet? Dismissed?
>=20
> =20
>=20
> Mo
>=20
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
>=20
> mmusic mailing list
>=20
> mmusic@ietf.org 
>=20
> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> =20
>=20
>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20

--=20
https://jitsi.org


From worley@shell01.TheWorld.com  Tue Mar 19 12:37:38 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6997821F8DA4 for ; Tue, 19 Mar 2013 12:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.240,  BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, 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 PoO9HjJBaXEq for ; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5603A21F8C4F for ; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2JJam06021311; Tue, 19 Mar 2013 15:36:50 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2JJalv9764565; Tue, 19 Mar 2013 14:36:47 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2JJakU4763611; Tue, 19 Mar 2013 15:36:46 -0400 (EDT)
Date: Tue, 19 Mar 2013 15:36:46 -0400 (EDT)
Message-Id: <201303191936.r2JJakU4763611@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "Mo Zanaty (mzanaty)" 
In-reply-to: <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> (mzanaty@cisco.com)
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com>
Cc: rtcweb@ietf.org, mmusic@ietf.org
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 19:37:38 -0000

> From: "Mo Zanaty (mzanaty)" 
> 
> Those drafts use the SDP grouping framework
> (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity
> and ambiguity for something which can be solved in a much simpler
> and clearer way with a single attribute: a=port . (Or, if we
> want to warn humans about RTP muxing, then name it a=rtp-mux:,
> but machines won't care about the name, and their RTP
> implementations already know how to deal with muxing if they use
> this attribute, so stronger warnings are unnecessary.)
> 
> Regarding the concern about non-use of the discarded RTP ports
> confusing SBCs, see this part of my original message [with
> clarifications], which is what the current bundle draft also
> suggests:
> 
> > Either end can re-offer without lies about ports on the m-line after
> > confirming the peer is not confused by muxing, if they want to avoid
> > confusing intermediaries [that may monitor the unused ports].

It's messier than that, unfortunately.

One requirement is that after negotiation is completed, the negotiated
transport associations (as seen by a legacy intermediary) must match
the actual media flows.

Another requirement is that two media descriptions shouldn't use the
same port (because a lot of legacy SBCs can't handle that).  This
applies to offer/answer updates as well as original offers/answers.

So what we want is a way for a media description to say, "I'm
reporting port zero so SBCs think this MD is rejected, but I'm
actually using port 1234 (which is officially reported in another
MD)."

There are also situations where the we want to signal perferences as
to which media descriptions share ports with which other media
descriptions.

Dale

From worley@shell01.TheWorld.com  Tue Mar 19 12:37:38 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA10121F8DAE for ; Tue, 19 Mar 2013 12:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level: 
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 f0KfFLtf1aKt for ; Tue, 19 Mar 2013 12:37:38 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5643421F8D85 for ; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2JJbEvb022620; Tue, 19 Mar 2013 15:37:17 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2JJbECB763258; Tue, 19 Mar 2013 14:37:14 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2JJbEWO763574; Tue, 19 Mar 2013 15:37:14 -0400 (EDT)
Date: Tue, 19 Mar 2013 15:37:14 -0400 (EDT)
Message-Id: <201303191937.r2JJbEWO763574@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Magnus Westerlund 
In-reply-to: <514767D1.3000906@ericsson.com> (magnus.westerlund@ericsson.com)
References: <51425974.9070608@ericsson.com> <201303151431.r2FEVHJ9498642@shell01.TheWorld.com> <514767D1.3000906@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 19:37:38 -0000

> From: Magnus Westerlund 
> 
> I thus propose a more generic version of your text in the D. section:
> 
>    This appendix describes how an SDP file determines the operation of
>    an RTSP session.  Thus, it is worth pointing out that the
>    interpretation of the SDP is done in the context of the SDP receiver
>    is the one being configured.  This is the same as in SAP [RFC2974],
>    this differs from SDP Offer/Answer [RFC3264] where the SDP describes
>    what the peer agent is ready to receive and willing to send.

I agree with the overall concept, but there are some edits that would
help:

There's some flaw in the wording around "of the SDP receiver is the
one".  Perhaps it was intended to be "... of the SDP receiver, which
is the one being configured."?

Strictly, in "the same as in SAP [RFC2974],", the final "," should be
";", as the two things being joined are complete sentences.

The final clause does not seem definite enough to me, as "the peer
agent" is used rather than "the agent sending the SDP".  I suppose
that is the meaning that it must have, but in many situations, "the
peer agent" is used to denote the agent at the *other end* of the
connection from the agent being described.  So I would say "where the
SDP describes what the agent sending it is ready to receive and
willing to send."

Dale

From harald@alvestrand.no  Tue Mar 19 15:20:00 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2621F8CF5; Tue, 19 Mar 2013 15:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.699
X-Spam-Level: 
X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 AVJSdYUQ3BAI; Tue, 19 Mar 2013 15:19:59 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB4B21F8CEC; Tue, 19 Mar 2013 15:19:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26CC039E1EE; Tue, 19 Mar 2013 23:19:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNosivuv1Tj8; Tue, 19 Mar 2013 23:19:56 +0100 (CET)
Received: from [172.30.42.73] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1B2B139E0A7; Tue, 19 Mar 2013 23:19:56 +0100 (CET)
Message-ID: <5148E48A.4060202@alvestrand.no>
Date: Tue, 19 Mar 2013 23:19:54 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" 
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Mar 2013 22:20:00 -0000

On 03/19/2013 07:43 PM, Mo Zanaty (mzanaty) wrote:
> Hi Emil,
>
> Those drafts use the SDP grouping framework (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity and ambiguity for something which can be solved in a much simpler and clearer way with a single attribute: a=port . (Or, if we want to warn humans about RTP muxing, then name it a=rtp-mux:, but machines won't care about the name, and their RTP implementations already know how to deal with muxing if they use this attribute, so stronger warnings are unnecessary.)

To me, what you're describing is a grouping (the ports with the same 
a=rtp-mux:port attribute form a single RTP session), so it seems to me 
that using the grouping framework and using matching a=rtp-mux:port 
attribute have exactly the same level of complexity - but in the case of 
a=rtp-mux:port, you lose the ability to use ICE attributes to negotiate 
the actual ports, addresses and network interfaces actually used - so 
the a=rtp-mux:port mechanism will actually turn out to be *more* complex 
than the grouping framework once you've added all the other features you 
need to take advantage of ICE and so on.

So - after I've thought about it for a while - I think calling it a 
"port override" is not just misleading, the implementation you're 
suggesting will be more complex than using the grouping framework.

Why invent square wheels when the pentagonal ones are doing just fine?


From Simo.Veikkolainen@nokia.com  Wed Mar 20 02:57:03 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1056C21F8AD5 for ; Wed, 20 Mar 2013 02:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.924
X-Spam-Level: 
X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=1.075,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PgBanuwXGTT for ; Wed, 20 Mar 2013 02:57:02 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48221F8AD4 for ; Wed, 20 Mar 2013 02:57:01 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2K9uwK1008812; Wed, 20 Mar 2013 11:57:00 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Mar 2013 11:56:58 +0200
Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0328.011; Wed, 20 Mar 2013 09:56:58 +0000
From: 
To: , 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJGpsaYWyC2xxJUaG2b4cQbjFxZiuU3ug
Date: Wed, 20 Mar 2013 09:56:57 +0000
Message-ID: 
References: <5148049B.6090205@cisco.com>
In-Reply-To: <5148049B.6090205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-version: 3.5.9.3
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJvrcT2VmD4iRqNDtz3NKc/LOn9Ls0KOL+40Vh61iFNHGfzpjcTACdIULNp3RnsSHdlPCE/lblMg9cG3A9PxJtPVAo/QrzI/wV/xYZvKGnpHkj9utSV2jnifPRoPWbfL5o5zQp9XCh/0lEeKL/oZHyHOAtRH+rahuoJKWQ7WayRAPYDuYdWnRvmXKYFJhrx2brlh3yPHveRVrRIJtsUik1yjU/ym0/gsPWw0IDYlR+Xlc8X4x8SSYaTfkCZ53TklZhR4NSUEgwXjYwetfjqEw7aw==
x-originating-ip: [62.78.254.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Mar 2013 09:56:58.0927 (UTC) FILETIME=[432303F0:01CE2551]
X-Nokia-AV: Clean
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Mar 2013 09:57:03 -0000

I went through the discussion, and my reading is that there is agreement on=
 not allowing ccap to be used for alternative IP address negotiation.

That could be made clear in the text e.g. by modifying the second sentence =
Flemming quoted to read:


    The 'ccap' attribute MUST NOT be used to select
    between different IP connection addresses (e.g. between=20
    "IP4" and "IP6" address families or different IP addresses=20
     within the same IP address family).


The ccap attribute should be able to carry either an IP or PSTN address; th=
at way either a PSTN or an IP bearer could be offered as the highest priori=
ty configuration (in the "m=3D" line).  However, if we want to clarify the =
intended use of ccap, we could modify the first sentence to read:


   The 'ccap' capability attribute is intended for offering
   alternative connection addresses where the 
   is "IN" or "PSTN", i.e. selecting between an IP based
   bearer or a circuit-switched bearer.


Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext Flemming Andreasen
Sent: 19. maaliskuuta 2013 8:24
To: mmusic
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft=
-ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

As you may have seen, there has recently been some list discussion on the "=
connection data capability" defined in
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability negot=
iation capabilities for what amounts to the "c=3D" line in regular SDP, and=
 as such enables negotiation of network type (such as "IN") and IP-address =
information (v4 and v6 addresses). The Standards Track mechanism for negoti=
ating and determining alternative IP-address information today is ICE, and =
hence the draft currently includes the following wording:

The 'ccap' capability attribute is intended to
    be used only when there is no other mechanism available for
    negotiating alternative connection address information, such as when
    the  is different among the alternative addresses (e.g.
    "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
    situations where an existing mechanism (such as Interactive
    Connectivity Establishment (ICE) [RFC5245]) can be used to select
    between different connection addresses (e.g.  "IP4" and "IP6" or
    different IP addresses within the same IP address family).


The above text has led to some confusion as to exactly when and what "ccap"=
 can be used for. More specifically, is it/should it ever be allowed to use=
 "ccap" to convey an IP4 or IP6 address, and if so, under what circumstance=
s ?

If you have an opinion, please let us know.

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that depen=
dency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be gener=
ally useful in line with the overall capability negotiation framework (as o=
pposed to targeted at one specific use case with one specific value)
- There are scenarios where ICE cannot be used, even if implemented (e.g. i=
ce-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of IC=
E support


Thanks

-- Flemming

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

From magnus.westerlund@ericsson.com  Wed Mar 20 08:11:49 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DE121F8FC4 for ; Wed, 20 Mar 2013 08:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.619
X-Spam-Level: 
X-Spam-Status: No, score=-106.619 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+bZ6MOjvIPY for ; Wed, 20 Mar 2013 08:11:48 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 694CE21F8470 for ; Wed, 20 Mar 2013 08:11:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-82-5149d1ab9dc6
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CB.45.10459.BA1D9415; Wed, 20 Mar 2013 16:11:39 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 20 Mar 2013 16:11:39 +0100
Message-ID: <5149D1AA.4010805@ericsson.com>
Date: Wed, 20 Mar 2013 16:11:38 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "mmusic (E-mail)" ,  draft-ietf-mmusic-sctp-sdp@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje7qi56BBjPPG1pMeTOD1WLq8scs DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAldGy94djAVPdSpaVnxjaWD8rdzFyMkhIWAi cad1MhuELSZx4d56IJuLQ0jgJKPE7u59rBDOckaJGf3zWUCqeAW0JSZ2n2EGsVkEVCWm9DeA xdkELCRu/mgEmyQqECzx89UZqHpBiZMzn4DZIgKhEi96VrGD2MICBhL7585mgtgsKbHlRTtY nFlAT2LK1RZGCFteonnrbLBdQkB7G5o6WCcw8s9CMnYWkpZZSFoWMDKvYmTPTczMSS833MQI DLKDW37r7mA8dU7kEKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzWp2yn S2hdZb2sUyprtL3n8Xb2bb4zpHslRBPz+qZofXR5UR247I7RRdeUE7tWW9ettyxtl3Y0uZZt t0RiUiJD4M7SS4p+OdLqC6qXfBC22vDjUmz0NOEJVX3P1MqvHP/i6dGX+UjalfPyNdWfrKcd LF6sWLWhwIDj55xD8xOm//BpOqXoJq3EUpyRaKjFXFScCABajBv6AAIAAA==
Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Mar 2013 15:11:49 -0000

Hi,

I have reviewed the SDP description of SCTP and have some comments and
suggestions.

1. My first comments is a very general one and concerns the relationship
between the proposed SCTP related proto identifiers and ICE for the
DTLS/SCTP encapsulation.

When ICE was defined it was natural to include ICE by reftorfitting it
to existing proto identifiers. However, given that this specification
intorduce a number of new identifiers I do woner if we should be more
explicit about the ICE usage in the proto field. I think have both pro
and cons for this.

So my considerations is basically to include specification of
ICE/DTLS/SCTP, where the lower layer transport is defined by what ICE
agrees on. This makes a lot of sense given that ICE can in fact arrive
on the usage of TCP/framing/DTLS/SCTP, TCP/TURN/DTLS/SCTP in addition to
more expected choices as UDP/DTLS/SCTP. This makes it clears that you do
require ICE to negotiate this transport flow. At the same time it is a
significant downside if ones negotiation needs are to chose between
using ICE or a specific lower layer transport.

These comments doesn't apply when one runs SCTP on top of IP.

2. Section 1:
RFC4145 [RFC4145] specifies a general mechanism for
   describing and establishing TCP (Transmission Control Protocol)
   streams.

I do dislike that usage of the RFC number as the explanation of what the
referenced document is. The previous sentence is how I prefer it to be
done:
   SDP (Session Description Protocol) [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.

Use the document title or an abbreviated explanation for what the
referenced document specifies and one gets much better flow in the
reading as one don't have stop look up the reference to find out what is
referred to.

3. Section 1:
I think having first a paragraph for SCTP and then having "Additionaly
.." with the other two protos are bit strange. Why not simpley say. This
document defines three proto identifiers: list of them with explnation.

4. Section 1:
   DTLS/SCTP :  to allow the usage of SCTP on top of the Datagram
      Transport Layer Security (DTLS) protocol, as defined in
      [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP.  SCTP over DTLS is
      used by the RTCWeb protocol suite for transporting non- media data
      between browsers.

This definitions says nothing of the lower transport layer for DTLS/SCTP
even if UDP is referred to in a later section. I think this needs to be
clarified and discussed in the context of which lower layers do we
expect to be supported? From my perspective I think two makes sense.
ICE/DTLS/SCTP that allows ICE to negoiate what ever and then
UDP/DTSL/SCTP that only uses UDP as lower layer. Lets other add other
variants in the future if needed.

5. Section 3:
   The 'DTLS/SCTP' protocol identifier indicates that the media
   described will use SCTP on top of the Datagram Transport Layer
   Security (DTLS) protocol as specified in
   [I-D.tuexen-tsvwg-sctp-dtls-encaps].

I would like to point out that the referenced document does not at all
indicate what lower layer is being used under DTLS.

6. Section 4.1:

This section discuss the usage of the "data channels" within the SCTP
association. My personal position is that for the moment this appears to
be unnecessary. The most important part is the SCTP association
establishment. Then one can discuss the general application using the
SCTP association as whole. Examples of such are WebRTC data channel.

If anyone want stream level information in SDP then I propose that this
is handled as a extension to this signaling, not an from the start
included functionality as we don't appear to have clear requirement for
that.

7. Section 4.2:

What are the requirements behind being able to establish multiple SCTP
association over the same DTLS connection? I am very unclear why this
would be required, and if not really needed I would suggest keeping
things simple.

8. Section 4.3: I guess this can for the moment be removed as it appears
to be taken care in other places, such as the RTCWEB WG data channel
protocol proposal.

9. If you are removing the multiple association and the "data channel"
parameters then most of the issues in section 5 vanish. If not I have
additional feedback on this section.

10. Section 8.

   Current NATs do not typically support SCTP.  As an alternative to
   design SCTP specific NATs, Encapsulating SCTP into UDP
   [I-D.tuexen-sctp-udp-encaps] makes it possible to use SCTP in
   networks with legacy NAT and firewalls not supporting SCTP.

First of all, there is a WG version for this document:
draft-ietf-tsvwg-sctp-udp-encaps-14. Which is in IESG evaluation. Thus I
wonder why signalling for this is not included when all the other
options are included, even less mature ones then this?

To me it looks like this document need to have some high level decisions
on what to include and not and then try to finish it up within the
agreed constraints. From my perspective I think it should focus on a
single SCTP association per m= line and the actual SCTP association.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From pkyzivat@alum.mit.edu  Wed Mar 20 09:55:07 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1211E80D1 for ; Wed, 20 Mar 2013 09:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Level: 
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150,  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 38BDXn2FEBz8 for ; Wed, 20 Mar 2013 09:55:07 -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 DA72611E80A4 for ; Wed, 20 Mar 2013 09:55:06 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta12.westchester.pa.mail.comcast.net with comcast id Doq31l0050SCNGk5Csv69E; Wed, 20 Mar 2013 16:55:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id Dsv51l00t3ZTu2S3Vsv6wG; Wed, 20 Mar 2013 16:55:06 +0000
Message-ID: <5149E9E9.10900@alum.mit.edu>
Date: Thu, 21 Mar 2013 00:55:05 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5149D1AA.4010805@ericsson.com>
In-Reply-To: <5149D1AA.4010805@ericsson.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=1363798506; bh=AvqESaVLL1f7Q/ghyDHVoWrpKwwLlemmMEp3S0Pcfmk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=P+qUOcH1VUxhRn20/GNUS9r99RB4qLcKsW2vReC+v7kRT3siBhVUrg2P/TA+IunCH MiGmtSOkHB5hATlhZzgP0zk1XXi4guTVOnOcewBQ3jAONt54M+KBVziFQIlD7zbHGE DxdJnc8YqzIxLSS9zBjzd+oJGnbmUf5UggTCpGNzvS4PU9yQMCbop96rKLzFc1u9Mt gVzDb38bCcqPGXK1OVVQ43W7DvImzdgNOpa6e/FiqoYkBXWbgiJ6PpSUvHDr7uu+xi oC9y2P4bHi4kprYKvEswQ/jAAN+Q2J5sF8pHcvHS7OnVR6o81n84eim+wfRO/1WVlo fOsMeLo4/jfkA==
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Mar 2013 16:55:07 -0000

Magnus,

Some comments on your review, from a CLUE perspective:

On 3/20/13 11:11 PM, Magnus Westerlund wrote:

> 6. Section 4.1:
>
> This section discuss the usage of the "data channels" within the SCTP
> association. My personal position is that for the moment this appears to
> be unnecessary. The most important part is the SCTP association
> establishment. Then one can discuss the general application using the
> SCTP association as whole. Examples of such are WebRTC data channel.
>
> If anyone want stream level information in SDP then I propose that this
> is handled as a extension to this signaling, not an from the start
> included functionality as we don't appear to have clear requirement for
> that.

Who is "we"?

In CLUE we expect to use this mechanism for a CLUE data channel.
And we intend to do so in pure sip-sip cases as well as webrtc-sip and 
webrtc-webrtc cases.

While webrtc-webrtc may have an independent mechanism to work out the 
channel usage, that is certainly not so for sip-sip sessions.

So I think "we" (CLUE) have a requirement to negotiate channel usage in SDP.

> 7. Section 4.2:
>
> What are the requirements behind being able to establish multiple SCTP
> association over the same DTLS connection? I am very unclear why this
> would be required, and if not really needed I would suggest keeping
> things simple.

I agree there has been no compelling need advanced for multiple SCTP 
associations over the same DTLS connection. But the fact is that SCTP 
has its own notion of port, and that needs to be dealt with one way or 
another. At a minimum this document should specify what SCTP port is to 
be used when conforming to this specification.

> 8. Section 4.3: I guess this can for the moment be removed as it appears
> to be taken care in other places, such as the RTCWEB WG data channel
> protocol proposal.

See above. That doesn't meet CLUE needs.

	Thanks,
	Paul

From mzanaty@cisco.com  Wed Mar 20 21:43:31 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6611E8108; Wed, 20 Mar 2013 21:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.399
X-Spam-Level: 
X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 Z9JrJcaT4VSW; Wed, 20 Mar 2013 21:43:29 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1611E80BA; Wed, 20 Mar 2013 21:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3247; q=dns/txt; s=iport; t=1363841009; x=1365050609; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AyICW4RX5JOzl2wntRMXwfu2dxYeeWCRvV2IhpDVSTI=; b=AcIAjnPdeWUWcceqKeK8AZbzF+gbDHjfhgnLBbiipLTdr10xaGGNuBS+ 01f+tM+PGfwtrEUm6OuusbF5rI2Nfx55ExQs5xbGOBaPf5AbkSvUgR8qd 8bv66olbJTHmhZG8jmzbyDpa/Tx72g0HZIuh/Glexa9kedo9bmy/GNflP g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAM6NSlGtJV2a/2dsb2JhbABDxTyBWRZ0giQBAQEDAScTPwUHBAIBCBEEAQELFAkHMhQJCAIEDgUIiAYGwlSOXzEHBoJZYQOnYoMKgig
X-IronPort-AV: E=Sophos;i="4.84,883,1355097600"; d="scan'208";a="189804172"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2013 04:43:28 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2L4hSgb021424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 04:43:28 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 23:43:28 -0500
From: "Mo Zanaty (mzanaty)" 
To: "Dale R. Worley" 
Thread-Topic: [rtcweb] [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXg//+IxWj///4R0A==
Date: Thu, 21 Mar 2013 04:43:27 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com>
In-Reply-To: <201303191936.r2JJakU4763611@shell01.TheWorld.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.216.176]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 04:43:31 -0000

Hi Dale,

In your draft (and Richard's), I understand your motivation to answer with =
port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff po=
rts so they don't smell anything fishy. I won't comment on whether they wil=
l react better to nostril-plugging than fishy smells, because I don't know,=
 but that is orthogonal to what I'm describing here.

Your bundle alternatives (and Richard's) also work fine with a simple attri=
bute without complex grouping semantics.

Offer to mux audio and video on the same port:
m=3Daudio 10000 RTP/AVP 0
m=3Dvideo 10002 RTP/AVP 31
a=3Dport 10000
i=3DI really want 10000, but lied on the m-line for fear of confusing you. =
Confused yet?
=20
Answer supports the port override attribute and agrees to mux audio and vid=
eo:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
a=3Dport 40000
...so audio and video ports are 10000<->40000.
=20
Answer doesn't support the port override attribute, or doesn't want to mux:
m=3Daudio 40000 RTP/AVP 0
m=3Dvideo 40002 RTP/AVP 31
...so audio ports are 10000<->40000 and video ports are 10002<->40002.

Cheers,
Mo


-----Original Message-----
From: Dale R. Worley [mailto:worley@ariadne.com]=20
Sent: Tuesday, March 19, 2013 3:37 PM
To: Mo Zanaty (mzanaty)
Cc: emcho@jitsi.org; rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

> From: "Mo Zanaty (mzanaty)" 
>=20
> Those drafts use the SDP grouping framework
> (a=3Dgroup:BUNDLE/TOGETHER), which I think is unnecessary complexity
> and ambiguity for something which can be solved in a much simpler
> and clearer way with a single attribute: a=3Dport . (Or, if we
> want to warn humans about RTP muxing, then name it a=3Drtp-mux:,
> but machines won't care about the name, and their RTP
> implementations already know how to deal with muxing if they use
> this attribute, so stronger warnings are unnecessary.)
>=20
> Regarding the concern about non-use of the discarded RTP ports
> confusing SBCs, see this part of my original message [with
> clarifications], which is what the current bundle draft also
> suggests:
>=20
> > Either end can re-offer without lies about ports on the m-line after
> > confirming the peer is not confused by muxing, if they want to avoid
> > confusing intermediaries [that may monitor the unused ports].

It's messier than that, unfortunately.

One requirement is that after negotiation is completed, the negotiated
transport associations (as seen by a legacy intermediary) must match
the actual media flows.

Another requirement is that two media descriptions shouldn't use the
same port (because a lot of legacy SBCs can't handle that).  This
applies to offer/answer updates as well as original offers/answers.

So what we want is a way for a media description to say, "I'm
reporting port zero so SBCs think this MD is rejected, but I'm
actually using port 1234 (which is officially reported in another
MD)."

There are also situations where the we want to signal perferences as
to which media descriptions share ports with which other media
descriptions.

Dale

From juberti@google.com  Wed Mar 20 22:11:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD721F87D3 for ; Wed, 20 Mar 2013 22:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.277
X-Spam-Level: 
X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 AjTDaIpATcWj for ; Wed, 20 Mar 2013 22:11:39 -0700 (PDT)
Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A500721F8821 for ; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
Received: by mail-ia0-f182.google.com with SMTP id u8so2096845iag.27 for ; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=n+8GNuWa1ReekamkcioQQX3DuG7LAxDUbGd0Jx9tVYw=; b=a6U+IEphxaIZ4Ar2nBf90Yyw5Sw91k9zSvM+roEBz/Arxib5lsEZHFzE4BGYb7VWTU 1GTOgoXSq9FKYzw9uTQ4x+4mGIf2UnwdCa/NOEeRNu8zq4S5Mc0TovUyZGAXmsF6CTOX cPx/wELZfJAHOFz8M9T8Kzed7/jqL10c69332fK8uV/GSgPE7WI/k97+ja4dbYaB8cqH Vo6J9g0tgoulW3ZaVur1cPLDyuXezJ2drkWuqqS91E8xWWbGdJgzhofDLsywPkYDbw8U a2ytpkhhSBD6lr5yb5nMNhyJE6d+OsUfmle2X7F3HYzPVV4x1IEy1R6Mqhd4G1ASO8z9 JGnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=n+8GNuWa1ReekamkcioQQX3DuG7LAxDUbGd0Jx9tVYw=; b=gLNfCIoXFXFgExD8CxzVs8V66ybGNGUybkZ2pL4ilgYBldclbI8YL9WRkpHCdYReh8 KA5PngUgsrm0Drz0VpHMS9lDMEGb1A1GvAGXB3gohi01GLftIEZXgNxZBzcicl+x+4bb Dcq+riduh0GvvxbXXsRdQzEBTt1A68r87d3tgfyyzx/s7nvr2Dz/1nSzZJOhA3oCiBOw N+PsTNW5nrnsNZoJTRjtl5N7HkntN9AHvh4SDbQgazQhV5fLyjfuROwcKtARm8tTXwY2 RDGaMr97zs9JNuuMlETltK1G3/IBe0ugQfbmAnK7TM/Z5tQ4KhZPGrB9Vz6ElCuZ/ePd A1Og==
X-Received: by 10.42.175.73 with SMTP id az9mr10595920icb.55.1363842692172; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.250.18 with HTTP; Wed, 20 Mar 2013 22:11:12 -0700 (PDT)
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
From: Justin Uberti 
Date: Wed, 20 Mar 2013 22:11:12 -0700
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Content-Type: multipart/alternative; boundary=90e6ba6e8f30326b3704d8685f8e
X-Gm-Message-State: ALoCoQmbVSggiG6ARiSzOe7HAq2l+tcJFlGte3dTt1eSHPH2iIR49fo/3e93+Yemc3CUrl1gx4ST3a7fWdDxi0mFJB+h+5isHUflPhTyNQnT1FUSlBRWYhYiI4VyUYj2wZCramcEmP5S2erio9mfOH4we60PWpcQxpxAFFwS/l2ULT6IhQVcYk2Am3K684+hRMljD54f1QmC
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 05:11:40 -0000

--90e6ba6e8f30326b3704d8685f8e
Content-Type: text/plain; charset=UTF-8

The point of the different ports is not just to make intermediaries happy,
but to ensure that we're successful when talking to an endpoint who doesn't
support BUNDLE. There are a litany of problems that have been identified
when the same ports are used on the offerer side and the answerer is
BUNDLE-unaware.

On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (mzanaty) wrote:

> Hi Dale,
>
> In your draft (and Richard's), I understand your motivation to answer with
> port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff
> ports so they don't smell anything fishy. I won't comment on whether they
> will react better to nostril-plugging than fishy smells, because I don't
> know, but that is orthogonal to what I'm describing here.
>
> Your bundle alternatives (and Richard's) also work fine with a simple
> attribute without complex grouping semantics.
>
> Offer to mux audio and video on the same port:
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
> i=I really want 10000, but lied on the m-line for fear of confusing you.
> Confused yet?
>
> Answer supports the port override attribute and agrees to mux audio and
> video:
> m=audio 40000 RTP/AVP 0
> m=video 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
> a=port 40000
> ...so audio and video ports are 10000<->40000.
>
> Answer doesn't support the port override attribute, or doesn't want to mux:
> m=audio 40000 RTP/AVP 0
> m=video 40002 RTP/AVP 31
> ...so audio ports are 10000<->40000 and video ports are 10002<->40002.
>
> Cheers,
> Mo
>
>
> -----Original Message-----
> From: Dale R. Worley [mailto:worley@ariadne.com]
> Sent: Tuesday, March 19, 2013 3:37 PM
> To: Mo Zanaty (mzanaty)
> Cc: emcho@jitsi.org; rtcweb@ietf.org; mmusic@ietf.org
> Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?
>
> > From: "Mo Zanaty (mzanaty)" 
> >
> > Those drafts use the SDP grouping framework
> > (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity
> > and ambiguity for something which can be solved in a much simpler
> > and clearer way with a single attribute: a=port . (Or, if we
> > want to warn humans about RTP muxing, then name it a=rtp-mux:,
> > but machines won't care about the name, and their RTP
> > implementations already know how to deal with muxing if they use
> > this attribute, so stronger warnings are unnecessary.)
> >
> > Regarding the concern about non-use of the discarded RTP ports
> > confusing SBCs, see this part of my original message [with
> > clarifications], which is what the current bundle draft also
> > suggests:
> >
> > > Either end can re-offer without lies about ports on the m-line after
> > > confirming the peer is not confused by muxing, if they want to avoid
> > > confusing intermediaries [that may monitor the unused ports].
>
> It's messier than that, unfortunately.
>
> One requirement is that after negotiation is completed, the negotiated
> transport associations (as seen by a legacy intermediary) must match
> the actual media flows.
>
> Another requirement is that two media descriptions shouldn't use the
> same port (because a lot of legacy SBCs can't handle that).  This
> applies to offer/answer updates as well as original offers/answers.
>
> So what we want is a way for a media description to say, "I'm
> reporting port zero so SBCs think this MD is rejected, but I'm
> actually using port 1234 (which is officially reported in another
> MD)."
>
> There are also situations where the we want to signal perferences as
> to which media descriptions share ports with which other media
> descriptions.
>
> Dale
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--90e6ba6e8f30326b3704d8685f8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The point of the different ports is not just to make inter=
mediaries happy, but to ensure that we're successful when talking to an=
 endpoint who doesn't support BUNDLE. There are a litany of problems th=
at have been identified when the same ports are used on the offerer side an=
d the answerer is BUNDLE-unaware.



On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (=
mzanaty) <mzanaty@cisco.com> wrote:


Hi Dale,



In your draft (and Richard's), I understand your motivation to answer w=
ith port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that snif=
f ports so they don't smell anything fishy. I won't comment on whet=
her they will react better to nostril-plugging than fishy smells, because I=
 don't know, but that is orthogonal to what I'm describing here.




Your bundle alternatives (and Richard's) also work fine with a simple a=
ttribute without complex grouping semantics.




Offer to mux audio and video on the same port:

m=3Daudio 10000 RTP/AVP 0

m=3Dvideo 10002 RTP/AVP 31

a=3Dport 10000

i=3DI really want 10000, but lied on the m-line for fear of confusing you. =
Confused yet?



Answer supports the port override attribute and agrees to mux audio and vid=
eo:

m=3Daudio 40000 RTP/AVP 0


m=3Dvideo 0 RTP/AVP 31 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- Dale's =
variant to answer with port 0


a=3Dport 40000

...so audio and video ports are 10000<->40000.




Answer doesn't support the port override attribute, or doesn'=
t want to mux:


m=3Daudio 40000 RTP/AVP 0

m=3Dvideo 40002 RTP/AVP 31

...so audio ports are 10000<->40000 and video ports are 10002<->=
;40002.




Cheers,

Mo






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

From: Dale R. Worley [mailto:worley@a=
riadne.com]

Sent: Tuesday, March 19, 2013 3:37 PM

To: Mo Zanaty (mzanaty)


Cc: emcho@jitsi.org; rtcweb@ie=
tf.org; mmusic@ietf.org

Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?



> From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>

>

> Those drafts use the SDP grouping framework

> (a=3Dgroup:BUNDLE/TOGETHER), which I think is unnecessary complexity
> and ambiguity for something which can be solved in a much simpler

> and clearer way with a single attribute: a=3Dport <port>. (Or, i=
f we

> want to warn humans about RTP muxing, then name it a=3Drtp-mux:<por=
t>,

> but machines won't care about the name, and their RTP

> implementations already know how to deal with muxing if they use

> this attribute, so stronger warnings are unnecessary.)

>

> Regarding the concern about non-use of the discarded RTP ports

> confusing SBCs, see this part of my original message [with

> clarifications], which is what the current bundle draft also

> suggests:

>

> > Either end can re-offer without lies about ports on the m-line af=
ter

> > confirming the peer is not confused by muxing, if they want to av=
oid

> > confusing intermediaries [that may monitor the unused ports].



It's messier than that, unfortunately.



One requirement is that after negotiation is completed, the negotiated

transport associations (as seen by a legacy intermediary) must match

the actual media flows.



Another requirement is that two media descriptions shouldn't use the
same port (because a lot of legacy SBCs can't handle that). =C2=A0This<=
br>
applies to offer/answer updates as well as original offers/answers.



So what we want is a way for a media description to say, "I'm

reporting port zero so SBCs think this MD is rejected, but I'm

actually using port 1234 (which is officially reported in another

MD)."



There are also situations where the we want to signal perferences as

to which media descriptions share ports with which other media

descriptions.



Dale

_______________________________________________


rtcweb mailing list

rtcweb@ietf.org

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





--90e6ba6e8f30326b3704d8685f8e--

From mzanaty@cisco.com  Wed Mar 20 22:59:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41F21F9002; Wed, 20 Mar 2013 22:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.899
X-Spam-Level: 
X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 1ZcSK++4a2p1; Wed, 20 Mar 2013 22:59:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F320821F8EF1; Wed, 20 Mar 2013 22:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1363845576; x=1365055176; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8zG6tcnrlHeJjsPnZtBDIXvNNfDOZRFzohf+/AJ2RtU=; b=RHwYGQ9yoBA0GkojiZjwVGP+yPXM3+xKv0F/DTymPWZW9REuDVxWNr4l tza3yHMu9YcORNMynUsXL/r0Z5Vg1+VJS8pxXWN5S1CosEGCJtmm3Yb1v lFdsZ63xKhEViQFIKLB/e0JqIAFpiAXxx+D8P2wvx2levusmBdVJDRboi U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMSgSlGtJV2a/2dsb2JhbABDxTqBWBZ0giQBAQEEOj8MBAIBCBEEAQEBChQJBzIUCQgCBA4FCIgMwkiOXzEHBoJZYQOnYoMKgig
X-IronPort-AV: E=Sophos;i="4.84,884,1355097600"; d="scan'208";a="189822883"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2013 05:59:35 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2L5xZ3U015180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 05:59:35 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 00:59:35 -0500
From: "Mo Zanaty (mzanaty)" 
To: Harald Alvestrand 
Thread-Topic: [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXgAAE+TwAANTO+sA==
Date: Thu, 21 Mar 2013 05:59:35 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F695203@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <5148E48A.4060202@alvestrand.no>
In-Reply-To: <5148E48A.4060202@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.216.176]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 05:59:40 -0000

Hi Harald,

You're right, both are essentially groupings, and all of our wheels have ug=
ly angles. To me, the ugly angles in bundle are unnecessary indirection by =
grouping with artificial bindings (mid), and that it pretends to be more th=
an it is. To me, it is just a port override, but with unnecessary indirecti=
on. Why not just say the port you want to use directly?

m=3Daudio 10000 RTP/AVP 0
m=3Dvideo 10002 RTP/AVP 31
a=3Dport 10000

vs.

a=3Dgroup:BUNDLE foo bar
m=3Daudio 10000 RTP/AVP 0
a=3Dmid:foo
m=3Dvideo 10002 RTP/AVP 31
a=3Dmid:bar

Why is the direct approach more complex? Why is ICE any different in either=
 approach?

Cheers,
Mo

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no]=20
Sent: Tuesday, March 19, 2013 6:20 PM
To: Mo Zanaty (mzanaty)
Cc: Emil Ivov; rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Is bundle just a port override?

On 03/19/2013 07:43 PM, Mo Zanaty (mzanaty) wrote:
> Hi Emil,
>
> Those drafts use the SDP grouping framework (a=3Dgroup:BUNDLE/TOGETHER), =
which I think is unnecessary complexity and ambiguity for something which c=
an be solved in a much simpler and clearer way with a single attribute: a=
=3Dport . (Or, if we want to warn humans about RTP muxing, then name =
it a=3Drtp-mux:, but machines won't care about the name, and their RT=
P implementations already know how to deal with muxing if they use this att=
ribute, so stronger warnings are unnecessary.)

To me, what you're describing is a grouping (the ports with the same=20
a=3Drtp-mux:port attribute form a single RTP session), so it seems to me=20
that using the grouping framework and using matching a=3Drtp-mux:port=20
attribute have exactly the same level of complexity - but in the case of=20
a=3Drtp-mux:port, you lose the ability to use ICE attributes to negotiate=20
the actual ports, addresses and network interfaces actually used - so=20
the a=3Drtp-mux:port mechanism will actually turn out to be *more* complex=
=20
than the grouping framework once you've added all the other features you=20
need to take advantage of ICE and so on.

So - after I've thought about it for a while - I think calling it a=20
"port override" is not just misleading, the implementation you're=20
suggesting will be more complex than using the grouping framework.

Why invent square wheels when the pentagonal ones are doing just fine?


From mzanaty@cisco.com  Wed Mar 20 23:51:16 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D733421F8F7B; Wed, 20 Mar 2013 23:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.649
X-Spam-Level: 
X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 rgVRoFD3ZlmB; Wed, 20 Mar 2013 23:51:15 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DE21F8F44; Wed, 20 Mar 2013 23:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20618; q=dns/txt; s=iport; t=1363848675; x=1365058275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L+O9c9uyk1S7VTVQbPOh55mmEkIUnf17SqFTTWt539s=; b=ZYUhWwpu1IUDduRs/T2F11cSwE7PfM212AzErM4fipg7AdxSyCz1WUgu WWw3Iqb75P+o8KVH/noby+Haw6JZTsLqZY3rCEMH3K6TaI02ACreCn4bB 7i0FzJJiHJsSeVeAqYIcm6kSj/yFoXXaasDQWyAy+NuFAKQKCivtYIOKy g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAH+tSlGtJV2Z/2dsb2JhbABDhBCEEL0bam4WdIIkAQEBAwEBAQEgBAZBCwUHBAIBCA4DBAEBCx0DAgICJQsUCQgCBA4FCBOHcwYMr3mSOgSJA4RXgQUWFwQGAQaCJzJhA6digwqBaj4
X-IronPort-AV: E=Sophos;i="4.84,884,1355097600";  d="scan'208,217";a="189833620"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2013 06:51:14 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2L6pEfE029796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 06:51:14 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 01:51:14 -0500
From: "Mo Zanaty (mzanaty)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXg//+IxWj///4R0IACiFsAgABCeCA=
Date: Thu, 21 Mar 2013 06:51:13 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.216.176]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F695235xmbrcdx14ciscoc_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 06:51:17 -0000

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F695235xmbrcdx14ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSnVzdGluLA0KDQpJIHVuZGVyc3RhbmQgdGhlIHBvdGVudGlhbCBwcm9ibGVtcyB3aXRoIGxl
Z2FjeSBlbmRwb2ludHMgYXMgZGVzY3JpYmVkIGluIEEuMiBvZiBDaHJpc3RlcuKAmXMgZHJhZnQs
IG5vdCBqdXN0IGludGVybWVkaWFyaWVzIChBLjQpIHdoaWNoIEkgdGhvdWdodCBEYWxlIHdhcyBz
cGVjaWZpY2FsbHkgY29tbWVudGluZyBhYm91dC4gVGhlIGNvbnN0cmFpbnRzIG9mIGxlZ2FjeSBw
ZWVycyBhbmQgaW50ZXJtZWRpYXJpZXMgaXMgb2J2aW91c2x5IGltcG9ydGFudCB0byB0aGUgb3Zl
cmFsbCBzb2x1dGlvbiwgYnV0IG9ydGhvZ29uYWwgdG8gaG93IHdlIHNpZ25hbCB0aGUgZGVzaXJl
ZCBwb3J0IGluIGEgbmV3IHdheSAoYXMgYSBzaW5nbGUgYXR0cmlidXRlIG9yIHVzaW5nIHRoZSBn
cm91cGluZyBmcmFtZXdvcmspLg0KDQpCVFcsIGhhcyBhbnlvbmUgYWN0dWFsbHkgb2JzZXJ2ZWQg
ZmFpbHVyZXM/IEkgYXNrIGJlY2F1c2UgSSBjb3VsZCBub3QgZ2V0IHByb2R1Y3RzIHRvIGZhaWwg
KHdoZW4gc2ltcGx5IG9mZmVyaW5nIHRoZSBzYW1lIHBvcnRzKSBpbiBteSAobGltaXRlZCkgaW50
ZXJvcCBsYWIuIFNJUGl0IDMwIHdhcyBvbiBteSBjYW1wdXMgbGFzdCBtb250aCwgSSB3aXNoIEkg
d291bGQgaGF2ZSB0ZXN0ZWQgaXQgdGhlcmUgZm9yIG1vcmUgZGF0YSBwb2ludHMuIEkgY2FuIHRy
eSBhdCBTdXBlck9wIG5leHQgbW9udGguIEp1c3QgY2hlY2tpbmcgaWYgc29tZW9uZSBoaXQgYSBy
ZWFsIHByb2JsZW0gYmVmb3JlIHN0YXJ0aW5nIHRoaXMgYnVuZGxlIHBhcnR5Lg0KDQpDaGVlcnMs
DQpNbw0KDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21d
DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjEsIDIwMTMgMToxMSBBTQ0KVG86IE1vIFphbmF0eSAo
bXphbmF0eSkNCkNjOiBEYWxlIFIuIFdvcmxleTsgcnRjd2ViQGlldGYub3JnOyBtbXVzaWNAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbTU1VU0lDXSBJcyBidW5kbGUganVzdCBhIHBv
cnQgb3ZlcnJpZGU/DQoNClRoZSBwb2ludCBvZiB0aGUgZGlmZmVyZW50IHBvcnRzIGlzIG5vdCBq
dXN0IHRvIG1ha2UgaW50ZXJtZWRpYXJpZXMgaGFwcHksIGJ1dCB0byBlbnN1cmUgdGhhdCB3ZSdy
ZSBzdWNjZXNzZnVsIHdoZW4gdGFsa2luZyB0byBhbiBlbmRwb2ludCB3aG8gZG9lc24ndCBzdXBw
b3J0IEJVTkRMRS4gVGhlcmUgYXJlIGEgbGl0YW55IG9mIHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVu
IGlkZW50aWZpZWQgd2hlbiB0aGUgc2FtZSBwb3J0cyBhcmUgdXNlZCBvbiB0aGUgb2ZmZXJlciBz
aWRlIGFuZCB0aGUgYW5zd2VyZXIgaXMgQlVORExFLXVuYXdhcmUuDQoNCk9uIFdlZCwgTWFyIDIw
LCAyMDEzIGF0IDk6NDMgUE0sIE1vIFphbmF0eSAobXphbmF0eSkgPG16YW5hdHlAY2lzY28uY29t
PG1haWx0bzptemFuYXR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgRGFsZSwNCg0KSW4geW91ciBk
cmFmdCAoYW5kIFJpY2hhcmQncyksIEkgdW5kZXJzdGFuZCB5b3VyIG1vdGl2YXRpb24gdG8gYW5z
d2VyIHdpdGggcG9ydCAwIChvciA5IG9yIElQIDApLCB0byBwbHVnIHRoZSBub3N0cmlscyBvZiBp
bnRlcm1lZGlhcmllcyB0aGF0IHNuaWZmIHBvcnRzIHNvIHRoZXkgZG9uJ3Qgc21lbGwgYW55dGhp
bmcgZmlzaHkuIEkgd29uJ3QgY29tbWVudCBvbiB3aGV0aGVyIHRoZXkgd2lsbCByZWFjdCBiZXR0
ZXIgdG8gbm9zdHJpbC1wbHVnZ2luZyB0aGFuIGZpc2h5IHNtZWxscywgYmVjYXVzZSBJIGRvbid0
IGtub3csIGJ1dCB0aGF0IGlzIG9ydGhvZ29uYWwgdG8gd2hhdCBJJ20gZGVzY3JpYmluZyBoZXJl
Lg0KDQpZb3VyIGJ1bmRsZSBhbHRlcm5hdGl2ZXMgKGFuZCBSaWNoYXJkJ3MpIGFsc28gd29yayBm
aW5lIHdpdGggYSBzaW1wbGUgYXR0cmlidXRlIHdpdGhvdXQgY29tcGxleCBncm91cGluZyBzZW1h
bnRpY3MuDQoNCk9mZmVyIHRvIG11eCBhdWRpbyBhbmQgdmlkZW8gb24gdGhlIHNhbWUgcG9ydDoN
Cm09YXVkaW8gMTAwMDAgUlRQL0FWUCAwDQptPXZpZGVvIDEwMDAyIFJUUC9BVlAgMzENCmE9cG9y
dCAxMDAwMA0KaT1JIHJlYWxseSB3YW50IDEwMDAwLCBidXQgbGllZCBvbiB0aGUgbS1saW5lIGZv
ciBmZWFyIG9mIGNvbmZ1c2luZyB5b3UuIENvbmZ1c2VkIHlldD8NCg0KQW5zd2VyIHN1cHBvcnRz
IHRoZSBwb3J0IG92ZXJyaWRlIGF0dHJpYnV0ZSBhbmQgYWdyZWVzIHRvIG11eCBhdWRpbyBhbmQg
dmlkZW86DQptPWF1ZGlvIDQwMDAwIFJUUC9BVlAgMA0KbT12aWRlbyAwIFJUUC9BVlAgMzEgICAg
ICAgICA8LS0gRGFsZSdzIHZhcmlhbnQgdG8gYW5zd2VyIHdpdGggcG9ydCAwDQphPXBvcnQgNDAw
MDANCi4uLnNvIGF1ZGlvIGFuZCB2aWRlbyBwb3J0cyBhcmUgMTAwMDA8LT40MDAwMC4NCkFuc3dl
ciBkb2Vzbid0IHN1cHBvcnQgdGhlIHBvcnQgb3ZlcnJpZGUgYXR0cmlidXRlLCBvciBkb2Vzbid0
IHdhbnQgdG8gbXV4Og0KbT1hdWRpbyA0MDAwMCBSVFAvQVZQIDANCm09dmlkZW8gNDAwMDIgUlRQ
L0FWUCAzMQ0KLi4uc28gYXVkaW8gcG9ydHMgYXJlIDEwMDAwPC0+NDAwMDAgYW5kIHZpZGVvIHBv
cnRzIGFyZSAxMDAwMjwtPjQwMDAyLg0KQ2hlZXJzLA0KTW8NCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogRGFsZSBSLiBXb3JsZXkgW21haWx0bzp3b3JsZXlAYXJpYWRuZS5j
b208bWFpbHRvOndvcmxleUBhcmlhZG5lLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxOSwg
MjAxMyAzOjM3IFBNDQpUbzogTW8gWmFuYXR5IChtemFuYXR5KQ0KQ2M6IGVtY2hvQGppdHNpLm9y
ZzxtYWlsdG86ZW1jaG9Aaml0c2kub3JnPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA
aWV0Zi5vcmc+OyBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1Ympl
Y3Q6IFJlOiBbcnRjd2ViXSBbTU1VU0lDXSBJcyBidW5kbGUganVzdCBhIHBvcnQgb3ZlcnJpZGU/
DQoNCj4gRnJvbTogIk1vIFphbmF0eSAobXphbmF0eSkiIDxtemFuYXR5QGNpc2NvLmNvbTxtYWls
dG86bXphbmF0eUBjaXNjby5jb20+Pg0KPg0KPiBUaG9zZSBkcmFmdHMgdXNlIHRoZSBTRFAgZ3Jv
dXBpbmcgZnJhbWV3b3JrDQo+IChhPWdyb3VwOkJVTkRMRS9UT0dFVEhFUiksIHdoaWNoIEkgdGhp
bmsgaXMgdW5uZWNlc3NhcnkgY29tcGxleGl0eQ0KPiBhbmQgYW1iaWd1aXR5IGZvciBzb21ldGhp
bmcgd2hpY2ggY2FuIGJlIHNvbHZlZCBpbiBhIG11Y2ggc2ltcGxlcg0KPiBhbmQgY2xlYXJlciB3
YXkgd2l0aCBhIHNpbmdsZSBhdHRyaWJ1dGU6IGE9cG9ydCA8cG9ydD4uIChPciwgaWYgd2UNCj4g
d2FudCB0byB3YXJuIGh1bWFucyBhYm91dCBSVFAgbXV4aW5nLCB0aGVuIG5hbWUgaXQgYT1ydHAt
bXV4Ojxwb3J0PiwNCj4gYnV0IG1hY2hpbmVzIHdvbid0IGNhcmUgYWJvdXQgdGhlIG5hbWUsIGFu
ZCB0aGVpciBSVFANCj4gaW1wbGVtZW50YXRpb25zIGFscmVhZHkga25vdyBob3cgdG8gZGVhbCB3
aXRoIG11eGluZyBpZiB0aGV5IHVzZQ0KPiB0aGlzIGF0dHJpYnV0ZSwgc28gc3Ryb25nZXIgd2Fy
bmluZ3MgYXJlIHVubmVjZXNzYXJ5LikNCj4NCj4gUmVnYXJkaW5nIHRoZSBjb25jZXJuIGFib3V0
IG5vbi11c2Ugb2YgdGhlIGRpc2NhcmRlZCBSVFAgcG9ydHMNCj4gY29uZnVzaW5nIFNCQ3MsIHNl
ZSB0aGlzIHBhcnQgb2YgbXkgb3JpZ2luYWwgbWVzc2FnZSBbd2l0aA0KPiBjbGFyaWZpY2F0aW9u
c10sIHdoaWNoIGlzIHdoYXQgdGhlIGN1cnJlbnQgYnVuZGxlIGRyYWZ0IGFsc28NCj4gc3VnZ2Vz
dHM6DQo+DQo+ID4gRWl0aGVyIGVuZCBjYW4gcmUtb2ZmZXIgd2l0aG91dCBsaWVzIGFib3V0IHBv
cnRzIG9uIHRoZSBtLWxpbmUgYWZ0ZXINCj4gPiBjb25maXJtaW5nIHRoZSBwZWVyIGlzIG5vdCBj
b25mdXNlZCBieSBtdXhpbmcsIGlmIHRoZXkgd2FudCB0byBhdm9pZA0KPiA+IGNvbmZ1c2luZyBp
bnRlcm1lZGlhcmllcyBbdGhhdCBtYXkgbW9uaXRvciB0aGUgdW51c2VkIHBvcnRzXS4NCg0KSXQn
cyBtZXNzaWVyIHRoYW4gdGhhdCwgdW5mb3J0dW5hdGVseS4NCg0KT25lIHJlcXVpcmVtZW50IGlz
IHRoYXQgYWZ0ZXIgbmVnb3RpYXRpb24gaXMgY29tcGxldGVkLCB0aGUgbmVnb3RpYXRlZA0KdHJh
bnNwb3J0IGFzc29jaWF0aW9ucyAoYXMgc2VlbiBieSBhIGxlZ2FjeSBpbnRlcm1lZGlhcnkpIG11
c3QgbWF0Y2gNCnRoZSBhY3R1YWwgbWVkaWEgZmxvd3MuDQoNCkFub3RoZXIgcmVxdWlyZW1lbnQg
aXMgdGhhdCB0d28gbWVkaWEgZGVzY3JpcHRpb25zIHNob3VsZG4ndCB1c2UgdGhlDQpzYW1lIHBv
cnQgKGJlY2F1c2UgYSBsb3Qgb2YgbGVnYWN5IFNCQ3MgY2FuJ3QgaGFuZGxlIHRoYXQpLiAgVGhp
cw0KYXBwbGllcyB0byBvZmZlci9hbnN3ZXIgdXBkYXRlcyBhcyB3ZWxsIGFzIG9yaWdpbmFsIG9m
ZmVycy9hbnN3ZXJzLg0KDQpTbyB3aGF0IHdlIHdhbnQgaXMgYSB3YXkgZm9yIGEgbWVkaWEgZGVz
Y3JpcHRpb24gdG8gc2F5LCAiSSdtDQpyZXBvcnRpbmcgcG9ydCB6ZXJvIHNvIFNCQ3MgdGhpbmsg
dGhpcyBNRCBpcyByZWplY3RlZCwgYnV0IEknbQ0KYWN0dWFsbHkgdXNpbmcgcG9ydCAxMjM0ICh3
aGljaCBpcyBvZmZpY2lhbGx5IHJlcG9ydGVkIGluIGFub3RoZXINCk1EKS4iDQoNClRoZXJlIGFy
ZSBhbHNvIHNpdHVhdGlvbnMgd2hlcmUgdGhlIHdlIHdhbnQgdG8gc2lnbmFsIHBlcmZlcmVuY2Vz
IGFzDQp0byB3aGljaCBtZWRpYSBkZXNjcmlwdGlvbnMgc2hhcmUgcG9ydHMgd2l0aCB3aGljaCBv
dGhlciBtZWRpYQ0KZGVzY3JpcHRpb25zLg0KDQpEYWxlDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGll
dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo=

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F695235xmbrcdx14ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93
dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU
ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs
bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgSnVz
dGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHVuZGVyc3RhbmQg
dGhlIHBvdGVudGlhbCBwcm9ibGVtcyB3aXRoIGxlZ2FjeSBlbmRwb2ludHMgYXMgZGVzY3JpYmVk
IGluIEEuMiBvZiBDaHJpc3RlcuKAmXMgZHJhZnQsIG5vdCBqdXN0IGludGVybWVkaWFyaWVzIChB
LjQpIHdoaWNoIEkgdGhvdWdodCBEYWxlIHdhcyBzcGVjaWZpY2FsbHkgY29tbWVudGluZw0KIGFi
b3V0LiBUaGUgY29uc3RyYWludHMgb2YgbGVnYWN5IHBlZXJzIGFuZCBpbnRlcm1lZGlhcmllcyBp
cyBvYnZpb3VzbHkgaW1wb3J0YW50IHRvIHRoZSBvdmVyYWxsIHNvbHV0aW9uLCBidXQgb3J0aG9n
b25hbCB0byBob3cgd2Ugc2lnbmFsIHRoZSBkZXNpcmVkIHBvcnQgaW4gYSBuZXcgd2F5IChhcyBh
IHNpbmdsZSBhdHRyaWJ1dGUgb3IgdXNpbmcgdGhlIGdyb3VwaW5nIGZyYW1ld29yaykuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJUVywgaGFzIGFueW9uZSBhY3R1YWxs
eSBvYnNlcnZlZCBmYWlsdXJlcz8gSSBhc2sgYmVjYXVzZSBJIGNvdWxkIG5vdCBnZXQgcHJvZHVj
dHMgdG8gZmFpbCAod2hlbiBzaW1wbHkgb2ZmZXJpbmcgdGhlIHNhbWUgcG9ydHMpIGluIG15IChs
aW1pdGVkKSBpbnRlcm9wIGxhYi4gU0lQaXQgMzAgd2FzDQogb24gbXkgY2FtcHVzIGxhc3QgbW9u
dGgsIEkgd2lzaCBJIHdvdWxkIGhhdmUgdGVzdGVkIGl0IHRoZXJlIGZvciBtb3JlIGRhdGEgcG9p
bnRzLiBJIGNhbiB0cnkgYXQgU3VwZXJPcCBuZXh0IG1vbnRoLiBKdXN0IGNoZWNraW5nIGlmIHNv
bWVvbmUgaGl0IGEgcmVhbCBwcm9ibGVtIGJlZm9yZSBzdGFydGluZyB0aGlzIGJ1bmRsZSBwYXJ0
eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+TW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDIxLCAyMDEzIDE6MTEgQU08YnI+DQo8Yj5Ubzo8
L2I+IE1vIFphbmF0eSAobXphbmF0eSk8YnI+DQo8Yj5DYzo8L2I+IERhbGUgUi4gV29ybGV5OyBy
dGN3ZWJAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W3J0Y3dlYl0gW01NVVNJQ10gSXMgYnVuZGxlIGp1c3QgYSBwb3J0IG92ZXJyaWRlPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb2ludCBvZiB0aGUgZGlmZmVyZW50
IHBvcnRzIGlzIG5vdCBqdXN0IHRvIG1ha2UgaW50ZXJtZWRpYXJpZXMgaGFwcHksIGJ1dCB0byBl
bnN1cmUgdGhhdCB3ZSdyZSBzdWNjZXNzZnVsIHdoZW4gdGFsa2luZyB0byBhbiBlbmRwb2ludCB3
aG8gZG9lc24ndCBzdXBwb3J0IEJVTkRMRS4gVGhlcmUgYXJlIGEgbGl0YW55IG9mIHByb2JsZW1z
IHRoYXQgaGF2ZSBiZWVuIGlkZW50aWZpZWQgd2hlbiB0aGUgc2FtZQ0KIHBvcnRzIGFyZSB1c2Vk
IG9uIHRoZSBvZmZlcmVyIHNpZGUgYW5kIHRoZSBhbnN3ZXJlciBpcyBCVU5ETEUtdW5hd2FyZS48
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyMCwgMjAx
MyBhdCA5OjQzIFBNLCBNbyBaYW5hdHkgKG16YW5hdHkpICZsdDs8YSBocmVmPSJtYWlsdG86bXph
bmF0eUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5temFuYXR5QGNpc2NvLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRGFsZSw8YnI+
DQo8YnI+DQpJbiB5b3VyIGRyYWZ0IChhbmQgUmljaGFyZCdzKSwgSSB1bmRlcnN0YW5kIHlvdXIg
bW90aXZhdGlvbiB0byBhbnN3ZXIgd2l0aCBwb3J0IDAgKG9yIDkgb3IgSVAgMCksIHRvIHBsdWcg
dGhlIG5vc3RyaWxzIG9mIGludGVybWVkaWFyaWVzIHRoYXQgc25pZmYgcG9ydHMgc28gdGhleSBk
b24ndCBzbWVsbCBhbnl0aGluZyBmaXNoeS4gSSB3b24ndCBjb21tZW50IG9uIHdoZXRoZXIgdGhl
eSB3aWxsIHJlYWN0IGJldHRlciB0byBub3N0cmlsLXBsdWdnaW5nDQogdGhhbiBmaXNoeSBzbWVs
bHMsIGJlY2F1c2UgSSBkb24ndCBrbm93LCBidXQgdGhhdCBpcyBvcnRob2dvbmFsIHRvIHdoYXQg
SSdtIGRlc2NyaWJpbmcgaGVyZS48YnI+DQo8YnI+DQpZb3VyIGJ1bmRsZSBhbHRlcm5hdGl2ZXMg
KGFuZCBSaWNoYXJkJ3MpIGFsc28gd29yayBmaW5lIHdpdGggYSBzaW1wbGUgYXR0cmlidXRlIHdp
dGhvdXQgY29tcGxleCBncm91cGluZyBzZW1hbnRpY3MuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT2ZmZXIgdG8gbXV4IGF1ZGlvIGFuZCB2aWRlbyBv
biB0aGUgc2FtZSBwb3J0Ojxicj4NCm09YXVkaW8gMTAwMDAgUlRQL0FWUCAwPGJyPg0KbT12aWRl
byAxMDAwMiBSVFAvQVZQIDMxPGJyPg0KYT1wb3J0IDEwMDAwPGJyPg0KaT1JIHJlYWxseSB3YW50
IDEwMDAwLCBidXQgbGllZCBvbiB0aGUgbS1saW5lIGZvciBmZWFyIG9mIGNvbmZ1c2luZyB5b3Uu
IENvbmZ1c2VkIHlldD88YnI+DQo8YnI+DQpBbnN3ZXIgc3VwcG9ydHMgdGhlIHBvcnQgb3ZlcnJp
ZGUgYXR0cmlidXRlIGFuZCBhZ3JlZXMgdG8gbXV4IGF1ZGlvIGFuZCB2aWRlbzo8YnI+DQptPWF1
ZGlvIDQwMDAwIFJUUC9BVlAgMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5tPXZpZGVvIDAgUlRQL0FWUCAzMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jmx0Oy0tIERhbGUncyB2YXJpYW50IHRvIGFuc3dlciB3aXRoIHBvcnQgMDxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+YT1wb3J0IDQwMDAwPGJyPg0KLi4uc28gYXVkaW8gYW5kIHZpZGVvIHBvcnRzIGFyZSAxMDAw
MCZsdDstJmd0OzQwMDAwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BbnN3ZXIgZG9lc24ndCBzdXBwb3J0IHRoZSBwb3J0IG92ZXJyaWRlIGF0dHJpYnV0ZSwg
b3IgZG9lc24ndCB3YW50IHRvIG11eDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPm09YXVkaW8gNDAwMDAgUlRQ
L0FWUCAwPGJyPg0KbT12aWRlbyA0MDAwMiBSVFAvQVZQIDMxPGJyPg0KLi4uc28gYXVkaW8gcG9y
dHMgYXJlIDEwMDAwJmx0Oy0mZ3Q7NDAwMDAgYW5kIHZpZGVvIHBvcnRzIGFyZSAxMDAwMiZsdDst
Jmd0OzQwMDAyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D
aGVlcnMsPGJyPg0KTW88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IERhbGUg
Ui4gV29ybGV5IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndvcmxleUBhcmlhZG5lLmNvbSI+d29y
bGV5QGFyaWFkbmUuY29tPC9hPl08YnI+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxOSwgMjAxMyAz
OjM3IFBNPGJyPg0KVG86IE1vIFphbmF0eSAobXphbmF0eSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYzogPGEgaHJlZj0ibWFpbHRv
OmVtY2hvQGppdHNpLm9yZyI+ZW1jaG9Aaml0c2kub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0
Y3dlYkBpZXRmLm9yZyI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bW11
c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtydGN3
ZWJdIFtNTVVTSUNdIElzIGJ1bmRsZSBqdXN0IGEgcG9ydCBvdmVycmlkZT88YnI+DQo8YnI+DQom
Z3Q7IEZyb206ICZxdW90O01vIFphbmF0eSAobXphbmF0eSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzptemFuYXR5QGNpc2NvLmNvbSI+bXphbmF0eUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCiZn
dDs8YnI+DQomZ3Q7IFRob3NlIGRyYWZ0cyB1c2UgdGhlIFNEUCBncm91cGluZyBmcmFtZXdvcms8
YnI+DQomZ3Q7IChhPWdyb3VwOkJVTkRMRS9UT0dFVEhFUiksIHdoaWNoIEkgdGhpbmsgaXMgdW5u
ZWNlc3NhcnkgY29tcGxleGl0eTxicj4NCiZndDsgYW5kIGFtYmlndWl0eSBmb3Igc29tZXRoaW5n
IHdoaWNoIGNhbiBiZSBzb2x2ZWQgaW4gYSBtdWNoIHNpbXBsZXI8YnI+DQomZ3Q7IGFuZCBjbGVh
cmVyIHdheSB3aXRoIGEgc2luZ2xlIGF0dHJpYnV0ZTogYT1wb3J0ICZsdDtwb3J0Jmd0Oy4gKE9y
LCBpZiB3ZTxicj4NCiZndDsgd2FudCB0byB3YXJuIGh1bWFucyBhYm91dCBSVFAgbXV4aW5nLCB0
aGVuIG5hbWUgaXQgYT1ydHAtbXV4OiZsdDtwb3J0Jmd0Oyw8YnI+DQomZ3Q7IGJ1dCBtYWNoaW5l
cyB3b24ndCBjYXJlIGFib3V0IHRoZSBuYW1lLCBhbmQgdGhlaXIgUlRQPGJyPg0KJmd0OyBpbXBs
ZW1lbnRhdGlvbnMgYWxyZWFkeSBrbm93IGhvdyB0byBkZWFsIHdpdGggbXV4aW5nIGlmIHRoZXkg
dXNlPGJyPg0KJmd0OyB0aGlzIGF0dHJpYnV0ZSwgc28gc3Ryb25nZXIgd2FybmluZ3MgYXJlIHVu
bmVjZXNzYXJ5Lik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRpbmcgdGhlIGNvbmNlcm4gYWJv
dXQgbm9uLXVzZSBvZiB0aGUgZGlzY2FyZGVkIFJUUCBwb3J0czxicj4NCiZndDsgY29uZnVzaW5n
IFNCQ3MsIHNlZSB0aGlzIHBhcnQgb2YgbXkgb3JpZ2luYWwgbWVzc2FnZSBbd2l0aDxicj4NCiZn
dDsgY2xhcmlmaWNhdGlvbnNdLCB3aGljaCBpcyB3aGF0IHRoZSBjdXJyZW50IGJ1bmRsZSBkcmFm
dCBhbHNvPGJyPg0KJmd0OyBzdWdnZXN0czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEVpdGhl
ciBlbmQgY2FuIHJlLW9mZmVyIHdpdGhvdXQgbGllcyBhYm91dCBwb3J0cyBvbiB0aGUgbS1saW5l
IGFmdGVyPGJyPg0KJmd0OyAmZ3Q7IGNvbmZpcm1pbmcgdGhlIHBlZXIgaXMgbm90IGNvbmZ1c2Vk
IGJ5IG11eGluZywgaWYgdGhleSB3YW50IHRvIGF2b2lkPGJyPg0KJmd0OyAmZ3Q7IGNvbmZ1c2lu
ZyBpbnRlcm1lZGlhcmllcyBbdGhhdCBtYXkgbW9uaXRvciB0aGUgdW51c2VkIHBvcnRzXS48YnI+
DQo8YnI+DQpJdCdzIG1lc3NpZXIgdGhhbiB0aGF0LCB1bmZvcnR1bmF0ZWx5Ljxicj4NCjxicj4N
Ck9uZSByZXF1aXJlbWVudCBpcyB0aGF0IGFmdGVyIG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlZCwg
dGhlIG5lZ290aWF0ZWQ8YnI+DQp0cmFuc3BvcnQgYXNzb2NpYXRpb25zIChhcyBzZWVuIGJ5IGEg
bGVnYWN5IGludGVybWVkaWFyeSkgbXVzdCBtYXRjaDxicj4NCnRoZSBhY3R1YWwgbWVkaWEgZmxv
d3MuPGJyPg0KPGJyPg0KQW5vdGhlciByZXF1aXJlbWVudCBpcyB0aGF0IHR3byBtZWRpYSBkZXNj
cmlwdGlvbnMgc2hvdWxkbid0IHVzZSB0aGU8YnI+DQpzYW1lIHBvcnQgKGJlY2F1c2UgYSBsb3Qg
b2YgbGVnYWN5IFNCQ3MgY2FuJ3QgaGFuZGxlIHRoYXQpLiAmbmJzcDtUaGlzPGJyPg0KYXBwbGll
cyB0byBvZmZlci9hbnN3ZXIgdXBkYXRlcyBhcyB3ZWxsIGFzIG9yaWdpbmFsIG9mZmVycy9hbnN3
ZXJzLjxicj4NCjxicj4NClNvIHdoYXQgd2Ugd2FudCBpcyBhIHdheSBmb3IgYSBtZWRpYSBkZXNj
cmlwdGlvbiB0byBzYXksICZxdW90O0knbTxicj4NCnJlcG9ydGluZyBwb3J0IHplcm8gc28gU0JD
cyB0aGluayB0aGlzIE1EIGlzIHJlamVjdGVkLCBidXQgSSdtPGJyPg0KYWN0dWFsbHkgdXNpbmcg
cG9ydCAxMjM0ICh3aGljaCBpcyBvZmZpY2lhbGx5IHJlcG9ydGVkIGluIGFub3RoZXI8YnI+DQpN
RCkuJnF1b3Q7PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gc2l0dWF0aW9ucyB3aGVyZSB0aGUg
d2Ugd2FudCB0byBzaWduYWwgcGVyZmVyZW5jZXMgYXM8YnI+DQp0byB3aGljaCBtZWRpYSBkZXNj
cmlwdGlvbnMgc2hhcmUgcG9ydHMgd2l0aCB3aGljaCBvdGhlciBtZWRpYTxicj4NCmRlc2NyaXB0
aW9ucy48YnI+DQo8YnI+DQpEYWxlPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F695235xmbrcdx14ciscoc_--

From magnus.westerlund@ericsson.com  Thu Mar 21 03:15:20 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524FD21F8F1C for ; Thu, 21 Mar 2013 03:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.105
X-Spam-Level: 
X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdo6Phlzp8uI for ; Thu, 21 Mar 2013 03:15:19 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EAA7F21F8EDE for ; Thu, 21 Mar 2013 03:15:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-32-514addb5a0fb
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6D.36.19728.5BDDA415; Thu, 21 Mar 2013 11:15:17 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 21 Mar 2013 11:15:17 +0100
Message-ID: <514ADDB5.8040909@ericsson.com>
Date: Thu, 21 Mar 2013 11:15:17 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Paul Kyzivat 
References: <5149D1AA.4010805@ericsson.com> <5149E9E9.10900@alum.mit.edu>
In-Reply-To: <5149E9E9.10900@alum.mit.edu>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3RnfrXa9Agyn7zSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj7N477AU3xSuazrayNzC+Eupi5OSQEDCR 2Ly1nQXCFpO4cG89WxcjF4eQwElGiVmfX0I5yxklbjaBZDg4eAW0Jf53x4M0sAioSszfuoEN xGYTsJC4+aMRzBYVCJb4+eoM2FBeAUGJkzOfsIC0ighoSEzaqgYSZhYQlrhw/jgTiC0sYCtx 7s8mZpASIQFPiUMP7UHCnAJaEhf2n2GHOE1SYsuLdnaIVj2JKVdbGCFseYnmrbOZQWwhoMMa mjpYJzAKzUKyeBaSlllIWhYwMq9iZM9NzMxJLzfaxAgM04NbfqvuYLxzTuQQozQHi5I4b7jr hQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCu+rTNQSLw6f/6d3CeHuS0Kmc0X1ohIu7/6 cXBVSVTgpOKGC6nC35panhV5Hk7z2/l9Uknby0dHFiW841ngOleNc2Xtdf+KDa7L51meTmq+ a58ttuzwfnNf765lZ9yn+mlZb23axtkz2a456Uuq3O+XXf9zDLsOvdnx4GnEZA+NBatCPzWa iSmxFGckGmoxFxUnAgDIJvqxIQIAAA==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 10:15:20 -0000

On 2013-03-20 17:55, Paul Kyzivat wrote:
> Magnus,
> 
> Some comments on your review, from a CLUE perspective:
> 
> On 3/20/13 11:11 PM, Magnus Westerlund wrote:
> 
>> 6. Section 4.1:
>>
>> This section discuss the usage of the "data channels" within the SCTP
>> association. My personal position is that for the moment this appears to
>> be unnecessary. The most important part is the SCTP association
>> establishment. Then one can discuss the general application using the
>> SCTP association as whole. Examples of such are WebRTC data channel.
>>
>> If anyone want stream level information in SDP then I propose that this
>> is handled as a extension to this signaling, not an from the start
>> included functionality as we don't appear to have clear requirement for
>> that.
> 
> Who is "we"?

MMUSIC WG

> 
> In CLUE we expect to use this mechanism for a CLUE data channel.
> And we intend to do so in pure sip-sip cases as well as webrtc-sip and
> webrtc-webrtc cases.

Yes.
> 
> While webrtc-webrtc may have an independent mechanism to work out the
> channel usage, that is certainly not so for sip-sip sessions.
> 
> So I think "we" (CLUE) have a requirement to negotiate channel usage in
> SDP.

Do you? Or it is sufficient to say

m=application 12234 UDP/DTLS/SCTP CLUE

Indicating that this SCTP association is using CLUEs defined way, not
WebRTC. I want to separate the usage of individual SCTP streams and the
general usage of the SCTP association.

> 
>> 7. Section 4.2:
>>
>> What are the requirements behind being able to establish multiple SCTP
>> association over the same DTLS connection? I am very unclear why this
>> would be required, and if not really needed I would suggest keeping
>> things simple.
> 
> I agree there has been no compelling need advanced for multiple SCTP
> associations over the same DTLS connection. But the fact is that SCTP
> has its own notion of port, and that needs to be dealt with one way or
> another. At a minimum this document should specify what SCTP port is to
> be used when conforming to this specification.

Agreed, there need to be clarity on the port usage.

> 
>> 8. Section 4.3: I guess this can for the moment be removed as it appears
>> to be taken care in other places, such as the RTCWEB WG data channel
>> protocol proposal.
> 
> See above. That doesn't meet CLUE needs.

Disagree, I don't think CLUE need SCTP stream specific indication or
negoitation. It will be sufficient to indicate that this is CLUE using SCTP.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From harald@alvestrand.no  Thu Mar 21 05:09:43 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3433721F872E; Thu, 21 Mar 2013 05:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.842
X-Spam-Level: 
X-Spam-Status: No, score=-109.842 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 U7mYfeiRu08k; Thu, 21 Mar 2013 05:09:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EABD721F8700; Thu, 21 Mar 2013 05:09:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACA4039E1C9; Thu, 21 Mar 2013 13:09:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD3LBMOwSDdM; Thu, 21 Mar 2013 13:09:38 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4551539E125; Thu, 21 Mar 2013 13:09:38 +0100 (CET)
Message-ID: <514AF881.4040209@alvestrand.no>
Date: Thu, 21 Mar 2013 13:09:37 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" 
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <5148E48A.4060202@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F695203@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F695203@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 12:09:43 -0000

On 03/21/2013 06:59 AM, Mo Zanaty (mzanaty) wrote:
> Hi Harald,
>
> You're right, both are essentially groupings, and all of our wheels have ugly angles. To me, the ugly angles in bundle are unnecessary indirection by grouping with artificial bindings (mid), and that it pretends to be more than it is. To me, it is just a port override, but with unnecessary indirection. Why not just say the port you want to use directly?
>
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
>
> vs.
>
> a=group:BUNDLE foo bar
> m=audio 10000 RTP/AVP 0
> a=mid:foo
> m=video 10002 RTP/AVP 31
> a=mid:bar
>
> Why is the direct approach more complex? Why is ICE any different in either approach?
You don't know the port you'll be using ahead of time with ICE; you have 
to put ICE into all the M-lines in order to be able to negotiate ICE 
when you don't get the bundling.

So in addition to specifying the port on the m= line, you have to uglify 
your solution by stating rules that say "if you accept this alternate 
port, you also have to accept these special rules for ICE", and all the 
other stuff that Christer uncovered and is documented in his draft.

And nothing that looks as the SDP without knowing the special semantics 
of bundle can know that the fact that a=port in those 2 M-lines implies 
special treatment of ICE.

It's a grouping framework. I don't want to create new grouping 
frameworks; the one we have is bad enough.

I think your angles will produce a bumpier ride than mine :-)

>
> Cheers,
> Mo
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Tuesday, March 19, 2013 6:20 PM
> To: Mo Zanaty (mzanaty)
> Cc: Emil Ivov; rtcweb@ietf.org; mmusic@ietf.org
> Subject: Re: [MMUSIC] Is bundle just a port override?
>
> On 03/19/2013 07:43 PM, Mo Zanaty (mzanaty) wrote:
>> Hi Emil,
>>
>> Those drafts use the SDP grouping framework (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity and ambiguity for something which can be solved in a much simpler and clearer way with a single attribute: a=port . (Or, if we want to warn humans about RTP muxing, then name it a=rtp-mux:, but machines won't care about the name, and their RTP implementations already know how to deal with muxing if they use this attribute, so stronger warnings are unnecessary.)
> To me, what you're describing is a grouping (the ports with the same
> a=rtp-mux:port attribute form a single RTP session), so it seems to me
> that using the grouping framework and using matching a=rtp-mux:port
> attribute have exactly the same level of complexity - but in the case of
> a=rtp-mux:port, you lose the ability to use ICE attributes to negotiate
> the actual ports, addresses and network interfaces actually used - so
> the a=rtp-mux:port mechanism will actually turn out to be *more* complex
> than the grouping framework once you've added all the other features you
> need to take advantage of ICE and so on.
>
> So - after I've thought about it for a while - I think calling it a
> "port override" is not just misleading, the implementation you're
> suggesting will be more complex than using the grouping framework.
>
> Why invent square wheels when the pentagonal ones are doing just fine?
>


From harald@alvestrand.no  Thu Mar 21 06:23:05 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9B21F8FA3 for ; Thu, 21 Mar 2013 06:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.993
X-Spam-Level: 
X-Spam-Status: No, score=-110.993 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_PART_INA=0.786, 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 TWc49EzxnHWc for ; Thu, 21 Mar 2013 06:23:04 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0321F8F4A for ; Thu, 21 Mar 2013 06:23:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5615A39E1C9; Thu, 21 Mar 2013 14:23:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9-uVV2e+Kgi; Thu, 21 Mar 2013 14:23:01 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B7A6839E125; Thu, 21 Mar 2013 14:23:00 +0100 (CET)
Message-ID: <514B09B3.9030903@alvestrand.no>
Date: Thu, 21 Mar 2013 14:22:59 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Magnus Westerlund 
References: <5149D1AA.4010805@ericsson.com>
In-Reply-To: <5149D1AA.4010805@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-mmusic-sctp-sdp@tools.ietf.org, "mmusic \(E-mail\)" 
Subject: [MMUSIC] Proto identifier: To UDP or not to UDP (Re: Review of draft-ietf-mmusic-sctp-sdp-03)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 13:23:05 -0000

One high level comment:

This series of comments points out that the purpose of the thing called 
"proto identifier" in SDP is not really well documented.

As far as I can tell, the requirement is that it uniquely identifies the 
parser one needs to use for the stuff under this m= line, and that is 
the sum total of the requirements on it - as we painfully learned with 
RTP/AVP, RTP/AVPF, SRTP/AVP and SRTP/AVPF, making detailed information 
about the parameters available via the "proto identifier" is not really 
a Good Idea.

I suggest we go for DTLS/SCTP, as specified in the document currently, 
and document that the lower layer used has to be identified from the 
elements inside the m= line block; if there is ICE, ICE can negotiate 
it; if there is only a port number, it's UDP; if there are more 
extensions to specify that the lower layer is LTE over pterodactyls, the 
identifier doesn't change.

Same handling as for RTP/AVP(F), and no double specifications.

On 03/20/2013 04:11 PM, Magnus Westerlund wrote:
> Hi,
>
> I have reviewed the SDP description of SCTP and have some comments and
> suggestions.
>
> 1. My first comments is a very general one and concerns the relationship
> between the proposed SCTP related proto identifiers and ICE for the
> DTLS/SCTP encapsulation.
>
> When ICE was defined it was natural to include ICE by reftorfitting it
> to existing proto identifiers. However, given that this specification
> intorduce a number of new identifiers I do woner if we should be more
> explicit about the ICE usage in the proto field. I think have both pro
> and cons for this.
>
> So my considerations is basically to include specification of
> ICE/DTLS/SCTP, where the lower layer transport is defined by what ICE
> agrees on. This makes a lot of sense given that ICE can in fact arrive
> on the usage of TCP/framing/DTLS/SCTP, TCP/TURN/DTLS/SCTP in addition to
> more expected choices as UDP/DTLS/SCTP. This makes it clears that you do
> require ICE to negotiate this transport flow. At the same time it is a
> significant downside if ones negotiation needs are to chose between
> using ICE or a specific lower layer transport.
>
> These comments doesn't apply when one runs SCTP on top of IP.
>
> 2. Section 1:
> RFC4145 [RFC4145] specifies a general mechanism for
>     describing and establishing TCP (Transmission Control Protocol)
>     streams.
>
> I do dislike that usage of the RFC number as the explanation of what the
> referenced document is. The previous sentence is how I prefer it to be
> done:
>     SDP (Session Description Protocol) [RFC4566] provides a general-
>     purpose format for describing multimedia sessions in announcements or
>     invitations.
>
> Use the document title or an abbreviated explanation for what the
> referenced document specifies and one gets much better flow in the
> reading as one don't have stop look up the reference to find out what is
> referred to.
>
> 3. Section 1:
> I think having first a paragraph for SCTP and then having "Additionaly
> .." with the other two protos are bit strange. Why not simpley say. This
> document defines three proto identifiers: list of them with explnation.
>
> 4. Section 1:
>     DTLS/SCTP :  to allow the usage of SCTP on top of the Datagram
>        Transport Layer Security (DTLS) protocol, as defined in
>        [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP.  SCTP over DTLS is
>        used by the RTCWeb protocol suite for transporting non- media data
>        between browsers.
>
> This definitions says nothing of the lower transport layer for DTLS/SCTP
> even if UDP is referred to in a later section. I think this needs to be
> clarified and discussed in the context of which lower layers do we
> expect to be supported? From my perspective I think two makes sense.
> ICE/DTLS/SCTP that allows ICE to negoiate what ever and then
> UDP/DTSL/SCTP that only uses UDP as lower layer. Lets other add other
> variants in the future if needed.
>
> 5. Section 3:
>     The 'DTLS/SCTP' protocol identifier indicates that the media
>     described will use SCTP on top of the Datagram Transport Layer
>     Security (DTLS) protocol as specified in
>     [I-D.tuexen-tsvwg-sctp-dtls-encaps].
>
> I would like to point out that the referenced document does not at all
> indicate what lower layer is being used under DTLS.
>
> 6. Section 4.1:
>
> This section discuss the usage of the "data channels" within the SCTP
> association. My personal position is that for the moment this appears to
> be unnecessary. The most important part is the SCTP association
> establishment. Then one can discuss the general application using the
> SCTP association as whole. Examples of such are WebRTC data channel.
>
> If anyone want stream level information in SDP then I propose that this
> is handled as a extension to this signaling, not an from the start
> included functionality as we don't appear to have clear requirement for
> that.
>
> 7. Section 4.2:
>
> What are the requirements behind being able to establish multiple SCTP
> association over the same DTLS connection? I am very unclear why this
> would be required, and if not really needed I would suggest keeping
> things simple.
>
> 8. Section 4.3: I guess this can for the moment be removed as it appears
> to be taken care in other places, such as the RTCWEB WG data channel
> protocol proposal.
>
> 9. If you are removing the multiple association and the "data channel"
> parameters then most of the issues in section 5 vanish. If not I have
> additional feedback on this section.
>
> 10. Section 8.
>
>     Current NATs do not typically support SCTP.  As an alternative to
>     design SCTP specific NATs, Encapsulating SCTP into UDP
>     [I-D.tuexen-sctp-udp-encaps] makes it possible to use SCTP in
>     networks with legacy NAT and firewalls not supporting SCTP.
>
> First of all, there is a WG version for this document:
> draft-ietf-tsvwg-sctp-udp-encaps-14. Which is in IESG evaluation. Thus I
> wonder why signalling for this is not included when all the other
> options are included, even less mature ones then this?
>
> To me it looks like this document need to have some high level decisions
> on what to include and not and then try to finish it up within the
> agreed constraints. From my perspective I think it should focus on a
> single SCTP association per m= line and the actual SCTP association.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From fandreas@cisco.com  Thu Mar 21 06:40:55 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12E21F8EDE for ; Thu, 21 Mar 2013 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.203
X-Spam-Level: 
X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[AWL=0.796,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 oYWiBqAnekXj for ; Thu, 21 Mar 2013 06:40:54 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D48AD21F8837 for ; Thu, 21 Mar 2013 06:40:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4176; q=dns/txt; s=iport; t=1363873255; x=1365082855; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YzKlJZUCHa3yeItJSlOs1G+ZuiDwXolfdh+G+a8lvuA=; b=eLYov3QX9fBR57lMKrDoyS3qn5egLVnDJAcW+MWNZ7gD/jiM64mVsWPM QNiXjR0H3nCQ7hvJ5ZcYfkK+Sgl4oCqS1LoAN4qH1uXObDgO2JSn2pmFO Xtt56PamoZsTVGOi7TEPNSj10/9zwfScuV6KugOFZLi/1i68GHSsHmvpN w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOMLS1GrRDoH/2dsb2JhbABDxTmBWxZ0giQBAQEEAQEBNTYKAQwECxEEAQEBCRYEBAcJAwIBAgEVHwkIBgEMAQUCAQEFiAoNwn+NYYElCwcGgzoDlmSRAoFUgVIggTc
X-IronPort-AV: E=Sophos;i="4.84,886,1355097600"; d="scan'208";a="76233938"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 21 Mar 2013 13:40:54 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.247.102]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2LDepeV031013; Thu, 21 Mar 2013 13:40:52 GMT
Message-ID: <514B0DE4.3060501@cisco.com>
Date: Thu, 21 Mar 2013 09:40:52 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jonathan Lennox , "mohamed.boucadair@orange.com" , Hadriel Kaplan , Atle Monrad , md3135@att.com, Stach Thomas , Andrew Allen 
References: <5148049B.6090205@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 13:40:55 -0000

Can we get some more comments from people on this please. In particular, 
I would like to hear if people are against "ccap" being able to convey 
an IP-address or not (if not, we can then debate the details of the 
restrictions around that separately) ?

Thanks

-- Flemming


On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
> I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation.
>
> That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read:
>
> 
>      The 'ccap' attribute MUST NOT be used to select
>      between different IP connection addresses (e.g. between
>      "IP4" and "IP6" address families or different IP addresses
>       within the same IP address family).
> 
>
> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:
>
> 
>     The 'ccap' capability attribute is intended for offering
>     alternative connection addresses where the 
>     is "IN" or "PSTN", i.e. selecting between an IP based
>     bearer or a circuit-switched bearer.
> 
>
> Simo
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
> Sent: 19. maaliskuuta 2013 8:24
> To: mmusic
> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Greetings
>
> As you may have seen, there has recently been some list discussion on the "connection data capability" defined in
> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>
> To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording:
> 
> The 'ccap' capability attribute is intended to
>      be used only when there is no other mechanism available for
>      negotiating alternative connection address information, such as when
>      the  is different among the alternative addresses (e.g.
>      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>      situations where an existing mechanism (such as Interactive
>      Connectivity Establishment (ICE) [RFC5245]) can be used to select
>      between different connection addresses (e.g.  "IP4" and "IP6" or
>      different IP addresses within the same IP address family).
> 
>
> The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ?
>
> If you have an opinion, please let us know.
>
> A couple of points to keep in mind:
> - The current document has been WGLC'ed without comment ~6 months ago.
> - 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature)
> - The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value)
> - There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch).
> - RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support
>
>
> Thanks
>
> -- Flemming
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>


From thomas.stach@siemens-enterprise.com  Thu Mar 21 09:28:45 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081DA21F8D27 for ; Thu, 21 Mar 2013 09:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level: 
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.315,  BAYES_00=-2.599, J_CHICKENPOX_42=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 yRhxKOh-3Kg6 for ; Thu, 21 Mar 2013 09:28:44 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65521F8168 for ; Thu, 21 Mar 2013 09:28:41 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1BE8E1EB8557; Thu, 21 Mar 2013 17:28:40 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 21 Mar 2013 17:28:39 +0100
From: "Stach, Thomas" 
To: Flemming Andreasen , Jonathan Lennox , "mohamed.boucadair@orange.com" , Hadriel Kaplan , "Atle Monrad" , "md3135@att.com" ,  "Stach Thomas" , Andrew Allen 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJjm5DuMwk0HhDEu05rftrPqJspiwJ5+g
Date: Thu, 21 Mar 2013 16:28:39 +0000
Message-ID: 
References: <5148049B.6090205@cisco.com>  <514B0DE4.3060501@cisco.com>
In-Reply-To: <514B0DE4.3060501@cisco.com>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 16:28:45 -0000

I don't object against having an IP adress in the ccap attribute and a PSTN=
 number in the c-line,=20
if that indicates a preference for the PSTN number.
But I don't like to have an IPv4 and/or IPv6 adress in both ccap and c-line
as this would introduce a second method for IPv4/v6 negotiation in addition=
 to ICE.

My objection on this is based on what I remember from the IETF-68 discussio=
n=20
on usage of ICE vs. ANAT vs. SDP Capability-Negotiation for IPv4/IPv6 negot=
iation.
Cap-Neg did not address negotiations of IP address families at that time,=20
but could have been extended accordingly.

Although the consensus at that meeting was very rough, ICE was finally sele=
cted as the=20
method of choice since it also allows to test which address family would wo=
rk based on connectivity checks.=20
This also led to the deprecation of ANAT, as people didn't want to have two=
 methods for the=20
IPv4/IPv6 negotiation (and due to ANAT's other drawbacks).
A Cap-Neg extension via ccap would also miss a function for connectivity ch=
ecking (common with ANAT).
I think this ability was seen as the major advantage of ICE and an Cap-Neg =
extension=20
was no longer persued until the need for negotiation of a PSTN vs. IP adres=
s came up.
We should stick to the decision from IETF-68 to only use ICE for IPv4/v6 ne=
gotiation.


Regards
Thomas =20

> -----Urspr=FCngliche Nachricht-----
> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20
> Im Auftrag von Flemming Andreasen
> Gesendet: Donnerstag, 21. M=E4rz 2013 14:41
> An: Jonathan Lennox; mohamed.boucadair@orange.com; Hadriel=20
> Kaplan; Atle Monrad; md3135@att.com; Stach Thomas; Andrew Allen
> Cc: mmusic@ietf.org
> Betreff: Re: [MMUSIC] Connection Data Capability (ccap) and=20
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>=20
> Can we get some more comments from people on this please. In=20
> particular,=20
> I would like to hear if people are against "ccap" being able=20
> to convey=20
> an IP-address or not (if not, we can then debate the details of the=20
> restrictions around that separately) ?
>=20
> Thanks
>=20
> -- Flemming
>=20
>=20
> On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
> > I went through the discussion, and my reading is that there=20
> is agreement on not allowing ccap to be used for alternative=20
> IP address negotiation.
> >
> > That could be made clear in the text e.g. by modifying the=20
> second sentence Flemming quoted to read:
> >
> > 
> >      The 'ccap' attribute MUST NOT be used to select
> >      between different IP connection addresses (e.g. between
> >      "IP4" and "IP6" address families or different IP addresses
> >       within the same IP address family).
> > 
> >
> > The ccap attribute should be able to carry either an IP or=20
> PSTN address; that way either a PSTN or an IP bearer could be=20
> offered as the highest priority configuration (in the "m=3D"=20
> line).  However, if we want to clarify the intended use of=20
> ccap, we could modify the first sentence to read:
> >
> > 
> >     The 'ccap' capability attribute is intended for offering
> >     alternative connection addresses where the 
> >     is "IN" or "PSTN", i.e. selecting between an IP based
> >     bearer or a circuit-switched bearer.
> > 
> >
> > Simo
> >
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org=20
> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
> > Sent: 19. maaliskuuta 2013 8:24
> > To: mmusic
> > Subject: [MMUSIC] Connection Data Capability (ccap) and=20
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
> >
> > Greetings
> >
> > As you may have seen, there has recently been some list=20
> discussion on the "connection data capability" defined in
> > draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
> > http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
> >
> > To recap, the connection data capability ("ccap") provides=20
> capability negotiation capabilities for what amounts to the=20
> "c=3D" line in regular SDP, and as such enables negotiation of=20
> network type (such as "IN") and IP-address information (v4=20
> and v6 addresses). The Standards Track mechanism for=20
> negotiating and determining alternative IP-address=20
> information today is ICE, and hence the draft currently=20
> includes the following wording:
> > 
> > The 'ccap' capability attribute is intended to
> >      be used only when there is no other mechanism available for
> >      negotiating alternative connection address=20
> information, such as when
> >      the  is different among the alternative=20
> addresses (e.g.
> >      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
> >      situations where an existing mechanism (such as Interactive
> >      Connectivity Establishment (ICE) [RFC5245]) can be=20
> used to select
> >      between different connection addresses (e.g.  "IP4"=20
> and "IP6" or
> >      different IP addresses within the same IP address family).
> > 
> >
> > The above text has led to some confusion as to exactly when=20
> and what "ccap" can be used for. More specifically, is=20
> it/should it ever be allowed to use "ccap" to convey an IP4=20
> or IP6 address, and if so, under what circumstances ?
> >
> > If you have an opinion, please let us know.
> >
> > A couple of points to keep in mind:
> > - The current document has been WGLC'ed without comment ~6=20
> months ago.
> > - 3GPP has a dependency on the document (however I'm not=20
> sure if that dependency includes the above "IN" feature)
> > - The connection data capability is defined in a general=20
> manner to be generally useful in line with the overall=20
> capability negotiation framework (as opposed to targeted at=20
> one specific use case with one specific value)
> > - There are scenarios where ICE cannot be used, even if=20
> implemented (e.g. ice-mismatch).
> > - RFC 6849 (media loopback) provides for NAT traversal in=20
> the absence of ICE support
> >
> >
> > Thanks
> >
> > -- Flemming
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> > .
> >
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> =

From pkyzivat@alum.mit.edu  Thu Mar 21 13:01:37 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E321F8CB4 for ; Thu, 21 Mar 2013 13:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Level: 
X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=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 xzbGsyjk8Gtf for ; Thu, 21 Mar 2013 13:01:37 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BE8CA21F8C66 for ; Thu, 21 Mar 2013 13:01:36 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id EB6o1l00D0xGWP853L1cga; Thu, 21 Mar 2013 20:01:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id EL1b1l00f3ZTu2S3YL1bZH; Thu, 21 Mar 2013 20:01:36 +0000
Message-ID: <514B671D.70100@alum.mit.edu>
Date: Fri, 22 Mar 2013 04:01:33 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Magnus Westerlund 
References: <5149D1AA.4010805@ericsson.com> <5149E9E9.10900@alum.mit.edu> <514ADDB5.8040909@ericsson.com>
In-Reply-To: <514ADDB5.8040909@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363896096; bh=FnxhTBYz57qfA2Ge+9gB8EU6PRUFYaeSH52fSU6bGs0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XbnUkbK6xGuTodHJXlPP8CEaWYwJF7UNua6R+P/4tfnLeyPMVQQtcUnXA2ZRaR8ET 7l49Afg3JjxGkX/0lkSaA0vMh2qTAEEhftO1PtS5UDAipf/j9mTKH4GRBk6o3ueHQA a2EfevONDRh5sLZsBku8zHMj7C8Or3jbJBfQJtj+mVb1bLKegZ0XkAaIextlmQ81wW +n5OOrjHW+OsXQ3K7kBfCsJZ2u5CDhLX2hYYa1b9NSYjR6bctc9AG05BGLVV8rnNMj PXPmiKTEaVnjibujxddpsN7X4jNqiyxfHeztbwzUCzjg5CCXCf7+9HUfRXeg72a4nP nRo72/wWaT1tQ==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 20:01:37 -0000

On 3/21/13 6:15 PM, Magnus Westerlund wrote:
> On 2013-03-20 17:55, Paul Kyzivat wrote:
>> Magnus,
>>
>> Some comments on your review, from a CLUE perspective:
>>
>> On 3/20/13 11:11 PM, Magnus Westerlund wrote:
>>
>>> 6. Section 4.1:
>>>
>>> This section discuss the usage of the "data channels" within the SCTP
>>> association. My personal position is that for the moment this appears to
>>> be unnecessary. The most important part is the SCTP association
>>> establishment. Then one can discuss the general application using the
>>> SCTP association as whole. Examples of such are WebRTC data channel.
>>>
>>> If anyone want stream level information in SDP then I propose that this
>>> is handled as a extension to this signaling, not an from the start
>>> included functionality as we don't appear to have clear requirement for
>>> that.
>>
>> Who is "we"?
>
> MMUSIC WG
>
>> In CLUE we expect to use this mechanism for a CLUE data channel.
>> And we intend to do so in pure sip-sip cases as well as webrtc-sip and
>> webrtc-webrtc cases.
>
> Yes.
>>
>> While webrtc-webrtc may have an independent mechanism to work out the
>> channel usage, that is certainly not so for sip-sip sessions.
>>
>> So I think "we" (CLUE) have a requirement to negotiate channel usage in
>> SDP.
>
> Do you? Or it is sufficient to say
>
> m=application 12234 UDP/DTLS/SCTP CLUE
>
> Indicating that this SCTP association is using CLUEs defined way, not
> WebRTC. I want to separate the usage of individual SCTP streams and the
> general usage of the SCTP association.

Then what do we do for an WEBRTC client doing CLUE, talking to a native 
sip CLUE endpoint?

I guess clue could live with a mechanism that reserves the complete SCTP 
association, with all of its streams, as globally managed in a 
clue-specific way, as long as we can sort out the interop with webrtc.

	Thanks,
	Paul

>>> 7. Section 4.2:
>>>
>>> What are the requirements behind being able to establish multiple SCTP
>>> association over the same DTLS connection? I am very unclear why this
>>> would be required, and if not really needed I would suggest keeping
>>> things simple.
>>
>> I agree there has been no compelling need advanced for multiple SCTP
>> associations over the same DTLS connection. But the fact is that SCTP
>> has its own notion of port, and that needs to be dealt with one way or
>> another. At a minimum this document should specify what SCTP port is to
>> be used when conforming to this specification.
>
> Agreed, there need to be clarity on the port usage.
>
>>
>>> 8. Section 4.3: I guess this can for the moment be removed as it appears
>>> to be taken care in other places, such as the RTCWEB WG data channel
>>> protocol proposal.
>>
>> See above. That doesn't meet CLUE needs.
>
> Disagree, I don't think CLUE need SCTP stream specific indication or
> negoitation. It will be sufficient to indicate that this is CLUE using SCTP.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>


From pkyzivat@alum.mit.edu  Thu Mar 21 13:06:18 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6143521F8CB4 for ; Thu, 21 Mar 2013 13:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level: 
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.150,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_42=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 xpm85Qu0mcba for ; Thu, 21 Mar 2013 13:06:17 -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 768F021F8CCF for ; Thu, 21 Mar 2013 13:06:17 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id EEHT1l00516LCl059L6Gjl; Thu, 21 Mar 2013 20:06:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id EL6G1l00Q3ZTu2S3SL6GeR; Thu, 21 Mar 2013 20:06:16 +0000
Message-ID: <514B6837.50505@alum.mit.edu>
Date: Fri, 22 Mar 2013 04:06:15 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5148049B.6090205@cisco.com>  <514B0DE4.3060501@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363896376; bh=sHvsHdAiXoiQ3fjHy/iYTJ1PC+hgbIF0OH+Di+ipgdk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZnIgggeeWwL77fMWO2FUrHN9bHX6oztjJXEO1cFj/COxiU2KdjKZsq3Tfb3aQW0kx geuhG+TGIzUfSGE3PCCdo4vjNrc0NLVe2PU9docMCSWRgRRbVEmM4DliUpF6QICikh 8V3WCbuGUi5Gp1ydCyfXgM7NNV3Xkgmiv3kDRlg6fwRviLLyH2O4ZAYQXbY3XpmXqq uY1+L8wVlvfzWM80AhQMzo4TFBvhwmj3AZdz/OLV1tVASV1iLgPMnr9SjFmg3/ybmI OosMpr00CDplk/1KVGqIkCUVstOe2x+wJfxBOUmIdGHkFxyRFusHvCAnkcOy3Nms+l DzCFn/ATGMVbg==
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 20:06:18 -0000

+1

On 3/22/13 12:28 AM, Stach, Thomas wrote:
> I don't object against having an IP adress in the ccap attribute and a PSTN number in the c-line,
> if that indicates a preference for the PSTN number.
> But I don't like to have an IPv4 and/or IPv6 adress in both ccap and c-line
> as this would introduce a second method for IPv4/v6 negotiation in addition to ICE.
>
> My objection on this is based on what I remember from the IETF-68 discussion
> on usage of ICE vs. ANAT vs. SDP Capability-Negotiation for IPv4/IPv6 negotiation.
> Cap-Neg did not address negotiations of IP address families at that time,
> but could have been extended accordingly.
>
> Although the consensus at that meeting was very rough, ICE was finally selected as the
> method of choice since it also allows to test which address family would work based on connectivity checks.
> This also led to the deprecation of ANAT, as people didn't want to have two methods for the
> IPv4/IPv6 negotiation (and due to ANAT's other drawbacks).
> A Cap-Neg extension via ccap would also miss a function for connectivity checking (common with ANAT).
> I think this ability was seen as the major advantage of ICE and an Cap-Neg extension
> was no longer persued until the need for negotiation of a PSTN vs. IP adress came up.
> We should stick to the decision from IETF-68 to only use ICE for IPv4/v6 negotiation.
>
>
> Regards
> Thomas
>
>> -----Ursprüngliche Nachricht-----
>> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>> Im Auftrag von Flemming Andreasen
>> Gesendet: Donnerstag, 21. März 2013 14:41
>> An: Jonathan Lennox; mohamed.boucadair@orange.com; Hadriel
>> Kaplan; Atle Monrad; md3135@att.com; Stach Thomas; Andrew Allen
>> Cc: mmusic@ietf.org
>> Betreff: Re: [MMUSIC] Connection Data Capability (ccap) and
>> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>> Can we get some more comments from people on this please. In
>> particular,
>> I would like to hear if people are against "ccap" being able
>> to convey
>> an IP-address or not (if not, we can then debate the details of the
>> restrictions around that separately) ?
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>> On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
>>> I went through the discussion, and my reading is that there
>> is agreement on not allowing ccap to be used for alternative
>> IP address negotiation.
>>>
>>> That could be made clear in the text e.g. by modifying the
>> second sentence Flemming quoted to read:
>>>
>>> 
>>>       The 'ccap' attribute MUST NOT be used to select
>>>       between different IP connection addresses (e.g. between
>>>       "IP4" and "IP6" address families or different IP addresses
>>>        within the same IP address family).
>>> 
>>>
>>> The ccap attribute should be able to carry either an IP or
>> PSTN address; that way either a PSTN or an IP bearer could be
>> offered as the highest priority configuration (in the "m="
>> line).  However, if we want to clarify the intended use of
>> ccap, we could modify the first sentence to read:
>>>
>>> 
>>>      The 'ccap' capability attribute is intended for offering
>>>      alternative connection addresses where the 
>>>      is "IN" or "PSTN", i.e. selecting between an IP based
>>>      bearer or a circuit-switched bearer.
>>> 
>>>
>>> Simo
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org
>> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
>>> Sent: 19. maaliskuuta 2013 8:24
>>> To: mmusic
>>> Subject: [MMUSIC] Connection Data Capability (ccap) and
>> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> Greetings
>>>
>>> As you may have seen, there has recently been some list
>> discussion on the "connection data capability" defined in
>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>>
>>> To recap, the connection data capability ("ccap") provides
>> capability negotiation capabilities for what amounts to the
>> "c=" line in regular SDP, and as such enables negotiation of
>> network type (such as "IN") and IP-address information (v4
>> and v6 addresses). The Standards Track mechanism for
>> negotiating and determining alternative IP-address
>> information today is ICE, and hence the draft currently
>> includes the following wording:
>>> 
>>> The 'ccap' capability attribute is intended to
>>>       be used only when there is no other mechanism available for
>>>       negotiating alternative connection address
>> information, such as when
>>>       the  is different among the alternative
>> addresses (e.g.
>>>       "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>>       situations where an existing mechanism (such as Interactive
>>>       Connectivity Establishment (ICE) [RFC5245]) can be
>> used to select
>>>       between different connection addresses (e.g.  "IP4"
>> and "IP6" or
>>>       different IP addresses within the same IP address family).
>>> 
>>>
>>> The above text has led to some confusion as to exactly when
>> and what "ccap" can be used for. More specifically, is
>> it/should it ever be allowed to use "ccap" to convey an IP4
>> or IP6 address, and if so, under what circumstances ?
>>>
>>> If you have an opinion, please let us know.
>>>
>>> A couple of points to keep in mind:
>>> - The current document has been WGLC'ed without comment ~6
>> months ago.
>>> - 3GPP has a dependency on the document (however I'm not
>> sure if that dependency includes the above "IN" feature)
>>> - The connection data capability is defined in a general
>> manner to be generally useful in line with the overall
>> capability negotiation framework (as opposed to targeted at
>> one specific use case with one specific value)
>>> - There are scenarios where ICE cannot be used, even if
>> implemented (e.g. ice-mismatch).
>>> - RFC 6849 (media loopback) provides for NAT traversal in
>> the absence of ICE support
>>>
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From juberti@google.com  Thu Mar 21 13:44:19 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE06221F8992 for ; Thu, 21 Mar 2013 13:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.826
X-Spam-Level: 
X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU+cn8Fgzn+p for ; Thu, 21 Mar 2013 13:44:19 -0700 (PDT)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id E65F721F862A for ; Thu, 21 Mar 2013 13:44:18 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id l8so1579111qaq.16 for ; Thu, 21 Mar 2013 13:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BKHOvhOpWFaqd2EtushJZXtWXQIIOT+WCRUVuq4x5Fg=; b=C9kvn6QW1ZI6dekiHC04w068W1agFT8bMYddGdlq/v6lzKBE+jDPZyjF4nnZc76GPz Oj6S2oO2mGdb445QynFlmMk/xh1kjD5lakI+N1EAmZUTpe/wlrLwTt/0y/8yFY6Kp1Nh fiUP34jL4YxsbV02XjcQh3W6WweqDPL/uYz+NUFExRI8o7FEr2bmLu0Ny0Znpnhx8jMC VycMS10m7J5bE+DeVBrPlwKV6oBfJlTFQhKa3F+LAFR5STy+Gaoeooz1+NXsXsV0YLT6 OCf+MDwa4ihUpu03d5aIqumKqDMb0a2oM5sNPdYaVaNRiQ9NDyW1tgO355X2lZC05KZT 9cfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=BKHOvhOpWFaqd2EtushJZXtWXQIIOT+WCRUVuq4x5Fg=; b=E04DFunLbONMjktjUB6KgJZh3xpQo0t5ZiE56AQACvLgHjxiUG19AxqXIKTzRkRATM xn3zweLUb0N/76TRr/aXFbD7pQm269vmZtLN1LtmbK9rPlqQBIjEzXOaDYGHhnaR6wdg AwLdCFWEXOMDW1LuClktLyv8tmHpXu/nnmsSkdPsLdWv3AQMiOdUe5+ghlgsikUzY1YX s9QwzpgscFTtge+LcP0qas0blCGcUzb41SqOrGEJYZ9U6bDFf24IE/7iA8jpk2e5tKb3 Vb0Irq2cGEd5k7saF7l5MeAAxlfNz3zjVQsJyzMaQtzhY6DYsARlxqyct7Pxkw8nV6gp 5OHg==
X-Received: by 10.229.137.75 with SMTP id v11mr652958qct.26.1363898654263; Thu, 21 Mar 2013 13:44:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Thu, 21 Mar 2013 13:43:54 -0700 (PDT)
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>  <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com>
From: Justin Uberti 
Date: Thu, 21 Mar 2013 13:43:54 -0700
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Content-Type: multipart/alternative; boundary=00235452ecd0cc4dbb04d87566aa
X-Gm-Message-State: ALoCoQnMnpmUK95bS4y1DW0DjpG70vQgqV7jjyjU/e/1p/0Y/TOd9ljSij0yhcbDsoCGnVq95YkKPc+OlS8vHn4MrRNAx5a0NJi/tR6eUy4ar5spKU3XKjdZPvn7Gjjg3CcHqV/zepfXyYySLjJ7qYQHIonPqvIHDm/zzvrgmNpWEUt0guKPFPKUpMIxCw1jAFtC01cbbay7
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 20:44:19 -0000

--00235452ecd0cc4dbb04d87566aa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2013 at 11:51 PM, Mo Zanaty (mzanaty) wr=
ote:

>  Hi Justin,****
>
> ** **
>
> I understand the potential problems with legacy endpoints as described in
> A.2 of Christer=E2=80=99s draft, not just intermediaries (A.4) which I th=
ought Dale
> was specifically commenting about. The constraints of legacy peers and
> intermediaries is obviously important to the overall solution, but
> orthogonal to how we signal the desired port in a new way (as a single
> attribute or using the grouping framework).****
>
> ** **
>
> BTW, has anyone actually observed failures? I ask because I could not get
> products to fail (when simply offering the same ports) in my (limited)
> interop lab. SIPit 30 was on my campus last month, I wish I would have
> tested it there for more data points. I can try at SuperOp next month. Ju=
st
> checking if someone hit a real problem before starting this bundle party.=
*
> ***
>
> **
>

Yes, we have observed failures directly, and Christer has identified
several cases that can cause latent malfunctions.

--00235452ecd0cc4dbb04d87566aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Mar 20, 2013 at 11:51 PM, Mo Zanaty (mzanaty) <mzanaty@cis=
co.com> wrote:














Hi Justin,


=C2=A0


I understand the potential problems wit=
h legacy endpoints as described in A.2 of Christer=E2=80=99s draft, not jus=
t intermediaries (A.4) which I thought Dale was specifically commenting
 about. The constraints of legacy peers and intermediaries is obviously imp=
ortant to the overall solution, but orthogonal to how we signal the desired=
 port in a new way (as a single attribute or using the grouping framework).=





=C2=A0


BTW, has anyone actually observed failu=
res? I ask because I could not get products to fail (when simply offering t=
he same ports) in my (limited) interop lab. SIPit 30 was
 on my campus last month, I wish I would have tested it there for more data=
 points. I can try at SuperOp next month. Just checking if someone hit a re=
al problem before starting this bundle party.




=C2=A0
=C2=A0
Yes, we have observed failures direct=
ly, and Christer has identified several cases that can cause latent malfunc=
tions.=C2=A0





--00235452ecd0cc4dbb04d87566aa--

From richard.ejzak@alcatel-lucent.com  Thu Mar 21 18:52:10 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3621A21F85E8 for ; Thu, 21 Mar 2013 18:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level: 
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, 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 pOgYpBXkBl0x for ; Thu, 21 Mar 2013 18:52:09 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48E21F85D2 for ; Thu, 21 Mar 2013 18:52:09 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2M1q6bl019096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Mar 2013 20:52:06 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2M1q5JB025597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 21:52:05 -0400
Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 21 Mar 2013 21:52:05 -0400
From: "Ejzak, Richard P (Richard)" 
To: Justin Uberti , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] 10 BUNDLE questions
Thread-Index: AQHOIb7u3UCm9g19LUKs5F6HDPZz4ZiwwNgA
Date: Fri, 22 Mar 2013 01:52:05 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F36EBBB41US70TWXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 01:52:10 -0000

--_000_03FBA798AC24E3498B74F47FD082A92F36EBBB41US70TWXCHMBA12z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSnVzdGluLA0KSSBoYXZlIGNvbW1lbnRzIG9uIGl0ZW1zIDQgYW5kIDEwIGluIHlvdXIgb3Jp
Z2luYWwgbGlzdC4NCg0KNDogSW4gNi4xLCBsaXN0IDEsIGlmIHRoZSBhbnN3ZXJlciBjaG9vc2Vz
IHRvIGJ1bmRsZSBhbmQgc2VsZWN0cyB0aGUgNS10dXBsZSBmcm9tIHRoZSBmaXJzdCBtIGxpbmUg
Zm9yIHRoZSBncm91cCwgdGhlbiBpdCBtdXN0IGFsc28gYXNzdW1lIHRoZSB1c2Ugb2YgdGhlIGM9
LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCAoYWxsIHRyYW5zcG9ydCByZWxhdGVkIGF0dHJp
YnV0ZXMpIGZyb20gdGhhdCBtIGxpbmUgZm9yIHRoZSBncm91cC4gIFRoZW4gYWNjb3JkaW5nIHRv
IHRoZSBydWxlcywgdGhlIDJuZCBvZmZlciBtdXN0IHRoZW4gaW5jbHVkZSB0aGUgc2FtZSB2YWx1
ZSBmb3IgYz0sIHJ0Y3AtbXV4IGFuZCBhPWZpbmdlcnByaW50IGZvciBhbGwgbSBsaW5lcyBpbiB0
aGUgZ3JvdXAuICBJZiB5b3UgcmVsYXggY29uZGl0aW9ucyAyLCA1IGFuZCA3IGZvciB0aGUgMXN0
IG9mZmVyLCBpdCB3b3VsZCBzZWVtIGEgbGl0dGxlIHN0cmFuZ2UgYW5kIHdvdWxkIHJlcXVpcmUg
ZXh0cmEgd29yayB0byBjbGVhbiB1cCBhbGwgdGhlIG0gbGluZXMgaW4gdGhlIDJuZCBvZmZlciBp
ZiB0aGUgMXN0IG9mZmVyIGhhZCBkaWZmZXJlbnQgdmFsdWVzIGZvciBjPSwgcnRjcC1tdXggYW5k
IGE9ZmluZ2VycHJpbnQgaW4gYWxsIHRoZSBtIGxpbmVzIG9mIHRoZSBncm91cC4gIEFzIEkgc2Vl
IGl0LCBpdOKAmXMgZWFzaWVyIHRvIGhhdmUgdGhpcyBydWxlIGZyb20gdGhlIGJlZ2lubmluZyB1
bmxlc3MgdGhlcmUgYXJlIHNvbWUgdXNlIGNhc2VzIHdoZXJlIHlvdSBtaWdodCB3YW50IGRpZmZl
cmVudCB2YWx1ZXMgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCBpZiBidW5kbGUg
Y2Fubm90IGJlIG5lZ290aWF0ZWQuICBEbyB5b3UgKG9yIGFueW9uZSBlbHNlKSBzZWUgYW55IHJl
YXNvbiB0byBoYXZlIHRoaXMgY2FwYWJpbGl0eT8gIEl0IHByb2JhYmx5IGlzbuKAmXQgdGhhdCBp
bXBvcnRhbnQgYSBydWxlIChleGNlcHQgZm9yIGNvbnZlbmllbmNlKSBzaW5jZSBhbnkgbWlkZGxl
Ym94IHdpbGwgZ2V0IHN0cmFpZ2h0ZW5lZCBvdXQgd2l0aCB0aGUgMm5kIG9mZmVyIGFuZCBhbnkg
cGVlciBhZ3JlZWluZyB0byBidW5kbGUga25vd3MgdG8gaWdub3JlIHRoZSB0cmFuc3BvcnQgcmVs
YXRlZCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBvdGhlciBsaW5lcyAoZXhjZXB0IGFzIGRpc2N1c3Nl
ZCBiZWxvdykuDQoNCjEwOiBJIHRoaW5rIHdlIGhhdmUgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byB1
bmJ1bmRsZSB3aXRoaW4gYSBQZWVyQ29ubmVjdGlvbi4gIEZvciB0aGUgZXJyb3IgY2FzZSBkZXNj
cmliZWQgKHR3aWNlKSBhdCB0aGUgbWlrZSBpbiBPcmxhbmRvLCBpZiB0aGUgZmlyc3QgYW5zd2Vy
IGNvbWVzIGJhY2sgYXNraW5nIHRvIGJ1bmRsZSBidXQgc2lnbmFsaW5nIGRpZmZlcmVudCBwb3J0
cywgaXQgaXMgYmVjYXVzZSBvZiBhbiBpbnRlcm1lZGlhcnkgZm9yd2FyZGluZyBidW5kbGUgYXR0
cmlidXRlcyB3aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhlbSB3aGlsZSByZW1hcHBpbmcgcG9ydHMu
ICBUaGVyZSBzZWVtZWQgdG8gYmUgYWdyZWVtZW50IGluIHRoaXMgY2FzZSAob3IgYXQgbGVhc3Qg
dGhlIG9waW5pb24gd2FzIGV4cHJlc3NlZCkgdGhhdCB0aGUgb2ZmZXJlciBuZWVkcyB0byBkZXRl
Y3QgdGhpcyBjb25kaXRpb24gYW5kIHNlbmQgYSAybmQgb2ZmZXIgd2l0aCBkaWZmZXJlbnQgcG9y
dHMgYW5kIHdpdGhvdXQgYnVuZGxlIChlbHNlIHRoZSBhbnN3ZXJlciB3aWxsIGNvbnRpbnVlIHRv
IGFzc3VtZSBidW5kbGUgd2hpbGUgdGhlIGludGVybWVkaWFyeSB3aWxsIG5vdCkuICBOb3RlIHRo
YXQgdGhpcyBjYXNlIGFwcGVhcnMgKHRvIHRoZSBhbnN3ZXJlcikgYXMgaWYgYnVuZGxlIGlzIHN1
Y2Nlc3NmdWxseSBuZWdvdGlhdGVkIGJ1dCB0aGVuIGl0IGlzIGltbWVkaWF0ZWx5IHJlbW92ZWQg
d2l0aCB0aGUgMm5kIG9mZmVyLg0KDQpJIHRoaW5rIHdlIGFsc28gaGF2ZSB0aGUgM3BjYyB1c2Ug
Y2FzZSB3aGVyZSBhIG1pZC1jYWxsIGJ1bmRsZWQgb2ZmZXIgZ29lcyB0byBhIGRpZmZlcmVudCBl
bmRwb2ludCB0aGF0IGNob29zZXMgbm90IHRvIGJ1bmRsZS4gIEFzIGxvbmcgYXMgaXQgcmVtb3Zl
cyB0aGUgYnVuZGxlIGF0dHJpYnV0ZXMgYW5kIHJldHVybnMgZGlmZmVyZW50IHBvcnRzLCB3aHkg
c2hvdWxkIHdlIGRpc2FsbG93IHRoaXM/ICBJdCBvbmx5IHJlcXVpcmVzIGFuIElDRSByZXN0YXJ0
LiAgVGhpcyB3aWxsIGV2ZW4gd29yayB3aXRoIG1vc3QgKG5ldykgaW50ZXJtZWRpYXJpZXMgZXhj
ZXB0IHRob3NlIHRoYXQgY2hva2Ugb24gc2VlaW5nIHRoZSBzYW1lIHBvcnQgaW4gbXVsdGlwbGUg
bSBsaW5lcy4gIFdoaWNoIGJyaW5ncyBtZSB0byB3aHkgSSB0aGluayB3ZSBhbHNvIG5lZWQgdG8g
YmUgYWJsZSB0byBpbmRpY2F0ZSB2aWEgdGhlIEFQSSB3aGV0aGVyIGEgbWlkLWNhbGwgb2ZmZXIg
aXMgdG8gYmUgc2lnbmFsZWQgd2l0aCB0aGUgc2FtZSBvciBkaWZmZXJlbnQgcG9ydHMgZm9yIGEg
YnVuZGxlIGdyb3VwIChhcyBJIGFsc28gcmVxdWVzdGVkIGF0IHRoZSBtaWtlKS4NCg0KUmljaGFy
ZA0KDQpGcm9tOiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogRnJpZGF5LCBNYXJj
aCAxNSwgMjAxMyAzOjUxIFBNDQpUbzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBbTU1VU0lD
XSAxMCBCVU5ETEUgcXVlc3Rpb25zDQoNClRoZSBsaXN0IGJlbG93IGlzIGEgc2V0IG9mIHF1ZXN0
aW9ucyAoc29tZSBtYXJrZWQgYXMgT1BFTiBJU1NVRSBhbHJlYWR5KSByZWdhcmRpbmcgdGhlIG5l
dyBCVU5ETEUgcHJvcG9zYWwuIElmIHlvdSBhZ3JlZSB3aXRoIG15IHN1Z2dlc3RlZCBhbnN3ZXJz
LCBJJ20gd2lsbGluZyB0byBjb250cmlidXRlIHRleHQgYWNjb3JkaW5nbHkuDQoNCiAgMS4gIENh
biB5b3UgY3JlYXRlIGEgQlVORExFIHdpdGggYSBzaW5nbGUgbT0gbGluZT8gKGFzc3VtaW5nIHll
cykNCiAgMi4gIENhbiB5b3UgY3JlYXRlIG11bHRpcGxlIEJVTkRMRXM/IChhc3N1bWluZyB5ZXMp
DQogIDMuICBXaGVuIGNyZWF0aW5nIGFuIGluaXRpYWwgb2ZmZXIsIGhvdyBzaG91bGQgd2UgZGVh
bCB3aXRoIHRoZSBjYXNlIHdoZXJlIGEgIm51bGwiIHBvcnQgaXMgdG8gYmUgdXNlZCB3aXRoIHRy
aWNrbGUgSUNFIChzaW5jZSA2LjE6MSBpbmRpY2F0ZXMgdGhlIHBvcnRzIE1VU1QgYmUgZGlmZmVy
ZW50KQ0KICA0LiAgRnJvbSA2LjEsIGxpc3QgMSAtIGFyZSBjb25kaXRpb25zIDIsIDUsIDcgcmVh
bGx5IG5lY2Vzc2FyeT8gKE1VU1QgdXNlIHNhbWUgYz0sIGFkZCBydGNwLW11eCwgc2FtZSBhPWZp
bmdlcnByaW50KQ0KICA1LiAgRnJvbSA2LjEsIGxpc3QgMiAtIGlzIGNvbmRpdGlvbiA2IHJpZ2h0
PyBXaHkgd291bGQgd2UgdXNlIGRpZmZlcmVudCBTREVTIGtleXMgZm9yIGEgc2luZ2xlIFJUUCBz
ZXNzaW9uPw0KICA2LiAgSWYgeW91IHN0YXJ0IHdpdGggYSBtPSBsaW5lIHdpdGggb25lIFNERVMg
Y29uZmlnIChlLmcuIDMyLWJpdCBNQUMpLCBhbmQgdGhlbiBCVU5ETEUgd2l0aCBhbm90aGVyIFNE
RVMgbGluZSB3aXRoIGEgZGlmZmVyZW50IChub24gb3ZlcmxhcHBpbmcpIFNERVMgY29uZmlnIChl
LmcuIDgwLWJpdCBNQUMpLCB3aGF0IGhhcHBlbnM/IChhc3N1bWUgZmFpbCkNCiAgNy4gIElmIHRo
ZSBCVU5ETEUgbWlkcyBpbiB0aGUgYW5zd2VyIGRvZXNuJ3QgbWF0Y2ggdGhlIEJVTkRMRSBtaWRz
IGluIHRoZSBvZmZlciwgd2hhdCBoYXBwZW5zPyAoYXNzdW1lIGZhaWwpDQogIDguICBJZiB5b3Ug
YWRkIGEgbT0gbGluZSB0byBhbiBleGlzdGluZyBCVU5ETEUsIGNhbiB0aGUgcmVjaXBpZW50IHJl
amVjdCB0aGF0IEJVTkRMRWluZyAoYXNzdW1lIG5vKQ0KICA5LiAgSWYgbT0gbGluZXMgYXJlIHJl
amVjdGVkLCBzaG91bGQgdGhlaXIgbWlkcyBzaG93IHVwIGluIHRoZSBCVU5ETEUgYW5zd2VyPyAo
YXNzdW1lIHllcz8pDQoNCiAgICAgKiAgIElmIG5vdCwgaG93IGRvZXMgcmVtb3RlIHNpZGUgaW5k
aWNhdGUgQlVORExFIHN1cHBvcnQgaWYgaXQgcmVqZWN0cyB0aGUgbT0gbGluZXMgdGhhdCBhcmUg
QlVORExFZD8NCg0KICAxLiAgSXMgdGhlcmUgYW55IHdheSwgaW4gYSBzaW5nbGUgUGVlckNvbm5l
Y3Rpb24sIHRvIHVuQlVORExFIG09IGxpbmVzIHRoYXQgd2VyZSBwcmV2aW91c2x5IEJVTkRMRWQg
KGFzc3VtZSBubykNCg==

--_000_03FBA798AC24E3498B74F47FD082A92F36EBBB41US70TWXCHMBA12z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEwNDMwNTkzNDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6LTUzNjMzMTIyODt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K
CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGNvbW1l
bnRzIG9uIGl0ZW1zIDQgYW5kIDEwIGluIHlvdXIgb3JpZ2luYWwgbGlzdC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQ6
IEluIDYuMSwgbGlzdCAxLCBpZiB0aGUgYW5zd2VyZXIgY2hvb3NlcyB0byBidW5kbGUgYW5kIHNl
bGVjdHMgdGhlIDUtdHVwbGUgZnJvbSB0aGUgZmlyc3QgbSBsaW5lIGZvciB0aGUgZ3JvdXAsIHRo
ZW4gaXQgbXVzdCBhbHNvIGFzc3VtZSB0aGUgdXNlIG9mIHRoZSBjPSwNCiBydGNwLW11eCBhbmQg
YT1maW5nZXJwcmludCAoYWxsIHRyYW5zcG9ydCByZWxhdGVkIGF0dHJpYnV0ZXMpIGZyb20gdGhh
dCBtIGxpbmUgZm9yIHRoZSBncm91cC4mbmJzcDsgVGhlbiBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVz
LCB0aGUgMjxzdXA+bmQ8L3N1cD4gb2ZmZXIgbXVzdCB0aGVuIGluY2x1ZGUgdGhlIHNhbWUgdmFs
dWUgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCBmb3IgYWxsIG0gbGluZXMgaW4g
dGhlIGdyb3VwLiZuYnNwOyBJZiB5b3UgcmVsYXgNCiBjb25kaXRpb25zIDIsIDUgYW5kIDcgZm9y
IHRoZSAxPHN1cD5zdDwvc3VwPiBvZmZlciwgaXQgd291bGQgc2VlbSBhIGxpdHRsZSBzdHJhbmdl
IGFuZCB3b3VsZCByZXF1aXJlIGV4dHJhIHdvcmsgdG8gY2xlYW4gdXAgYWxsIHRoZSBtIGxpbmVz
IGluIHRoZSAyPHN1cD5uZDwvc3VwPiBvZmZlciBpZiB0aGUgMTxzdXA+c3Q8L3N1cD4gb2ZmZXIg
aGFkIGRpZmZlcmVudCB2YWx1ZXMgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCBp
biBhbGwNCiB0aGUgbSBsaW5lcyBvZiB0aGUgZ3JvdXAuJm5ic3A7IEFzIEkgc2VlIGl0LCBpdOKA
mXMgZWFzaWVyIHRvIGhhdmUgdGhpcyBydWxlIGZyb20gdGhlIGJlZ2lubmluZyB1bmxlc3MgdGhl
cmUgYXJlIHNvbWUgdXNlIGNhc2VzIHdoZXJlIHlvdSBtaWdodCB3YW50IGRpZmZlcmVudCB2YWx1
ZXMgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCBpZiBidW5kbGUgY2Fubm90IGJl
IG5lZ290aWF0ZWQuJm5ic3A7IERvIHlvdSAob3IgYW55b25lIGVsc2UpIHNlZSBhbnkNCiByZWFz
b24gdG8gaGF2ZSB0aGlzIGNhcGFiaWxpdHk/ICZuYnNwO0l0IHByb2JhYmx5IGlzbuKAmXQgdGhh
dCBpbXBvcnRhbnQgYSBydWxlIChleGNlcHQgZm9yIGNvbnZlbmllbmNlKSBzaW5jZSBhbnkgbWlk
ZGxlYm94IHdpbGwgZ2V0IHN0cmFpZ2h0ZW5lZCBvdXQgd2l0aCB0aGUgMjxzdXA+bmQ8L3N1cD4g
b2ZmZXIgYW5kIGFueSBwZWVyIGFncmVlaW5nIHRvIGJ1bmRsZSBrbm93cyB0byBpZ25vcmUgdGhl
IHRyYW5zcG9ydCByZWxhdGVkIGluZm9ybWF0aW9uDQogZnJvbSB0aGUgb3RoZXIgbGluZXMgKGV4
Y2VwdCBhcyBkaXNjdXNzZWQgYmVsb3cpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MTA6IEkgdGhpbmsgd2UgaGF2ZSB0
byBoYXZlIHRoZSBhYmlsaXR5IHRvIHVuYnVuZGxlIHdpdGhpbiBhIFBlZXJDb25uZWN0aW9uLiZu
YnNwOyBGb3IgdGhlIGVycm9yIGNhc2UgZGVzY3JpYmVkICh0d2ljZSkgYXQgdGhlIG1pa2UgaW4g
T3JsYW5kbywgaWYgdGhlIGZpcnN0IGFuc3dlcg0KIGNvbWVzIGJhY2sgYXNraW5nIHRvIGJ1bmRs
ZSBidXQgc2lnbmFsaW5nIGRpZmZlcmVudCBwb3J0cywgaXQgaXMgYmVjYXVzZSBvZiBhbiBpbnRl
cm1lZGlhcnkgZm9yd2FyZGluZyBidW5kbGUgYXR0cmlidXRlcyB3aXRob3V0IHVuZGVyc3RhbmRp
bmcgdGhlbSB3aGlsZSByZW1hcHBpbmcgcG9ydHMuJm5ic3A7IFRoZXJlIHNlZW1lZCB0byBiZSBh
Z3JlZW1lbnQgaW4gdGhpcyBjYXNlIChvciBhdCBsZWFzdCB0aGUgb3BpbmlvbiB3YXMgZXhwcmVz
c2VkKSB0aGF0DQogdGhlIG9mZmVyZXIgbmVlZHMgdG8gZGV0ZWN0IHRoaXMgY29uZGl0aW9uIGFu
ZCBzZW5kIGEgMjxzdXA+bmQ8L3N1cD4gb2ZmZXIgd2l0aCBkaWZmZXJlbnQgcG9ydHMgYW5kIHdp
dGhvdXQgYnVuZGxlIChlbHNlIHRoZSBhbnN3ZXJlciB3aWxsIGNvbnRpbnVlIHRvIGFzc3VtZSBi
dW5kbGUgd2hpbGUgdGhlIGludGVybWVkaWFyeSB3aWxsIG5vdCkuICZuYnNwO05vdGUgdGhhdCB0
aGlzIGNhc2UgYXBwZWFycyAodG8gdGhlIGFuc3dlcmVyKSBhcyBpZiBidW5kbGUNCiBpcyBzdWNj
ZXNzZnVsbHkgbmVnb3RpYXRlZCBidXQgdGhlbiBpdCBpcyBpbW1lZGlhdGVseSByZW1vdmVkIHdp
dGggdGhlIDI8c3VwPm5kPC9zdXA+IG9mZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB3ZSBhbHNvIGhh
dmUgdGhlIDNwY2MgdXNlIGNhc2Ugd2hlcmUgYSBtaWQtY2FsbCBidW5kbGVkIG9mZmVyIGdvZXMg
dG8gYSBkaWZmZXJlbnQgZW5kcG9pbnQgdGhhdCBjaG9vc2VzIG5vdCB0byBidW5kbGUuJm5ic3A7
IEFzIGxvbmcgYXMgaXQgcmVtb3ZlcyB0aGUgYnVuZGxlDQogYXR0cmlidXRlcyBhbmQgcmV0dXJu
cyBkaWZmZXJlbnQgcG9ydHMsIHdoeSBzaG91bGQgd2UgZGlzYWxsb3cgdGhpcz8gJm5ic3A7SXQg
b25seSByZXF1aXJlcyBhbiBJQ0UgcmVzdGFydC4mbmJzcDsgVGhpcyB3aWxsIGV2ZW4gd29yayB3
aXRoIG1vc3QgKG5ldykgaW50ZXJtZWRpYXJpZXMgZXhjZXB0IHRob3NlIHRoYXQgY2hva2Ugb24g
c2VlaW5nIHRoZSBzYW1lIHBvcnQgaW4gbXVsdGlwbGUgbSBsaW5lcy4mbmJzcDsgV2hpY2ggYnJp
bmdzIG1lIHRvIHdoeSBJIHRoaW5rDQogd2UgYWxzbyBuZWVkIHRvIGJlIGFibGUgdG8gaW5kaWNh
dGUgdmlhIHRoZSBBUEkgd2hldGhlciBhIG1pZC1jYWxsIG9mZmVyIGlzIHRvIGJlIHNpZ25hbGVk
IHdpdGggdGhlIHNhbWUgb3IgZGlmZmVyZW50IHBvcnRzIGZvciBhIGJ1bmRsZSBncm91cCAoYXMg
SSBhbHNvIHJlcXVlc3RlZCBhdCB0aGUgbWlrZSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJpY2hhcmQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbW11c2ljLWJvdW5jZXNAaWV0
Zi5vcmcgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDE1LCAyMDEz
IDM6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6
PC9iPiBbTU1VU0lDXSAxMCBCVU5ETEUgcXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsaXN0IGJlbG93IGlzIGEgc2V0IG9m
IHF1ZXN0aW9ucyAoc29tZSBtYXJrZWQgYXMgT1BFTiBJU1NVRSBhbHJlYWR5KSByZWdhcmRpbmcg
dGhlIG5ldyBCVU5ETEUgcHJvcG9zYWwuIElmIHlvdSBhZ3JlZSB3aXRoIG15IHN1Z2dlc3RlZCBh
bnN3ZXJzLCBJJ20gd2lsbGluZyB0byBjb250cmlidXRlIHRleHQgYWNjb3JkaW5nbHkuPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQ2FuIHlvdSBjcmVhdGUgYSBCVU5E
TEUgd2l0aCBhIHNpbmdsZSBtPSBsaW5lPyAoYXNzdW1pbmcgeWVzKTxvOnA+PC9vOnA+PC9saT48
bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkNhbiB5b3Ug
Y3JlYXRlIG11bHRpcGxlIEJVTkRMRXM/IChhc3N1bWluZyB5ZXMpPG86cD48L286cD48L2xpPjxs
aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KV2hlbiBjcmVh
dGluZyBhbiBpbml0aWFsIG9mZmVyLCBob3cgc2hvdWxkIHdlIGRlYWwgd2l0aCB0aGUgY2FzZSB3
aGVyZSBhICZxdW90O251bGwmcXVvdDsgcG9ydCBpcyB0byBiZSB1c2VkIHdpdGggdHJpY2tsZSBJ
Q0UgKHNpbmNlIDYuMToxIGluZGljYXRlcyB0aGUgcG9ydHMgTVVTVCBiZSBkaWZmZXJlbnQpJm5i
c3A7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2
ZWwxIGxmbzEiPg0KRnJvbSA2LjEsIGxpc3QgMSAtIGFyZSBjb25kaXRpb25zIDIsIDUsIDcgcmVh
bGx5IG5lY2Vzc2FyeT8gKE1VU1QgdXNlIHNhbWUgYz0sIGFkZCBydGNwLW11eCwgc2FtZSBhPWZp
bmdlcnByaW50KTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwwIGxldmVsMSBsZm8xIj4NCkZyb20gNi4xLCBsaXN0IDIgLSBpcyBjb25kaXRpb24gNiByaWdo
dD8gV2h5IHdvdWxkIHdlIHVzZSBkaWZmZXJlbnQgU0RFUyBrZXlzIGZvciBhIHNpbmdsZSBSVFAg
c2Vzc2lvbj88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps
MCBsZXZlbDEgbGZvMSI+DQpJZiB5b3Ugc3RhcnQgd2l0aCBhIG09IGxpbmUgd2l0aCBvbmUgU0RF
UyBjb25maWcgKGUuZy4gMzItYml0IE1BQyksIGFuZCB0aGVuIEJVTkRMRSB3aXRoIGFub3RoZXIg
U0RFUyBsaW5lIHdpdGggYSBkaWZmZXJlbnQgKG5vbiBvdmVybGFwcGluZykgU0RFUyBjb25maWcg
KGUuZy4gODAtYml0IE1BQyksIHdoYXQgaGFwcGVucz8gKGFzc3VtZSBmYWlsKTxvOnA+PC9vOnA+
PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCklm
IHRoZSBCVU5ETEUgbWlkcyBpbiB0aGUgYW5zd2VyIGRvZXNuJ3QgbWF0Y2ggdGhlIEJVTkRMRSBt
aWRzIGluIHRoZSBvZmZlciwgd2hhdCBoYXBwZW5zPyAoYXNzdW1lIGZhaWwpPG86cD48L286cD48
L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWYg
eW91IGFkZCBhIG09IGxpbmUgdG8gYW4gZXhpc3RpbmcgQlVORExFLCBjYW4gdGhlIHJlY2lwaWVu
dCByZWplY3QgdGhhdCBCVU5ETEVpbmcgKGFzc3VtZSBubyk8bzpwPjwvbzpwPjwvbGk+PGxpIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJZiBtPSBsaW5lcyBh
cmUgcmVqZWN0ZWQsIHNob3VsZCB0aGVpciBtaWRzIHNob3cgdXAgaW4gdGhlIEJVTkRMRSBhbnN3
ZXI/IChhc3N1bWUgeWVzPyk8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdGFydD0iOSIgdHlw
ZT0iMSI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt
c28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQpJZiBub3QsIGhvdyBkb2VzIHJlbW90ZSBzaWRlIGlu
ZGljYXRlIEJVTkRMRSBzdXBwb3J0IGlmIGl0IHJlamVjdHMgdGhlIG09IGxpbmVzIHRoYXQgYXJl
IEJVTkRMRWQ/PG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPG9sIHN0YXJ0PSIxMCIgdHlw
ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N
CklzIHRoZXJlIGFueSB3YXksIGluIGEgc2luZ2xlIFBlZXJDb25uZWN0aW9uLCB0byB1bkJVTkRM
RSBtPSBsaW5lcyB0aGF0IHdlcmUgcHJldmlvdXNseSBCVU5ETEVkIChhc3N1bWUgbm8pPG86cD48
L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_03FBA798AC24E3498B74F47FD082A92F36EBBB41US70TWXCHMBA12z_--

From prvs=2793a08615=aallen@blackberry.com  Thu Mar 21 22:35:48 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD321F9025 for ; Thu, 21 Mar 2013 22:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.316
X-Spam-Level: 
X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[AWL=0.287,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396,  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 YzNm1J42f1w7 for ; Thu, 21 Mar 2013 22:35:43 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4C21F8FE3 for ; Thu, 21 Mar 2013 22:35:43 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-bb-514beda85292
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 51.BF.09265.8ADEB415; Fri, 22 Mar 2013 00:35:36 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Fri, 22 Mar 2013 00:35:35 -0500
From: Andrew Allen 
To: Flemming Andreasen , Jonathan Lennox , "mohamed.boucadair@orange.com" , Hadriel Kaplan , "Atle Monrad" , "md3135@att.com" ,  "Stach Thomas" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJjm5B4s42L3aokaFCl3Xnh0SyJixCFEQ
Date: Fri, 22 Mar 2013 05:35:35 +0000
Message-ID: 
References: <5148049B.6090205@cisco.com>  <514B0DE4.3060501@cisco.com>
In-Reply-To: <514B0DE4.3060501@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA3VSbUgTYRznuTvP22xwLtMH+9C6iNKczTK5SCWt4MQgzU8GZed2bVfbbd1N afbFIMIMMrWlDk3L9WL0qtELZsNVkhbNskEujWJmSS1JiF6Jbl2BED2ffv+33+//f/gRqLYG TyZ4wcmJAmulcDWmXmdP15+NFBYb7g4vogPdrYCeHtbTbSNvYmlfZwCl/S9fx9LuM2GMvhOR 0aOZcYzed/E2slbFdDf24MxUXStgjn6/EsN8+xTEGa/3K8KMh54gzP7JQZy5PtiAMAcmx2KL VFuqQXY566ws4c3C8txsVhDsTtbJ6UycZMyhNnJm1qorEvlK1ujSreclo5XlbZxI6XhTDpVJ 6RxW1sjZOMGZQ7EOByeYqFy17p+XLbfxgo4TjHYTL5hzqIKSTXqaXrVan0Hl6rcfnGO5cS8U 4wgv2fOgtx+vBl8W1AIVAclMeC1wPEbBiXD4xSW8FqgJLdkFoK9nBFWCHgAHer1YtAsnU6Hv ThMSLSSQNxHY3PAciRZQcgccD7lBLSCIueQe2OeOi6YTSBe8XHsBV/AKODqq8GDkYrjv58Dv vIZkYOfAAFDE3AAe9rl/F1RkCvxwJoxGMZDX+zx0/o9WEgxNtCPK2iT03gqgCp4Hp8I//5yz EIb3H8KU/jTY0TuDK3gZPH3iHaoIx8PBlgnsCEj0zKL1zBrxzBrxzBrpANg5EG+zSIYsg1Ew pou8LV3gnN0gaq28pctvgMg07QckAag5mraJwmJtDFspuWx+AAmUStCUmuSUxsS6qjjRXiZW WDnJDzbI31KPJscZ7bJRBWfZSoPh/wGVpKl7VlCsJc2ymXZxnIMT//IghCqqo05OkGS/cCJb 4bSURS1YJskeTK4GrsT3b0d2tm0ubak317g78yKfkSWbTqlS753te3ASrcpI9Fvyy/PTgsda 2KHdfcMh7dWnwa2BsVcZF3LNP8rzho5Z+7elx21Pe/pxYq+uf1d8xNqR1F58zcPeD57wByWv 73DNevvHrNUp8z1zRUPzQ8Nk1+P8m02NkmpnOGuN4KcwycJmpKKixP4CkbS1x5sDAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 05:35:48 -0000

The offline discussion in Quebec agreed that CCAP should not be used to nego=
tiate between different IP addresses or between IPv4 and IPV6.  

CCAP was only to be used to negotiate between IN address type and PSTN addre=
ss type.

This is all 3GPP needs for CCAP as 3GPP specifications support use of ICE

I am in favor of improving the wording if it is not clear.

Andrew

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Thursday, March 21, 2013 9:41 AM
To: Jonathan Lennox; mohamed.boucadair@orange.com; Hadriel Kaplan; Atle Monr=
ad; md3135@att.com; Stach Thomas; Andrew Allen
Cc: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)

Can we get some more comments from people on this please. In particular, I w=
ould like to hear if people are against "ccap" being able to convey an IP-ad=
dress or not (if not, we can then debate the details of the restrictions aro=
und that separately) ?

Thanks

-- Flemming


On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
> I went through the discussion, and my reading is that there is agreement o=
n not allowing ccap to be used for alternative IP address negotiation.
>
> That could be made clear in the text e.g. by modifying the second sentence=
 Flemming quoted to read:
>
> 
>      The 'ccap' attribute MUST NOT be used to select
>      between different IP connection addresses (e.g. between
>      "IP4" and "IP6" address families or different IP addresses
>       within the same IP address family).
> 
>
> The ccap attribute should be able to carry either an IP or PSTN address; t=
hat way either a PSTN or an IP bearer could be offered as the highest priori=
ty configuration (in the "m=3D" line).  However, if we want to clarify the i=
ntended use of ccap, we could modify the first sentence to read:
>
> 
>     The 'ccap' capability attribute is intended for offering
>     alternative connection addresses where the 
>     is "IN" or "PSTN", i.e. selecting between an IP based
>     bearer or a circuit-switched bearer.
> 
>
> Simo
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
> Behalf Of ext Flemming Andreasen
> Sent: 19. maaliskuuta 2013 8:24
> To: mmusic
> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses 
> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Greetings
>
> As you may have seen, there has recently been some list discussion on 
> the "connection data capability" defined in
> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>
> To recap, the connection data capability ("ccap") provides capability nego=
tiation capabilities for what amounts to the "c=3D" line in regular SDP, and=
 as such enables negotiation of network type (such as "IN") and IP-address i=
nformation (v4 and v6 addresses). The Standards Track mechanism for negotiat=
ing and determining alternative IP-address information today is ICE, and hen=
ce the draft currently includes the following wording:
> 
> The 'ccap' capability attribute is intended to
>      be used only when there is no other mechanism available for
>      negotiating alternative connection address information, such as when
>      the  is different among the alternative addresses (e.g.
>      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>      situations where an existing mechanism (such as Interactive
>      Connectivity Establishment (ICE) [RFC5245]) can be used to select
>      between different connection addresses (e.g.  "IP4" and "IP6" or
>      different IP addresses within the same IP address family).
> 
>
> The above text has led to some confusion as to exactly when and what "ccap=
" can be used for. More specifically, is it/should it ever be allowed to use=
 "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances=
 ?
>
> If you have an opinion, please let us know.
>
> A couple of points to keep in mind:
> - The current document has been WGLC'ed without comment ~6 months ago.
> - 3GPP has a dependency on the document (however I'm not sure if that 
> dependency includes the above "IN" feature)
> - The connection data capability is defined in a general manner to be 
> generally useful in line with the overall capability negotiation 
> framework (as opposed to targeted at one specific use case with one 
> specific value)
> - There are scenarios where ICE cannot be used, even if implemented (e.g.=
 ice-mismatch).
> - RFC 6849 (media loopback) provides for NAT traversal in the absence 
> of ICE support
>
>
> Thanks
>
> -- Flemming
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=5793f8886f=aallen@blackberry.com  Thu Mar 21 22:36:01 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3687921F902E for ; Thu, 21 Mar 2013 22:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.343
X-Spam-Level: 
X-Spam-Status: No, score=-4.343 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396,  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 1twa8d8+0pmM for ; Thu, 21 Mar 2013 22:36:00 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0921F9030 for ; Thu, 21 Mar 2013 22:35:59 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-42-514bedbec41c
Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id D5.23.13213.EBDEB415; Fri, 22 Mar 2013 00:35:59 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Fri, 22 Mar 2013 00:35:58 -0500
From: Andrew Allen 
To: "Simo.Veikkolainen@nokia.com" , "fandreas@cisco.com" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJVFHm26zQKMoG0mBkvXJOa0PXZixDNgw
Date: Fri, 22 Mar 2013 05:35:56 +0000
Message-ID: 
References: <5148049B.6090205@cisco.com> 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXC5Zyvrbv/rXegwfVz7BbvL+haTF3+mMXi 3Ke7LA7MHlN+b2T1WLLkJ5PH3VuXmAKYoxoYbZISS8qCM9Pz9O1sEvPy8ksSS1IVUlKLk22V fFLTE3MUAooyyxKTKxVcMouTcxIzc1OLlBQyU2yVTJQUCnISk1NzU/NKbJUSCwpS81KU7LgU MIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWuoZKdbkInT8bERfcZC3YpVmw9tY2pgXGjdBcj J4eEgInEw58rGSFsMYkL99azdTFycQgJtDFJ9O07ygrhbGaUeNM5jw2kik1AS2L/4elMILaI wGRGiacHtUFsYYEKieUbLzFDxCsltp6cwAJhG0lsmHkVrJdFQFWia2ErWJxXwEPi/MQuVhBb SKBM4uacu+wgNqdAhMSV6X1gNqOArMTus9fBdjELiEvcejKfCeJSAYkle84zQ9iiEi8f/2OF sBUlHrd0s0DU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWj YG5GsYGZYXJesl5RZq5eXmrJJkZQinDUMNjB+P69xSFGAQ5GJR7e+kfegUKsiWXFlbmHGCU4 mJVEeCNTgEK8KYmVValF+fFFpTmpxYcYXYGhMpFZijs5H5i+8krijQ0McHOUxHn7b3gGCgmk A9NPdmpqQWoRzBwmDk6QPVxSIsXAJJJalFhakhEPSnXxxcBkJ9XAGNvyNjItPLv/l7nZ+3nP 41br/PBPZOwNeR1V7sTRuHvd/7refDHNp50l+wMf+11jXlAUJczU/uq42tdmbZNfj1sSJJbo /70qsPz88kc1/P7iW19/rUnUZJ+qySNTtybMPOuBjSHLkqJNkm8tuO+xhavniqwseRi5PHtn dOKms6nr54WEOlQosRRnJBpqMRcVJwIAFUiKNFIDAAA=
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 05:36:01 -0000

I am OK with either of these proposals

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Simo.Veikkolainen@nokia.com
Sent: Wednesday, March 20, 2013 5:57 AM
To: fandreas@cisco.com; mmusic@ietf.org
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)

I went through the discussion, and my reading is that there is agreement on=
 not allowing ccap to be used for alternative IP address negotiation.

That could be made clear in the text e.g. by modifying the second sentence F=
lemming quoted to read:


    The 'ccap' attribute MUST NOT be used to select
    between different IP connection addresses (e.g. between 
    "IP4" and "IP6" address families or different IP addresses 
     within the same IP address family).


The ccap attribute should be able to carry either an IP or PSTN address; tha=
t way either a PSTN or an IP bearer could be offered as the highest priority=
 configuration (in the "m=3D" line).  However, if we want to clarify the int=
ended use of ccap, we could modify the first sentence to read:


   The 'ccap' capability attribute is intended for offering
   alternative connection addresses where the 
   is "IN" or "PSTN", i.e. selecting between an IP based
   bearer or a circuit-switched bearer.


Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext Flemming Andreasen
Sent: 19. maaliskuuta 2013 8:24
To: mmusic
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-=
ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

As you may have seen, there has recently been some list discussion on the "c=
onnection data capability" defined in
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability negoti=
ation capabilities for what amounts to the "c=3D" line in regular SDP, and a=
s such enables negotiation of network type (such as "IN") and IP-address inf=
ormation (v4 and v6 addresses). The Standards Track mechanism for negotiatin=
g and determining alternative IP-address information today is ICE, and hence=
 the draft currently includes the following wording:

The 'ccap' capability attribute is intended to
    be used only when there is no other mechanism available for
    negotiating alternative connection address information, such as when
    the  is different among the alternative addresses (e.g.
    "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
    situations where an existing mechanism (such as Interactive
    Connectivity Establishment (ICE) [RFC5245]) can be used to select
    between different connection addresses (e.g.  "IP4" and "IP6" or
    different IP addresses within the same IP address family).


The above text has led to some confusion as to exactly when and what "ccap"=
 can be used for. More specifically, is it/should it ever be allowed to use=
 "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances=
 ?

If you have an opinion, please let us know.

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that depend=
ency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be genera=
lly useful in line with the overall capability negotiation framework (as opp=
osed to targeted at one specific use case with one specific value)
- There are scenarios where ICE cannot be used, even if implemented (e.g. ic=
e-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE=
 support


Thanks

-- Flemming

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=879345e0a2=aallen@blackberry.com  Thu Mar 21 22:36:01 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41C21F902E for ; Thu, 21 Mar 2013 22:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.664
X-Spam-Level: 
X-Spam-Status: No, score=-4.664 tagged_above=-999 required=5 tests=[AWL=0.539,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 kJVHoyKch5Ab for ; Thu, 21 Mar 2013 22:36:01 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E56721F9031 for ; Thu, 21 Mar 2013 22:36:00 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-43-514bedbfa680
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 26.23.13213.FBDEB415; Fri, 22 Mar 2013 00:35:59 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Fri, 22 Mar 2013 00:35:59 -0500
From: Andrew Allen 
To: Hadriel Kaplan 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJK0vVKS0PWIWhUmJ7t6klfo0spixDsKg
Date: Fri, 22 Mar 2013 05:35:58 +0000
Message-ID: 
References:  <6290145A-C58E-47A8-B36F-43D066724370@acmepacket.com>
In-Reply-To: <6290145A-C58E-47A8-B36F-43D066724370@acmepacket.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXC5Zyvpbv/rXegwYy3VhZzLz9nt5i6/DGL A5PHpsmb2TyWLPnJFMAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mjr27WUteMZecfvTE+YGxqlsXYycHBICJhL73vay Q9hiEhfurQeKc3EICbQxSZx6+IwRwtnMKPHg/VJmkCo2AS2J/YenM4HYIgLaEpcmbWUFsZkF DCSeP7rEAmILC1RILN94iRmiplJi68kJLBC2kcT21dOAejk4WARUJX6+0gQJ8wp4SOzYtocV YlcDo0TzpcNsIDWcAk4Sl48rgdQwCshK7D57nQlilbjErSfzmSCOFpBYsuc8M4QtKvHy8T9W CFtR4nFLNwtEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYx CuZmFBuYGSbnJesVZebq5aWWbGIEpQlHDYMdjO/fWxxiFOBgVOLhrX/kHSjEmlhWXJl7iFGC g1lJhDcyBSjEm5JYWZValB9fVJqTWnyI0RUYKBOZpbiT84EpLK8k3tjAADdHSZy3/4ZnoJBA OjApZaemFqQWwcxh4uAE2cMlJVIMTC2pRYmlJRnxoAQYXwxMgVINjII7Ghamboq/VR5sNMfm 67Z1Vo+NJ3AUT7d416767f3fmy8atm3VO1dcL1qyV9/LvuPM3/kfrq6Zv1Vv17Nts+VMG/3Z 6j/G7HAQC7v8R16bo0XukuwtkV2R229u2b1pxou5vxd3/DDeZGCddMlvzaq97n+fB/3giIo8 +5LJMkOv+XRNUXdP5xolluKMREMt5qLiRAAt1MXdVAMAAA==
Cc: "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 05:36:01 -0000

CCAP is currently only used by 3GPP to allow the UA to choose between PS and=
 CS for a terminating call at call setup when the UA has the possibility to=
 use either PS or CS for the call.

Mid call Handover PS to CS and CS to PS uses other techniques and does not i=
nvolve use of CCAP.

Andrew

-----Original Message-----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
Sent: Tuesday, March 19, 2013 10:22 AM
To: Andrew Allen
Cc: mmusic@ietf.org (E-mail)
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)


On Mar 19, 2013, at 8:27 AM, Andrew Allen  wrote:

> CCAP is the essential feature required by 3GPP. It is used by 3GPP to nego=
tiate the use of CS SDP to set up a CS call as an alternative to a packet sw=
itched audio stream.

Does it also need to be able to go from CS to IP sometime during a call, or=
 once it's chosen to be CS it stays CS?

-hadriel


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From harald@alvestrand.no  Fri Mar 22 00:33:32 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D221F9011 for ; Fri, 22 Mar 2013 00:33: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 0NDariP2ydFX for ; Fri, 22 Mar 2013 00:33:32 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF621F900F for ; Fri, 22 Mar 2013 00:33:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C65F339E04C for ; Fri, 22 Mar 2013 08:33:29 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPiI+pdgX7yN for ; Fri, 22 Mar 2013 08:33:29 +0100 (CET)
Received: from [83.145.61.131] (unknown [83.145.61.131]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EF69439E01E for ; Fri, 22 Mar 2013 08:33:28 +0100 (CET)
Message-ID: <514C0947.2010703@alvestrand.no>
Date: Fri, 22 Mar 2013 08:33:27 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: mmusic@ietf.org
References: <949EF20990823C4C85C18D59AA11AD8B016A9B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B016A9B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] RTP grouping taxonomy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 07:33:32 -0000

I was not in the room, and support having such a document. So add me as 
a +1.

On 03/15/2013 08:27 PM, DRAGE, Keith (Keith) wrote:
> (As AVTEXT cochair)
>
> In the joint session between AVTEXT and MMUSIC today we took a call in the room with substantial consensus in the room that there should be a document in some group in the RAI area that described the RTP grouping taxonomy.
>
> The RAI ADs will decide which group this should go to and therefore which list should be used for the discussion.
>
> This is a call to the membership of both the MMUSIC list and AVTEXT list to confirm that decision. If you were in the room you do not need to reply. Particularly if you do have objections please reply as soon as practicable at least to the appropriate chairs and the RAI ADs with your objections.
>
> In addition, if you want to contribute to Jonathan Lennox's document
>
> https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/
>
> directly then please do feel free to contact him for details on how to provide text. There will be at least another author version of this document before any call for adoption of the text.
>
> Regards
>
> Keith
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From magnus.westerlund@ericsson.com  Fri Mar 22 03:18:12 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43C21F9091 for ; Fri, 22 Mar 2013 03:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.832
X-Spam-Level: 
X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=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 fl7yK5kZurRe for ; Fri, 22 Mar 2013 03:18:11 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A383321F9058 for ; Fri, 22 Mar 2013 03:18:10 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-5e-514c2fe1280f
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.27.10459.1EF2C415; Fri, 22 Mar 2013 11:18:09 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 11:18:09 +0100
Message-ID: <514C2FE1.7060603@ericsson.com>
Date: Fri, 22 Mar 2013 11:18:09 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Paul Kyzivat 
References: <5149D1AA.4010805@ericsson.com> <5149E9E9.10900@alum.mit.edu> <514ADDB5.8040909@ericsson.com> <514B671D.70100@alum.mit.edu>
In-Reply-To: <514B671D.70100@alum.mit.edu>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvje5DfZ9Ag6OH9S2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj7fVDjAULRCs2L9/E1sC4WLCLkZNDQsBE 4vS7UywQtpjEhXvr2boYuTiEBE4ySrzv2MgC4SxnlHjwYA07SBWvgLbEp4crmEBsFgFViQ+/ 2hlBbDYBC4mbPxrZQGxRgWCJn6/OsEDUC0qcnPkEyObgEBHQkJi0VQ0kzCwgLHHh/HGwMcIC thLn/mxihtjVziix890WZpAEp4CWxORFb1khrpOU2PKinR2iWU9iytUWRghbXqJ562yweiGg 2xqaOlgnMArNQrJ6FpKWWUhaFjAyr2Jkz03MzEkvN9zECAzWg1t+6+5gPHVO5BCjNAeLkjhv mOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MQqci2WpL9bq+PtXq22omf/bbFEfD2uYt S/Nr8nt3nT49u7Rw8qvtUkaMvCb+c513ss5kjpcWNq5frX244KrNJFZllW1TecuD7yT5H5Io 5eYQPs1gtq+p9fWn9zEM2w6L9z55nWq74ppM34zqaQ6JAd9FeBW2q55dtePt3BPM/psuZJ+s WiaoxFKckWioxVxUnAgAnE3fpiQCAAA=
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 10:18:12 -0000

On 2013-03-21 21:01, Paul Kyzivat wrote:
> On 3/21/13 6:15 PM, Magnus Westerlund wrote:
>> On 2013-03-20 17:55, Paul Kyzivat wrote:
>>> While webrtc-webrtc may have an independent mechanism to work out the
>>> channel usage, that is certainly not so for sip-sip sessions.
>>>
>>> So I think "we" (CLUE) have a requirement to negotiate channel usage in
>>> SDP.
>>
>> Do you? Or it is sufficient to say
>>
>> m=application 12234 UDP/DTLS/SCTP CLUE
>>
>> Indicating that this SCTP association is using CLUEs defined way, not
>> WebRTC. I want to separate the usage of individual SCTP streams and the
>> general usage of the SCTP association.
> 
> Then what do we do for an WEBRTC client doing CLUE, talking to a native
> sip CLUE endpoint?
> 
> I guess clue could live with a mechanism that reserves the complete SCTP
> association, with all of its streams, as globally managed in a
> clue-specific way, as long as we can sort out the interop with webrtc.

What I understand you can't really in the general case sort out the
WebRTC interoperability. WebRTC is after all a JavaScript specific usage
of a generic bi-directional multi-channel data transmission. Where the
generic bi-directional paradigm is realized using RTCWEB defined data
protocol. Clue could reuse that basic scheme but it would not make it
clear about will be on specific channels, that can be explicit or
implicit and depends on the WebRTC application.

It might be that certain usages becomes standardized and that we can
agree on labeling them and interconnect them with other systems. Doest
that need to happen in SDP. Don't think so. What I think will be
happening is that when you like to connect to a CLUE system using a
WebRTC supporting browser then you deploy a CLUE speaking JS, that will
use the data channel in a CLUE agreed way requiring minimal translation.
In fact the only adaptation is likely that the PeerConnection peer must
be capable of accepting peerConnections and interconnect them with a
CLUE system. In such system I don't see the WebRTC endpoint indicating
that it is CLUE interoperable, it is the CLUE JS APP plus the WebRTC to
CLUE gateway that ensures that this works. No changes to the WebRTC browser.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Fri Mar 22 03:21:26 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028E421F90BA for ; Fri, 22 Mar 2013 03:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.116
X-Spam-Level: 
X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-Rg61-KE76b for ; Fri, 22 Mar 2013 03:21:25 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD721F9094 for ; Fri, 22 Mar 2013 03:21:24 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-df-514c30a3ec9a
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CD.BF.19728.3A03C415; Fri, 22 Mar 2013 11:21:23 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 11:21:23 +0100
Message-ID: <514C30A2.3070601@ericsson.com>
Date: Fri, 22 Mar 2013 11:21:22 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Harald Alvestrand 
References: <5149D1AA.4010805@ericsson.com> <514B09B3.9030903@alvestrand.no>
In-Reply-To: <514B09B3.9030903@alvestrand.no>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje5iA59Ag989ahZT3sxgtTjW18Vm MXX5YxYHZo8rE66weixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGScnnmAtOMdb8frgVdYG xh9cXYycHBICJhKv2p4zQ9hiEhfurWfrYuTiEBI4ySgxf2EfM4SznFHi/MUFYFW8AtoSC/41 sncxcnCwCKhKnDgqDxJmE7CQuPmjkQ3EFhUIlvj56gwLRLmgxMmZT8BsEQEdiYf7G5hAbGaB UIntK7YwgtjCAjkSly8uAosLCfhIbPnUzgpicwroSrxasIkV4jhJiS0v2tkhevUkplxtYYSw 5SWat85mhujVlmho6mCdwCg0C8nqWUhaZiFpWcDIvIqRPTcxMye93GgTIzB8D275rbqD8c45 kUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwzvjq6KSWFChdo+ZiPeUt w/Tjkw/81JoVZH7+3ZNSu4aeB8YrYjddSU7VvbKgecqs28vld5TNfca3Xdr5sdVU3hD+/Ktb l3Bs1PYsUq3fcUSL0+z1RtsZWm8ubGq9KpTtrTTzfVNa3Oq6hcLCeYwrQvfeCozZnFX84vJW 3/Pqe01TXH0VL7XsVWIpzkg01GIuKk4EACGebpktAgAA
Cc: draft-ietf-mmusic-sctp-sdp@tools.ietf.org, "mmusic \(E-mail\)" 
Subject: Re: [MMUSIC] Proto identifier: To UDP or not to UDP (Re: Review of draft-ietf-mmusic-sctp-sdp-03)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 10:21:26 -0000

On 2013-03-21 14:22, Harald Alvestrand wrote:
> One high level comment:
> 
> This series of comments points out that the purpose of the thing called
> "proto identifier" in SDP is not really well documented.
> 
> As far as I can tell, the requirement is that it uniquely identifies the
> parser one needs to use for the stuff under this m= line, and that is
> the sum total of the requirements on it - as we painfully learned with
> RTP/AVP, RTP/AVPF, SRTP/AVP and SRTP/AVPF, making detailed information
> about the parameters available via the "proto identifier" is not really
> a Good Idea.
> 
> I suggest we go for DTLS/SCTP, as specified in the document currently,
> and document that the lower layer used has to be identified from the
> elements inside the m= line block; if there is ICE, ICE can negotiate
> it; if there is only a port number, it's UDP; if there are more
> extensions to specify that the lower layer is LTE over pterodactyls, the
> identifier doesn't change.

I am fine with this and it is likely the most pragmatic choice. However,
the current draft is not clear on the lower layer at all. If it adds
this and makes it clear on the handling I don't see an issue. Especially
as what ICE provides may not be UDP at all.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From mary.ietf.barnes@gmail.com  Fri Mar 22 07:28:50 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222D021F8C48 for ; Fri, 22 Mar 2013 07:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.168
X-Spam-Level: 
X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKx-CzZ6Szrw for ; Fri, 22 Mar 2013 07:28:49 -0700 (PDT)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5A21F8503 for ; Fri, 22 Mar 2013 07:28:48 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id k4so850077qaq.12 for ; Fri, 22 Mar 2013 07:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Zn2OcB42OgFU7QT+TIiHEO+eV0ATR7E/c+7/FMQOeug=; b=T9ia5Xu4K1g0v822IKJEr2uNdWL2Fe97CQq7mRr97nfbROl/bqagoF7pjDnMpyVLIr 3b7rv9KQ+uC1FqFtzDGio5LgJMeKjmGpX0acZ7Pf7JUn89mw9CVuY+HoodRQUdGDllLR Bt73M+iYto2v7V829zJWrDAno8BOMrUWIEtahGZFKQlitkST1km/sv67g6bePLjxoy05 5caKX75cy4C3zwykoyG3pOX233/JsTNPAMyVyHtgmKiqz1FxVaEaNzymoDKtYvqzhmLX /PcKbanrOlSyK8dN0Nihn/itQ//s07UPaqzx4VmqXf9MzU0ej3StNvJbdQ6pfnSURSKT A8ug==
MIME-Version: 1.0
X-Received: by 10.49.87.40 with SMTP id u8mr776102qez.62.1363962528257; Fri, 22 Mar 2013 07:28:48 -0700 (PDT)
Received: by 10.49.94.166 with HTTP; Fri, 22 Mar 2013 07:28:48 -0700 (PDT)
In-Reply-To: <514C2FE1.7060603@ericsson.com>
References: <5149D1AA.4010805@ericsson.com> <5149E9E9.10900@alum.mit.edu> <514ADDB5.8040909@ericsson.com> <514B671D.70100@alum.mit.edu> <514C2FE1.7060603@ericsson.com>
Date: Fri, 22 Mar 2013 09:28:48 -0500
Message-ID: 
From: Mary Barnes 
To: Magnus Westerlund 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "mmusic@ietf.org" , Paul Kyzivat 
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 14:28:50 -0000

On Fri, Mar 22, 2013 at 5:18 AM, Magnus Westerlund
 wrote:
> On 2013-03-21 21:01, Paul Kyzivat wrote:
>> On 3/21/13 6:15 PM, Magnus Westerlund wrote:
>>> On 2013-03-20 17:55, Paul Kyzivat wrote:
>>>> While webrtc-webrtc may have an independent mechanism to work out the
>>>> channel usage, that is certainly not so for sip-sip sessions.
>>>>
>>>> So I think "we" (CLUE) have a requirement to negotiate channel usage i=
n
>>>> SDP.
>>>
>>> Do you? Or it is sufficient to say
>>>
>>> m=3Dapplication 12234 UDP/DTLS/SCTP CLUE
>>>
>>> Indicating that this SCTP association is using CLUEs defined way, not
>>> WebRTC. I want to separate the usage of individual SCTP streams and the
>>> general usage of the SCTP association.
>>
>> Then what do we do for an WEBRTC client doing CLUE, talking to a native
>> sip CLUE endpoint?
>>
>> I guess clue could live with a mechanism that reserves the complete SCTP
>> association, with all of its streams, as globally managed in a
>> clue-specific way, as long as we can sort out the interop with webrtc.
>
> What I understand you can't really in the general case sort out the
> WebRTC interoperability. WebRTC is after all a JavaScript specific usage
> of a generic bi-directional multi-channel data transmission. Where the
> generic bi-directional paradigm is realized using RTCWEB defined data
> protocol. Clue could reuse that basic scheme but it would not make it
> clear about will be on specific channels, that can be explicit or
> implicit and depends on the WebRTC application.
>
> It might be that certain usages becomes standardized and that we can
> agree on labeling them and interconnect them with other systems. Doest
> that need to happen in SDP. Don't think so. What I think will be
> happening is that when you like to connect to a CLUE system using a
> WebRTC supporting browser then you deploy a CLUE speaking JS, that will
> use the data channel in a CLUE agreed way requiring minimal translation.
> In fact the only adaptation is likely that the PeerConnection peer must
> be capable of accepting peerConnections and interconnect them with a
> CLUE system. In such system I don't see the WebRTC endpoint indicating
> that it is CLUE interoperable, it is the CLUE JS APP plus the WebRTC to
> CLUE gateway that ensures that this works. No changes to the WebRTC brows=
er.

[MB] This is exactly how I was anticipating it to work for the most
part.  CLUE is defining a data model and from that I believe we can
extract the data relevant to the CLUE JS APP. I also don't see how we
could do it without a gateway. [/MB]

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From radhika.r.roy.civ@mail.mil  Thu Mar 21 05:15:29 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63921F8D68; Thu, 21 Mar 2013 05:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 geeZEhyAaCLo; Thu, 21 Mar 2013 05:15:28 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA621F8D14; Thu, 21 Mar 2013 05:15:27 -0700 (PDT)
Received: from UCOLHP3O.easf.csd.disa.mil (131.64.100.154) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 21 Mar 2013 12:15:10 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.116]) by UCOLHP3O.easf.csd.disa.mil ([131.64.100.154]) with mapi id 14.02.0309.003; Thu, 21 Mar 2013 12:15:10 +0000
From: "Roy, Radhika R CIV USARMY (US)" 
To: Harald Alvestrand , "Mo Zanaty (mzanaty)" 
Thread-Topic: [rtcweb] [MMUSIC] Is bundle just a port override? (UNCLASSIFIED)
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXgAAE+TwAANTO+sAAPluaAAAAoBlA=
Date: Thu, 21 Mar 2013 12:15:10 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49A66ECD@ucolhp9b.easf.csd.disa.mil>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <5148E48A.4060202@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F695203@xmb-rcd-x14.cisco.com> <514AF881.4040209@alvestrand.no>
In-Reply-To: <514AF881.4040209@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01CE260C.300637E0"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 22 Mar 2013 08:46:07 -0700
Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] [rtcweb] Is bundle just a port override? (UNCLASSIFIED)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Mar 2013 12:15:29 -0000

------=_NextPart_000_000E_01CE260C.300637E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

So, it is ugly vs. uglier vs. ugliest ...

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Harald Alvestrand
Sent: Thursday, March 21, 2013 8:10 AM
To: Mo Zanaty (mzanaty)
Cc: rtcweb@ietf.org; mmusic@ietf.org
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

On 03/21/2013 06:59 AM, Mo Zanaty (mzanaty) wrote:
> Hi Harald,
>
> You're right, both are essentially groupings, and all of our wheels have
ugly angles. To me, the ugly angles in bundle are unnecessary indirection by
grouping with artificial bindings (mid), and that it pretends to be more
than it is. To me, it is just a port override, but with unnecessary
indirection. Why not just say the port you want to use directly?
>
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
>
> vs.
>
> a=group:BUNDLE foo bar
> m=audio 10000 RTP/AVP 0
> a=mid:foo
> m=video 10002 RTP/AVP 31
> a=mid:bar
>
> Why is the direct approach more complex? Why is ICE any different in
either approach?
You don't know the port you'll be using ahead of time with ICE; you have 
to put ICE into all the M-lines in order to be able to negotiate ICE 
when you don't get the bundling.

So in addition to specifying the port on the m= line, you have to uglify 
your solution by stating rules that say "if you accept this alternate 
port, you also have to accept these special rules for ICE", and all the 
other stuff that Christer uncovered and is documented in his draft.

And nothing that looks as the SDP without knowing the special semantics 
of bundle can know that the fact that a=port in those 2 M-lines implies 
special treatment of ICE.

It's a grouping framework. I don't want to create new grouping 
frameworks; the one we have is bad enough.

I think your angles will produce a bumpier ride than mine :-)

>
> Cheers,
> Mo
>

Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_000E_01CE260C.300637E0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN
MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww
CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE
SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9
ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V
hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR
9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV
lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9
eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh
eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js
L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL
CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB
BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku
Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth
LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN
AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E
wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF
NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp
8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh
iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw
DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM
MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x
MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu
IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk
BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm
b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd
Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma
9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u
rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD
VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny
bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc
MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y
9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v
RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud
EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5
ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU
AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ
G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/
VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O
vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF
eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5
uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ
MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow
XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww
CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ
s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4
zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY
zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf
VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G
A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU
uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG
A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC
AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs
oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB
AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U
Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC
hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul
M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl
cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3
i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW
LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y
U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz
SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5
eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg
Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMzAzMjExMjE1MDJaMCMGCSqGSIb3DQEJBDEWBBQ9DMvHY83ARJaVyKG9qzL/
/6gVejBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG
A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm
oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB
AQUABIIBADwlhnlHWZwc/IF1jel9NoTu1hbb7WzYKxjRwK5upnNH6mulcUixCwOFvRNRnfvvT0ai
RotOnzSL0z5Lwb9KibGJMVDXy8hTiSLeBSFHLzQpnlifEUw4vaA7rYbWxiMY1UeJM7PxuawqEV3e
h+IeEUTleqWrNaPyEF+7wqW1lbi0WOfIDWkAD4CceHEtY2tzYtj2BBcxDYykjyCZQOiqy+73KMKU
cAtNvDvBEBrEl7h6KGcj0E+I8vAkwm/Nm1Lqy7gfqCJoMlBVPj38/3CgiURU0CsuQYWWe4KiBmV2
yxxDto3h3xjc7VoGEGP7wN3mf/GdGsFqOMxxIcTcFXB/APYAAAAAAAA=

------=_NextPart_000_000E_01CE260C.300637E0--

From pkyzivat@alum.mit.edu  Fri Mar 22 08:58:33 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FD521F8D27 for ; Fri, 22 Mar 2013 08:58:31 -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.129,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_111=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 5TYFfPWDEk8T for ; Fri, 22 Mar 2013 08:58:30 -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 6AE7521F8CFA for ; Fri, 22 Mar 2013 08:58:30 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ebkd1l0050QuhwU51fyVjT; Fri, 22 Mar 2013 15:58:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id EfyU1l00R3ZTu2S3NfyVid; Fri, 22 Mar 2013 15:58:29 +0000
Message-ID: <514C7FA4.4060805@alum.mit.edu>
Date: Fri, 22 Mar 2013 23:58:28 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Mary Barnes 
References: <5149D1AA.4010805@ericsson.com> <5149E9E9.10900@alum.mit.edu> <514ADDB5.8040909@ericsson.com> <514B671D.70100@alum.mit.edu> <514C2FE1.7060603@ericsson.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=1363967909; bh=fMf56oaRxIrfwXS1uveObHp2ZV9xHIw6Fk8yIYoYxZw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pFSph01it2AHTdJXx0yOjgrYO8L1TfGEMW4bPsDs1r2dy4S28iCdBRzfFotYsdCJN k8FU2efNuHCA9t/38BpmXVp4vNZ912cuSOmnzyFBs9U8iDkQNAbGLqAdliNzGOs0gN +nnO5jtxi/g1czZzsT4SLtvCkJJDL2RI2MP0Ll8fLxpXMS4GMo5qF6eoEcB4IRjRzJ nAymVi5lpC9Wu7oJ5z+a6weqLY/BGvZ12xrUZnVoSf7X40Z4IHAQRLHlF+I+Xfr8v9 ghNtfET8vzb+E6RslEuKvwuScUGAyR8kdb2+vFHNgyRLCfyN7bsG3NLeHG/LVmSRkp JVR6GZ+cbsxag==
Cc: Magnus Westerlund , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 15:58:33 -0000

On 3/22/13 10:28 PM, Mary Barnes wrote:
> On Fri, Mar 22, 2013 at 5:18 AM, Magnus Westerlund
>  wrote:
>> On 2013-03-21 21:01, Paul Kyzivat wrote:
>>> On 3/21/13 6:15 PM, Magnus Westerlund wrote:
>>>> On 2013-03-20 17:55, Paul Kyzivat wrote:
>>>>> While webrtc-webrtc may have an independent mechanism to work out the
>>>>> channel usage, that is certainly not so for sip-sip sessions.
>>>>>
>>>>> So I think "we" (CLUE) have a requirement to negotiate channel usage in
>>>>> SDP.
>>>>
>>>> Do you? Or it is sufficient to say
>>>>
>>>> m=application 12234 UDP/DTLS/SCTP CLUE
>>>>
>>>> Indicating that this SCTP association is using CLUEs defined way, not
>>>> WebRTC. I want to separate the usage of individual SCTP streams and the
>>>> general usage of the SCTP association.
>>>
>>> Then what do we do for an WEBRTC client doing CLUE, talking to a native
>>> sip CLUE endpoint?
>>>
>>> I guess clue could live with a mechanism that reserves the complete SCTP
>>> association, with all of its streams, as globally managed in a
>>> clue-specific way, as long as we can sort out the interop with webrtc.
>>
>> What I understand you can't really in the general case sort out the
>> WebRTC interoperability. WebRTC is after all a JavaScript specific usage
>> of a generic bi-directional multi-channel data transmission. Where the
>> generic bi-directional paradigm is realized using RTCWEB defined data
>> protocol. Clue could reuse that basic scheme but it would not make it
>> clear about will be on specific channels, that can be explicit or
>> implicit and depends on the WebRTC application.
>>
>> It might be that certain usages becomes standardized and that we can
>> agree on labeling them and interconnect them with other systems. Doest
>> that need to happen in SDP. Don't think so. What I think will be
>> happening is that when you like to connect to a CLUE system using a
>> WebRTC supporting browser then you deploy a CLUE speaking JS, that will
>> use the data channel in a CLUE agreed way requiring minimal translation.
>> In fact the only adaptation is likely that the PeerConnection peer must
>> be capable of accepting peerConnections and interconnect them with a
>> CLUE system. In such system I don't see the WebRTC endpoint indicating
>> that it is CLUE interoperable, it is the CLUE JS APP plus the WebRTC to
>> CLUE gateway that ensures that this works. No changes to the WebRTC browser.
>
> [MB] This is exactly how I was anticipating it to work for the most
> part.  CLUE is defining a data model and from that I believe we can
> extract the data relevant to the CLUE JS APP. I also don't see how we
> could do it without a gateway. [/MB]

I'm not certain if I agree with my co-chair or not. :-)

I do agree that clue-specific JS must be delivered to the browser. And 
so this calls for a webserver that can do that and knows it should. And 
in the webrtc-sip case that means the webserver must serve as a 
signaling gateway for sip.

I don't think this requires that there be a signaling gateway for the 
clue protocol. It ought to be possible for the clue protocol to be 
direct between the browser and the sip-clue endpoint. That in turn means 
that the SCTP association setup and channel usage must be identical 
between the SIP UA and the browser. The webserver can of course adjust 
the JS to arrange that to be the case. I suppose it can arrange for the 
SCTP m-line to reference "clue" when talking to the sip server, while 
the SDP interface in the browser says "webrtc" for that.

This isn't the way I would *like* to be signaling SCTP usage in SIP/SDP, 
but I can live with it. Perhaps it is better to work on the taxonomy 
document before doing more. (I think we should at some point include 
SCTP associations and streams/channels in the taxonomy.)

	Thanks,
	Paul


From magnus.westerlund@ericsson.com  Fri Mar 22 09:03:39 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0185D21F8D8D for ; Fri, 22 Mar 2013 09:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.127
X-Spam-Level: 
X-Spam-Status: No, score=-106.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5Bjd2wuPK0n for ; Fri, 22 Mar 2013 09:03:38 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C721F8B7C for ; Fri, 22 Mar 2013 09:03:37 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-15-514c80d997d1
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BE.14.19728.9D08C415; Fri, 22 Mar 2013 17:03:37 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 17:03:37 +0100
Message-ID: <514C80D8.2030802@ericsson.com>
Date: Fri, 22 Mar 2013 17:03:36 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Dale R. Worley" 
References: <51425974.9070608@ericsson.com> <201303151431.r2FEVHJ9498642@shell01.TheWorld.com> <514767D1.3000906@ericsson.com> <201303191937.r2JJbEWO763574@shell01.TheWorld.com>
In-Reply-To: <201303191937.r2JJbEWO763574@shell01.TheWorld.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Rvdmg0+gwZ4tvBZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgymjsXcBWcE244tiFHvYGxjX8XYycHBICJhIr t81gh7DFJC7cW88GYgsJnGSU+DXREsJezijx76g8iM0roC0xf0MjWD2LgKrEuq/zmEBsNgEL iZs/GsF6RQWCJX6+OsMCUS8ocXLmEyCbg0NEQFOiY0EOSJhZQFjiwvnjYK3CAk4SH5bcAGrl Alq1kVHi/PRusASngL3EjZnNjBC3SUpsedHODtGsJzHlagsjhC0v0bx1NjPEndoSDU0drBMY hWYhWT0LScssJC0LGJlXMbLnJmbmpJcbbWIEhunBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb5c8IXE5/qVSyfUmf9QFOO6/Q+h3/PDm4OnmabNPfA RyadjKQuRy6jKy0fZ6gf27RkQUQJd/uHgi1mdjyCTYmh+n+rJmUfe79NamJR9uaHF55FpXzm bJm+9c8cbp09Nls2JB1Pb1Zqn9q/cs+TivVNnuH7P+5st72xI/z9C7XYo8ffFYe334tQYinO SDTUYi4qTgQAG8rkGCECAAA=
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:03:39 -0000

Dale,

Thanks for the input. I have tried to address your input in this version:

   This appendix describes how an SDP file determines the operation of
   an RTSP session.  Thus, it is worth pointing out that the
   interpretation of the SDP is done in the context of the SDP receiver,
   which is the one being configured.  This is the same as in SAP
   [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where the SDP
   describes what the agent providing the SDP is ready to receive and
   willing to send.

Cheers

Magnus

On 2013-03-19 20:37, Dale R. Worley wrote:
>> From: Magnus Westerlund 
>>
>> I thus propose a more generic version of your text in the D. section:
>>
>>    This appendix describes how an SDP file determines the operation of
>>    an RTSP session.  Thus, it is worth pointing out that the
>>    interpretation of the SDP is done in the context of the SDP receiver
>>    is the one being configured.  This is the same as in SAP [RFC2974],
>>    this differs from SDP Offer/Answer [RFC3264] where the SDP describes
>>    what the peer agent is ready to receive and willing to send.
> 
> I agree with the overall concept, but there are some edits that would
> help:
> 
> There's some flaw in the wording around "of the SDP receiver is the
> one".  Perhaps it was intended to be "... of the SDP receiver, which
> is the one being configured."?
> 
> Strictly, in "the same as in SAP [RFC2974],", the final "," should be
> ";", as the two things being joined are complete sentences.
> 
> The final clause does not seem definite enough to me, as "the peer
> agent" is used rather than "the agent sending the SDP".  I suppose
> that is the meaning that it must have, but in many situations, "the
> peer agent" is used to denote the agent at the *other end* of the
> connection from the agent being described.  So I would say "where the
> SDP describes what the agent sending it is ready to receive and
> willing to send."
> 
> Dale
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From internet-drafts@ietf.org  Fri Mar 22 09:03:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BC821F8E10; Fri, 22 Mar 2013 09:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level: 
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 pXCQvDlyFRLb; Fri, 22 Mar 2013 09:03:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7570421F8B7C; Fri, 22 Mar 2013 09:03:39 -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.43
Message-ID: <20130322160339.18189.47384.idtracker@ietfa.amsl.com>
Date: Fri, 22 Mar 2013 09:03:39 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-32.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:03:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Real Time Streaming Protocol 2.0 (RTSP)
	Author(s)       : Henning Schulzrinne
                          Anup Rao
                          Rob Lanphier
                          Magnus Westerlund
                          Martin Stiemerling
	Filename        : draft-ietf-mmusic-rfc2326bis-32.txt
	Pages           : 285
	Date            : 2013-03-22

Abstract:
   This memorandum defines RTSP version 2.0 which obsoletes RTSP version
   1.0 defined in RFC 2326.

   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for setup and control of the delivery of data with real-time
   properties.  RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video.  Sources of data can include both live data feeds and stored
   clips.  This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 3550).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-32

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-32


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


From magnus.westerlund@ericsson.com  Fri Mar 22 09:12:17 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272521F84B2 for ; Fri, 22 Mar 2013 09:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.135
X-Spam-Level: 
X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nGLsNt0X2mn for ; Fri, 22 Mar 2013 09:12:17 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15C21F84A8 for ; Fri, 22 Mar 2013 09:12:16 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-13-514c82de8709
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.60.32353.ED28C415; Fri, 22 Mar 2013 17:12:15 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 17:12:14 +0100
Message-ID: <514C82DE.9030303@ericsson.com>
Date: Fri, 22 Mar 2013 17:12:14 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "mmusic (E-mail)" 
References: <20130322160339.18189.47384.idtracker@ietfa.amsl.com>
In-Reply-To: <20130322160339.18189.47384.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje79Jp9Ag2VnuS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLf3lrIWHJeuuHduO1sD4zbRLkYODgkBE4n/Nyy7GDmBTDGJ C/fWs3UxcnEICZxklLg98R0rhLOcUeL8lw2MIFW8AtoSO26dZQexWQRUJZZPOMYGYrMJWEjc /NEIZosKBEv8fHWGBaJeUOLkzCdgtoiAukTr5j5WEFtYwEZiw8fTYHOEBBwlzj7eBjafU8BJ Ys/ZTywQF0lKbHnRDlbDLKAnMeVqCyOELS/RvHU2M0SvtkRDUwfrBEbBWUjWzULSMgtJywJG 5lWM7LmJmTnp5eabGIHhd3DLb4MdjJvuix1ilOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBMTdv3xHJAi/3+SxWX7oemTXkbDwfoHXu4LfJpak+hr9+HPP+Vr3rr87h1Htc Waf1T4mVFW4KcdxvHDit8v8pmy77YIXZRXfO/09z/BBib7+EtSHLYqHES4u/7ybWdCbn193c ddn4h/uuPfN55744lKn3MeLUSz2DPzcnBM1dPaXC/wkP96sl2kosxRmJhlrMRcWJAChQHj4N AgAA
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-32.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:12:17 -0000

WG,

This updates takes care of the last of some smaller issues that Flemming
noticed in his chair writeup review. This includes the issues I have
brought up on the mailing list.

The diff of the changes:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-32

A number of changes in this diff are due to the new XML2RFC tool. The
significant changes are:

Section 10.2 - above 1024 registered port.

Section C.1.2, C.1.3, C.2.2 - Clarifing usage of RTP/RTCP multiplexing.

Appendix D: SDP usage clarification, intro + D.1.5

I would note that this document has been bitten by bugs in the XML2RFC
tool. Two issues to be noted.

- The long line is due to hangtext not keeping within limits
- Some hangtext items without content has diseapeard in the MIME
registration.

Thus I will resubmit a version with the old XML tool to avoid these.

Cheers

Magnus

On 2013-03-22 17:03, 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 Multiparty Multimedia Session Control Working Group of the IETF.
> 
> 	Title           : Real Time Streaming Protocol 2.0 (RTSP)
> 	Author(s)       : Henning Schulzrinne
>                           Anup Rao
>                           Rob Lanphier
>                           Magnus Westerlund
>                           Martin Stiemerling
> 	Filename        : draft-ietf-mmusic-rfc2326bis-32.txt
> 	Pages           : 285
> 	Date            : 2013-03-22
> 
> Abstract:
>    This memorandum defines RTSP version 2.0 which obsoletes RTSP version
>    1.0 defined in RFC 2326.
> 
>    The Real Time Streaming Protocol, or RTSP, is an application-level
>    protocol for setup and control of the delivery of data with real-time
>    properties.  RTSP provides an extensible framework to enable
>    controlled, on-demand delivery of real-time data, such as audio and
>    video.  Sources of data can include both live data feeds and stored
>    clips.  This protocol is intended to control multiple data delivery
>    sessions, provide a means for choosing delivery channels such as UDP,
>    multicast UDP and TCP, and provide a means for choosing delivery
>    mechanisms based upon RTP (RFC 3550).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-32
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-32
> 
> 
> 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
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From internet-drafts@ietf.org  Fri Mar 22 09:21:35 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F99821F8E6B; Fri, 22 Mar 2013 09:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level: 
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, 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 SxDV5rAXNPqk; Fri, 22 Mar 2013 09:21:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5121F8DE5; Fri, 22 Mar 2013 09:21:34 -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.43
Message-ID: <20130322162134.14348.58258.idtracker@ietfa.amsl.com>
Date: Fri, 22 Mar 2013 09:21:34 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-33.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:21:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Real Time Streaming Protocol 2.0 (RTSP)
	Author(s)       : Henning Schulzrinne
                          Anup Rao
                          Rob Lanphier
                          Magnus Westerlund
                          Martin Stiemerling
	Filename        : draft-ietf-mmusic-rfc2326bis-33.txt
	Pages           : 302
	Date            : 2013-03-22

Abstract:
   This memorandum defines RTSP version 2.0 which obsoletes RTSP version
   1.0 defined in RFC 2326.

   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for setup and control of the delivery of data with real-time
   properties.  RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video.  Sources of data can include both live data feeds and stored
   clips.  This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 3550).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-33

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-33


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


From magnus.westerlund@ericsson.com  Fri Mar 22 09:23:36 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBB21F851C for ; Fri, 22 Mar 2013 09:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.143
X-Spam-Level: 
X-Spam-Status: No, score=-106.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwnWSl1lsaNS for ; Fri, 22 Mar 2013 09:23:34 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 14D8D21F85CE for ; Fri, 22 Mar 2013 09:23:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-c7-514c85815532
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CA.A1.32353.1858C415; Fri, 22 Mar 2013 17:23:29 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 22 Mar 2013 17:23:28 +0100
Message-ID: <514C8580.9050001@ericsson.com>
Date: Fri, 22 Mar 2013 17:23:28 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "mmusic (E-mail)" 
References: <20130322162134.14348.58258.idtracker@ietfa.amsl.com>
In-Reply-To: <20130322162134.14348.58258.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+JvjW5jq0+gwb1+JYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY8a1qoLJYhWPrl9jbmBsF+xi5OSQEDCROPGwnR3CFpO4cG89 WxcjF4eQwElGid0nrrFAOMsZJV6ff8XaxcjBwSugLXHuoj6IySKgKtGxRBGkl03AQuLmj0Y2 EFtUIFji56szLCA2r4CgxMmZT8BsEQF1idbNfawgtrCAjcSuL1PB9goJOEqcu7wezOYUcJK4 +2MGI8Q9khJbXkDcxiygJzHlagsjhC0v0bx1NjNEr7ZEQ1MH6wRGwVlI1s1C0jILScsCRuZV jOy5iZk56eXmmxiBoXdwy2+DHYyb7osdYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgTFh4b6darPEjFtWP/9TI6b3QuLGjbn2R+7Ov6myi9/3Z5eE5FmvrL87D3QdXLlU LFHe4srveQl3qj62sfgWHm+5Vp6X9yCKgU3os17R+pnLchL8Tpmdnn97S9WbJy6qU5e+/DDt 9Ks/obZRoX/1onmf7tQWVnZ5yv7kj9fHa9ml/164TX72LDBaiaU4I9FQi7moOBEAOic3VwsC AAA=
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-33.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 16:23:36 -0000

WG,

This is a version produced by the old XML2RFC tool. No other changes
then the version number.

Please note that it becomes 17 pages longer with the old tool.

Have a nice weekend

Magnus

On 2013-03-22 17:21, 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 Multiparty Multimedia Session Control Working Group of the IETF.
> 
> 	Title           : Real Time Streaming Protocol 2.0 (RTSP)
> 	Author(s)       : Henning Schulzrinne
>                           Anup Rao
>                           Rob Lanphier
>                           Magnus Westerlund
>                           Martin Stiemerling
> 	Filename        : draft-ietf-mmusic-rfc2326bis-33.txt
> 	Pages           : 302
> 	Date            : 2013-03-22
> 
> Abstract:
>    This memorandum defines RTSP version 2.0 which obsoletes RTSP version
>    1.0 defined in RFC 2326.
> 
>    The Real Time Streaming Protocol, or RTSP, is an application-level
>    protocol for setup and control of the delivery of data with real-time
>    properties.  RTSP provides an extensible framework to enable
>    controlled, on-demand delivery of real-time data, such as audio and
>    video.  Sources of data can include both live data feeds and stored
>    clips.  This protocol is intended to control multiple data delivery
>    sessions, provide a means for choosing delivery channels such as UDP,
>    multicast UDP and TCP, and provide a means for choosing delivery
>    mechanisms based upon RTP (RFC 3550).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-33
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-33
> 
> 
> 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
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From fandreas@cisco.com  Fri Mar 22 11:37:22 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2414C21F8440 for ; Fri, 22 Mar 2013 11:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.463
X-Spam-Level: 
X-Spam-Status: No, score=-9.463 tagged_above=-999 required=5 tests=[AWL=0.536,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 h9obCWl7U3Uq for ; Fri, 22 Mar 2013 11:37:21 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D64CC21F843F for ; Fri, 22 Mar 2013 11:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6083; q=dns/txt; s=iport; t=1363977441; x=1365187041; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ca/+8adWW4UI+Wes3epQv4z5Gx0In5ZxplGNpIaiSE0=; b=SHozMnr3YMbLZwOxWnAAo6aUbKZUS/dLia5jyglDKBwqNjIdUiAeaqgG SclLB7Zq4vyia9hd896RK/KtFE32J+PXNTnpX6Y+mwUJkSw1beLxjwREK RHLKaGcokEt+h15RM1cRW1cS/fvOE8EuQk2x2nxylOMCni4tQKmKDz/Wj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACSjTFGtJV2c/2dsb2JhbABDxVSBZRZ0giQBAQEEAQEBNTYLDAQLDgMEAQEBCRoEBw8CFh8JCAYNAQUCAQEFiAsMwhmNYoElCwcGgzoDlmSRBIFUgVIggTc
X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208";a="190476544"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Mar 2013 18:37:20 +0000
Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2MIbJMQ020323;  Fri, 22 Mar 2013 18:37:19 GMT
Message-ID: <514CA4E1.50006@cisco.com>
Date: Fri, 22 Mar 2013 14:37:21 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Andrew Allen 
References: <5148049B.6090205@cisco.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 18:37:22 -0000

Still waiting for more comments on this, especially from the people that 
were very vocal in their complaints previously: Now is the time to speak up.

Regardless, a few comments on the below:
1) It allows the use of "ccap" to be used to indicate one or more "IP4" 
addresses in a given SDP.
2) It allows the use of "ccap" to be used to indicate one or more "IP6" 
addresses in a given SDP.

Nit-picking a bit on the actual text, which I think is important:
The "ccap" attribute is not what is being to select between different 
IP-addresses; the use of a "ccap" attribute in a potential configuration 
("pcfg") is what is being used for this. Is the restriction that we want 
here:
a) A potential configuration MUST NOT reference more than one "ccap" 
attribute with a network type of "IN" ?
b) All potential configurations for a particular media description MUST 
NOT reference more than one "ccap" attribute with a network type of "IN" ?
c) Something else ?

Thanks

-- Flemming



On 3/22/13 1:35 AM, Andrew Allen wrote:
> I am OK with either of these proposals
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com
> Sent: Wednesday, March 20, 2013 5:57 AM
> To: fandreas@cisco.com; mmusic@ietf.org
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation.
>
> That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read:
>
> 
>      The 'ccap' attribute MUST NOT be used to select
>      between different IP connection addresses (e.g. between
>      "IP4" and "IP6" address families or different IP addresses
>       within the same IP address family).
> 
>
> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:
>
> 
>     The 'ccap' capability attribute is intended for offering
>     alternative connection addresses where the 
>     is "IN" or "PSTN", i.e. selecting between an IP based
>     bearer or a circuit-switched bearer.
> 
>
> Simo
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
> Sent: 19. maaliskuuta 2013 8:24
> To: mmusic
> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Greetings
>
> As you may have seen, there has recently been some list discussion on the "connection data capability" defined in
> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>
> To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording:
> 
> The 'ccap' capability attribute is intended to
>      be used only when there is no other mechanism available for
>      negotiating alternative connection address information, such as when
>      the  is different among the alternative addresses (e.g.
>      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>      situations where an existing mechanism (such as Interactive
>      Connectivity Establishment (ICE) [RFC5245]) can be used to select
>      between different connection addresses (e.g.  "IP4" and "IP6" or
>      different IP addresses within the same IP address family).
> 
>
> The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ?
>
> If you have an opinion, please let us know.
>
> A couple of points to keep in mind:
> - The current document has been WGLC'ed without comment ~6 months ago.
> - 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature)
> - The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value)
> - There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch).
> - RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support
>
>
> Thanks
>
> -- Flemming
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> .
>


From worley@shell01.TheWorld.com  Fri Mar 22 12:28:02 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9921F8E83 for ; Fri, 22 Mar 2013 12:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.927
X-Spam-Level: 
X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 rywpT1TVXHpp for ; Fri, 22 Mar 2013 12:28:02 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44E21F8E11 for ; Fri, 22 Mar 2013 12:28:02 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2MJRsjS026056 for ; Fri, 22 Mar 2013 15:27:56 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2MJRrAg957402 for ; Fri, 22 Mar 2013 14:27:54 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2MJRrmL957691; Fri, 22 Mar 2013 15:27:53 -0400 (EDT)
Date: Fri, 22 Mar 2013 15:27:53 -0400 (EDT)
Message-Id: <201303221927.r2MJRrmL957691@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
In-reply-to: <514C0947.2010703@alvestrand.no> (harald@alvestrand.no)
References: <949EF20990823C4C85C18D59AA11AD8B016A9B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <514C0947.2010703@alvestrand.no>
Subject: Re: [MMUSIC] RTP grouping taxonomy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 19:28:02 -0000

On 03/15/2013 08:27 PM, DRAGE, Keith (Keith) wrote:
> (As AVTEXT cochair)
>
> In the joint session between AVTEXT and MMUSIC today we took a call
> in the room with substantial consensus in the room that there should
> be a document in some group in the RAI area that described the RTP
> grouping taxonomy.

> This is a call to the membership of both the MMUSIC list and AVTEXT
> list to confirm that decision. If you were in the room you do not
> need to reply. Particularly if you do have objections please reply
> as soon as practicable at least to the appropriate chairs and the
> RAI ADs with your objections.

We *definitely* need such a document, because major RFCs in these
areas use the terminology inconsistently, in ways that confuse
technical discussions.

Dale

From worley@shell01.TheWorld.com  Fri Mar 22 12:29:05 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38DA21F900E for ; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level: 
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 pCE8fUR1Y9vb for ; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB221F8FDD for ; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2MJShWs016761; Fri, 22 Mar 2013 15:28:46 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2MJShVW956659; Fri, 22 Mar 2013 14:28:43 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2MJShtu960817; Fri, 22 Mar 2013 15:28:43 -0400 (EDT)
Date: Fri, 22 Mar 2013 15:28:43 -0400 (EDT)
Message-Id: <201303221928.r2MJShtu960817@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "Mo Zanaty (mzanaty)" 
In-reply-to: <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com> (mzanaty@cisco.com)
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
Cc: rtcweb@ietf.org, mmusic@ietf.org
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 19:29:06 -0000

> From: "Mo Zanaty (mzanaty)" 
> 
> Your bundle alternatives (and Richard's) also work fine with a simple
> attribute without complex grouping semantics.
> 
> Offer to mux audio and video on the same port:
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
> i=I really want 10000, but lied on the m-line for fear of confusing
>     you. Confused yet?
>  
> Answer supports the port override attribute and agrees to mux audio and video:
> m=audio 40000 RTP/AVP 0
> m=video 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
> a=port 40000
> ...so audio and video ports are 10000<->40000.

Well, the analysis depends on exactly how "a=port" works.

Option 1A:  "a=port" specifies the port number for the packets.

The difficulty with this is that, at the time the offer is made, we
don't actually know what port number (or IP address) will be used,
because (commonly) ICE will be used to negotiate the transport
association, and "a=port" doesn't provide any way to specify ICE
candidates.

Worse, we don't want the video m= line to have perform an ICE
negotiation regarding "port 40000", we want the video m= line to
utilize the *same* ICE negotiation that the audio m= line will have.

So what we really want "a=port" to do is:

Option 1B:  "a=port" is a pointer to another media description, and the
packets from this media description will be multiplexed on the
transport association for the other media description.

That is, it's an indirection mechanism.  The question is how to
organize the indirection?  And the most pleasant choice is to use the
grouping mechanism that we already have.

Once we've decided that media descriptions should have a pointer to
another media description that will carry its packets if bundling is
negotiated, there are two main choices:

Option 2A:  One of the constituent media descriptions, the "master",
will be used to carry the bundled media.

Option 2B:  There is a separate "bundle" media description that
describes the bundled media.

2B has the advantage that it allows presenting an SDP description for
the bundle transport flow *as a whole*, while still presenting an SDP
description for each of the constituent media descriptions.  Otherwise
it becomes difficult to, for instance, specify the bandwidth or QoS of
the "master" constituent media flow independently of the bandwidth or
QoS of the entire bundle media flow.

Dale

From worley@shell01.TheWorld.com  Fri Mar 22 12:29:06 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4858F21F8FDD for ; Fri, 22 Mar 2013 12:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.832
X-Spam-Level: 
X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 p7minxtc7hvE for ; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4734221F8E11 for ; Fri, 22 Mar 2013 12:29:05 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2MJSOTe016105; Fri, 22 Mar 2013 15:28:26 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2MJSOht960277; Fri, 22 Mar 2013 14:28:24 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2MJSOvW960763; Fri, 22 Mar 2013 15:28:24 -0400 (EDT)
Date: Fri, 22 Mar 2013 15:28:24 -0400 (EDT)
Message-Id: <201303221928.r2MJSOvW960763@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "Mo Zanaty (mzanaty)" 
In-reply-to: <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com> (mzanaty@cisco.com)
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>  <3879D71E758A7E4AA99A35DD8D41D3D90F695235@xmb-rcd-x14.cisco.com>
Cc: rtcweb@ietf.org, mmusic@ietf.org
Subject: Re: [MMUSIC] [rtcweb]  Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 19:29:06 -0000

> From: "Mo Zanaty (mzanaty)" 
> 
> BTW, has anyone actually observed failures?

My memory is that Cullen Jennings knows of a significant installed
base of SBCs that choke on SDP that contains duplicated port
references.

Dale

From jonathan@vidyo.com  Fri Mar 22 13:00:26 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CA221F9371 for ; Fri, 22 Mar 2013 13:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_42=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 gZcqPPxihdgM for ; Fri, 22 Mar 2013 13:00:24 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B521F9365 for ; Fri, 22 Mar 2013 13:00:24 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2A94E7A5A2B; Fri, 22 Mar 2013 15:31:46 -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 492377A59FD; Fri, 22 Mar 2013 15:31:45 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Fri, 22 Mar 2013 15:59:43 -0400
From: Jonathan Lennox 
To: Flemming Andreasen 
Date: Fri, 22 Mar 2013 16:00:22 -0400
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: Ac4nN+KLtohQNzF8QJq+4t1yVTiI4A==
Message-ID: 
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com>
In-Reply-To: <514CA4E1.50006@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Mar 2013 20:00:26 -0000

Currently, the deployed SIP world has three mechanisms to allow some flavor=
 of negotiation among multiple IP addresses: ICE, altc (despite the general=
 disapproval of the working group), and ANAT (despite its deprecation).

I think that adding ccap as a fourth member of this set would be a terrible=
 idea; and as far as I can tell, no one wants to do that.  So we need to ma=
ke it clear that that it MUST NOT be used for that purpose.

In the formulation below, I think I'd say that a given media description MU=
ST NOT indicate more than one address with an IN network type, across all i=
ts configurations (actual and potential).

Obviously, different media descriptions (m=3D line blocks) can have differe=
nt addresses.

In practice, given the port number issue that started this thread, I suspec=
t this means that the SDP offer will need to put the IN address in the actu=
al configuration (in the c=3D line), and the PSTN address(es) will be in th=
e potential configurations.

On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:

> Still waiting for more comments on this, especially from the people that=
=20
> were very vocal in their complaints previously: Now is the time to speak =
up.
>=20
> Regardless, a few comments on the below:
> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"=20
> addresses in a given SDP.
> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"=20
> addresses in a given SDP.
>=20
> Nit-picking a bit on the actual text, which I think is important:
> The "ccap" attribute is not what is being to select between different=20
> IP-addresses; the use of a "ccap" attribute in a potential configuration=
=20
> ("pcfg") is what is being used for this. Is the restriction that we want=
=20
> here:
> a) A potential configuration MUST NOT reference more than one "ccap"=20
> attribute with a network type of "IN" ?
> b) All potential configurations for a particular media description MUST=20
> NOT reference more than one "ccap" attribute with a network type of "IN" =
?
> c) Something else ?
>=20
> Thanks
>=20
> -- Flemming
>=20
>=20
>=20
> On 3/22/13 1:35 AM, Andrew Allen wrote:
>> I am OK with either of these proposals
>>=20
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of Simo.Veikkolainen@nokia.com
>> Sent: Wednesday, March 20, 2013 5:57 AM
>> To: fandreas@cisco.com; mmusic@ietf.org
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses=
 (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>=20
>> I went through the discussion, and my reading is that there is agreement=
 on not allowing ccap to be used for alternative IP address negotiation.
>>=20
>> That could be made clear in the text e.g. by modifying the second senten=
ce Flemming quoted to read:
>>=20
>> 
>>     The 'ccap' attribute MUST NOT be used to select
>>     between different IP connection addresses (e.g. between
>>     "IP4" and "IP6" address families or different IP addresses
>>      within the same IP address family).
>> 
>>=20
>> The ccap attribute should be able to carry either an IP or PSTN address;=
 that way either a PSTN or an IP bearer could be offered as the highest pri=
ority configuration (in the "m=3D" line).  However, if we want to clarify t=
he intended use of ccap, we could modify the first sentence to read:
>>=20
>> 
>>    The 'ccap' capability attribute is intended for offering
>>    alternative connection addresses where the 
>>    is "IN" or "PSTN", i.e. selecting between an IP based
>>    bearer or a circuit-switched bearer.
>> 
>>=20
>> Simo
>>=20
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of ext Flemming Andreasen
>> Sent: 19. maaliskuuta 2013 8:24
>> To: mmusic
>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>=20
>> Greetings
>>=20
>> As you may have seen, there has recently been some list discussion on th=
e "connection data capability" defined in
>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>=20
>> To recap, the connection data capability ("ccap") provides capability ne=
gotiation capabilities for what amounts to the "c=3D" line in regular SDP, =
and as such enables negotiation of network type (such as "IN") and IP-addre=
ss information (v4 and v6 addresses). The Standards Track mechanism for neg=
otiating and determining alternative IP-address information today is ICE, a=
nd hence the draft currently includes the following wording:
>> 
>> The 'ccap' capability attribute is intended to
>>     be used only when there is no other mechanism available for
>>     negotiating alternative connection address information, such as when
>>     the  is different among the alternative addresses (e.g.
>>     "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>     situations where an existing mechanism (such as Interactive
>>     Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>     between different connection addresses (e.g.  "IP4" and "IP6" or
>>     different IP addresses within the same IP address family).
>> 
>>=20
>> The above text has led to some confusion as to exactly when and what "cc=
ap" can be used for. More specifically, is it/should it ever be allowed to =
use "ccap" to convey an IP4 or IP6 address, and if so, under what circumsta=
nces ?
>>=20
>> If you have an opinion, please let us know.
>>=20
>> A couple of points to keep in mind:
>> - The current document has been WGLC'ed without comment ~6 months ago.
>> - 3GPP has a dependency on the document (however I'm not sure if that de=
pendency includes the above "IN" feature)
>> - The connection data capability is defined in a general manner to be ge=
nerally useful in line with the overall capability negotiation framework (a=
s opposed to targeted at one specific use case with one specific value)
>> - There are scenarios where ICE cannot be used, even if implemented (e.g=
. ice-mismatch).
>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of=
 ICE support
>>=20
>>=20
>> Thanks
>>=20
>> -- Flemming
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>=20
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential i=
nformation, privileged material (including material protected by the solici=
tor-client or other applicable privileges), or constitute non-public inform=
ation. Any use of this information by anyone other than the intended recipi=
ent is prohibited. If you have received this transmission in error, please =
immediately reply to the sender and delete this information from your syste=
m. Use, dissemination, distribution, or reproduction of this transmission b=
y unintended recipients is not authorized and may be unlawful.
>> .
>>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20

--
Jonathan Lennox
jonathan@vidyo.com



From christer.holmberg@ericsson.com  Sat Mar 23 02:24:18 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEFF21F897A for ; Sat, 23 Mar 2013 02:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.066
X-Spam-Level: 
X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn18XCqVy1-R for ; Sat, 23 Mar 2013 02:24:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7B08821F8941 for ; Sat, 23 Mar 2013 02:24:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-9d-514d74bf027d
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FA.52.19728.FB47D415; Sat, 23 Mar 2013 10:24:15 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Sat, 23 Mar 2013 10:24:14 +0100
From: Christer Holmberg 
To: Jonathan Lennox , Flemming Andreasen 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJzfqZ2oNg1/uCU+2HPG3Sb7enZizAVaD
Date: Sat, 23 Mar 2013 09:24:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B132443@ESESSMB209.ericsson.se>
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje7+Et9Ag7f3VSzeX9C12L/4PLPF 1OWPWRyYPab83sjqsWTJTyaPtmd32AOYo7hsUlJzMstSi/TtErgy1h/uYi7Y71gx+4xZA+Nc 0y5GDg4JAROJ9b8Suhg5gUwxiQv31rN1MXJxCAkcYpQ49fEcI4SzmFFizdbdbCANbAIWEt3/ tEFMEYFgiWsNXiAms4C6xNXFQSBjhAUqJFo3rWMGsUUEKiUOT2hlgbCNJK60v2cGKWcRUJW4 dlkCJMwr4C2x8Ml6dohFzUwSB462sIEkOAVsJd7cPgI2hxHotO+n1jCB2MwC4hK3nsxngjhZ QGLJnvPMELaoxMvH/1ghbEWJj6/2MULU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRUje25iZk56udEmRmC0HNzyW3UH451zIocYpTlYlMR5w10vBAgJpCeW pGanphakFsUXleakFh9iZOLglGpgXHc7dpP5Q7a9PwQurEv7uZxhUoOpQNXB1e/uTOaaXl9Y YFKun9b+KI2Vb9ohg5Ntcxj992q9lGvdKKfT3GPMLsOly8br6GV6yiN/p7DXednbb5dknu0/ YVQ98eckVzUjtQt75Rqyr/2sFlHh6VR51JPQvm5SllxW4zIun/PB69uP/q5Ms7ugxFKckWio xVxUnAgAV8QEqGQCAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Mar 2013 09:24:18 -0000

Hi,

In general I agree that having multiple ways of doing the same thing is not=
 a good thing, and I don't have any strong feelings regarding the ccap usag=
e.

But, no matter what we say, what would actually prevent people from using c=
cap, in the same way they are using ANAT and altc? :)

Regards,

Christer


________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jonath=
an Lennox [jonathan@vidyo.com]
Sent: Friday, 22 March 2013 10:00 PM
To: Flemming Andreasen
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-addresse=
s    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Currently, the deployed SIP world has three mechanisms to allow some flavor=
 of negotiation among multiple IP addresses: ICE, altc (despite the general=
 disapproval of the working group), and ANAT (despite its deprecation).

I think that adding ccap as a fourth member of this set would be a terrible=
 idea; and as far as I can tell, no one wants to do that.  So we need to ma=
ke it clear that that it MUST NOT be used for that purpose.

In the formulation below, I think I'd say that a given media description MU=
ST NOT indicate more than one address with an IN network type, across all i=
ts configurations (actual and potential).

Obviously, different media descriptions (m=3D line blocks) can have differe=
nt addresses.

In practice, given the port number issue that started this thread, I suspec=
t this means that the SDP offer will need to put the IN address in the actu=
al configuration (in the c=3D line), and the PSTN address(es) will be in th=
e potential configurations.

On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:

> Still waiting for more comments on this, especially from the people that
> were very vocal in their complaints previously: Now is the time to speak =
up.
>
> Regardless, a few comments on the below:
> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"
> addresses in a given SDP.
> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"
> addresses in a given SDP.
>
> Nit-picking a bit on the actual text, which I think is important:
> The "ccap" attribute is not what is being to select between different
> IP-addresses; the use of a "ccap" attribute in a potential configuration
> ("pcfg") is what is being used for this. Is the restriction that we want
> here:
> a) A potential configuration MUST NOT reference more than one "ccap"
> attribute with a network type of "IN" ?
> b) All potential configurations for a particular media description MUST
> NOT reference more than one "ccap" attribute with a network type of "IN" =
?
> c) Something else ?
>
> Thanks
>
> -- Flemming
>
>
>
> On 3/22/13 1:35 AM, Andrew Allen wrote:
>> I am OK with either of these proposals
>>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of Simo.Veikkolainen@nokia.com
>> Sent: Wednesday, March 20, 2013 5:57 AM
>> To: fandreas@cisco.com; mmusic@ietf.org
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses=
 (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>> I went through the discussion, and my reading is that there is agreement=
 on not allowing ccap to be used for alternative IP address negotiation.
>>
>> That could be made clear in the text e.g. by modifying the second senten=
ce Flemming quoted to read:
>>
>> 
>>     The 'ccap' attribute MUST NOT be used to select
>>     between different IP connection addresses (e.g. between
>>     "IP4" and "IP6" address families or different IP addresses
>>      within the same IP address family).
>> 
>>
>> The ccap attribute should be able to carry either an IP or PSTN address;=
 that way either a PSTN or an IP bearer could be offered as the highest pri=
ority configuration (in the "m=3D" line).  However, if we want to clarify t=
he intended use of ccap, we could modify the first sentence to read:
>>
>> 
>>    The 'ccap' capability attribute is intended for offering
>>    alternative connection addresses where the 
>>    is "IN" or "PSTN", i.e. selecting between an IP based
>>    bearer or a circuit-switched bearer.
>> 
>>
>> Simo
>>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of ext Flemming Andreasen
>> Sent: 19. maaliskuuta 2013 8:24
>> To: mmusic
>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>> Greetings
>>
>> As you may have seen, there has recently been some list discussion on th=
e "connection data capability" defined in
>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>
>> To recap, the connection data capability ("ccap") provides capability ne=
gotiation capabilities for what amounts to the "c=3D" line in regular SDP, =
and as such enables negotiation of network type (such as "IN") and IP-addre=
ss information (v4 and v6 addresses). The Standards Track mechanism for neg=
otiating and determining alternative IP-address information today is ICE, a=
nd hence the draft currently includes the following wording:
>> 
>> The 'ccap' capability attribute is intended to
>>     be used only when there is no other mechanism available for
>>     negotiating alternative connection address information, such as when
>>     the  is different among the alternative addresses (e.g.
>>     "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>     situations where an existing mechanism (such as Interactive
>>     Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>     between different connection addresses (e.g.  "IP4" and "IP6" or
>>     different IP addresses within the same IP address family).
>> 
>>
>> The above text has led to some confusion as to exactly when and what "cc=
ap" can be used for. More specifically, is it/should it ever be allowed to =
use "ccap" to convey an IP4 or IP6 address, and if so, under what circumsta=
nces ?
>>
>> If you have an opinion, please let us know.
>>
>> A couple of points to keep in mind:
>> - The current document has been WGLC'ed without comment ~6 months ago.
>> - 3GPP has a dependency on the document (however I'm not sure if that de=
pendency includes the above "IN" feature)
>> - The connection data capability is defined in a general manner to be ge=
nerally useful in line with the overall capability negotiation framework (a=
s opposed to targeted at one specific use case with one specific value)
>> - There are scenarios where ICE cannot be used, even if implemented (e.g=
. ice-mismatch).
>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of=
 ICE support
>>
>>
>> Thanks
>>
>> -- Flemming
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential i=
nformation, privileged material (including material protected by the solici=
tor-client or other applicable privileges), or constitute non-public inform=
ation. Any use of this information by anyone other than the intended recipi=
ent is prohibited. If you have received this transmission in error, please =
immediately reply to the sender and delete this information from your syste=
m. Use, dissemination, distribution, or reproduction of this transmission b=
y unintended recipients is not authorized and may be unlawful.
>> .
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--
Jonathan Lennox
jonathan@vidyo.com


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

From fandreas@cisco.com  Sun Mar 24 08:39:19 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1035F21F8CD9 for ; Sun, 24 Mar 2013 08:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.468
X-Spam-Level: 
X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[AWL=0.531,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 kC63lhPQSIBK for ; Sun, 24 Mar 2013 08:39:18 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0021F8CA0 for ; Sun, 24 Mar 2013 08:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8701; q=dns/txt; s=iport; t=1364139558; x=1365349158; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2yyveq5MujEsitApQPNx1MVYCSr+xp3AD7jdDFrJyho=; b=Af7QyT/H/RLvJmhOH/wzE5ihNwcFfbQzpNu/HITNwa8MghlPJ8gFoOMU eOdCAo2dcpy6hLqU2+KAjLpwdvc3pATzT78rO5fP3rsFwiX8pEApHJ49p B3RPOvachEh0XsSLtjxXhrBCXWjj+rjn1PTXzUZxuvsW3tBQxaV9tAw6p M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAEgcT1GrRDoG/2dsb2JhbABDxW+BcBZ0giQBAQEDAQEBATU2CgEFBwQLEQQBAQEJFgQEBwkDAgECARUfCQgGDQEFAgEBBYgFBQ3BK41ogSULBwaDOgOWZ5EEgVSBUiCBNw
X-IronPort-AV: E=Sophos;i="4.84,900,1355097600"; d="scan'208";a="76593390"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 24 Mar 2013 15:39:16 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.254.117]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2OFdFIC001675; Sun, 24 Mar 2013 15:39:15 GMT
Message-ID: <514F1E29.8030906@cisco.com>
Date: Sun, 24 Mar 2013 11:39:21 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Christer Holmberg 
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com>,  <7594FB04B1934943A5C02806D1A2204B132443@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B132443@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 15:39:19 -0000

On 3/23/13 5:24 AM, Christer Holmberg wrote:
> Hi,
>
> In general I agree that having multiple ways of doing the same thing is not a good thing, and I don't have any strong feelings regarding the ccap usage.
>
> But, no matter what we say, what would actually prevent people from using ccap, in the same way they are using ANAT and altc? :)
There's no port signaling capability with ccap, but other than that, the 
only thing that prevents people from using this to signal alternative 
IP-addresses is the existence of a "MUST NOT" in the spec.

-- Flemming

> Regards,
>
> Christer
>
>
> ________________________________________
> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jonathan Lennox [jonathan@vidyo.com]
> Sent: Friday, 22 March 2013 10:00 PM
> To: Flemming Andreasen
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-addresses    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Currently, the deployed SIP world has three mechanisms to allow some flavor of negotiation among multiple IP addresses: ICE, altc (despite the general disapproval of the working group), and ANAT (despite its deprecation).
>
> I think that adding ccap as a fourth member of this set would be a terrible idea; and as far as I can tell, no one wants to do that.  So we need to make it clear that that it MUST NOT be used for that purpose.
>
> In the formulation below, I think I'd say that a given media description MUST NOT indicate more than one address with an IN network type, across all its configurations (actual and potential).
>
> Obviously, different media descriptions (m= line blocks) can have different addresses.
>
> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations.
>
> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:
>
>> Still waiting for more comments on this, especially from the people that
>> were very vocal in their complaints previously: Now is the time to speak up.
>>
>> Regardless, a few comments on the below:
>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"
>> addresses in a given SDP.
>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"
>> addresses in a given SDP.
>>
>> Nit-picking a bit on the actual text, which I think is important:
>> The "ccap" attribute is not what is being to select between different
>> IP-addresses; the use of a "ccap" attribute in a potential configuration
>> ("pcfg") is what is being used for this. Is the restriction that we want
>> here:
>> a) A potential configuration MUST NOT reference more than one "ccap"
>> attribute with a network type of "IN" ?
>> b) All potential configurations for a particular media description MUST
>> NOT reference more than one "ccap" attribute with a network type of "IN" ?
>> c) Something else ?
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>> On 3/22/13 1:35 AM, Andrew Allen wrote:
>>> I am OK with either of these proposals
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com
>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>> To: fandreas@cisco.com; mmusic@ietf.org
>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation.
>>>
>>> That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read:
>>>
>>> 
>>>      The 'ccap' attribute MUST NOT be used to select
>>>      between different IP connection addresses (e.g. between
>>>      "IP4" and "IP6" address families or different IP addresses
>>>       within the same IP address family).
>>> 
>>>
>>> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:
>>>
>>> 
>>>     The 'ccap' capability attribute is intended for offering
>>>     alternative connection addresses where the 
>>>     is "IN" or "PSTN", i.e. selecting between an IP based
>>>     bearer or a circuit-switched bearer.
>>> 
>>>
>>> Simo
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
>>> Sent: 19. maaliskuuta 2013 8:24
>>> To: mmusic
>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> Greetings
>>>
>>> As you may have seen, there has recently been some list discussion on the "connection data capability" defined in
>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>>
>>> To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording:
>>> 
>>> The 'ccap' capability attribute is intended to
>>>      be used only when there is no other mechanism available for
>>>      negotiating alternative connection address information, such as when
>>>      the  is different among the alternative addresses (e.g.
>>>      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>>      situations where an existing mechanism (such as Interactive
>>>      Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>      between different connection addresses (e.g.  "IP4" and "IP6" or
>>>      different IP addresses within the same IP address family).
>>> 
>>>
>>> The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ?
>>>
>>> If you have an opinion, please let us know.
>>>
>>> A couple of points to keep in mind:
>>> - The current document has been WGLC'ed without comment ~6 months ago.
>>> - 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature)
>>> - The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value)
>>> - There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch).
>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support
>>>
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>> .
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> --
> Jonathan Lennox
> jonathan@vidyo.com
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>


From btv1==7952eb95b97==HKaplan@acmepacket.com  Sun Mar 24 10:00:43 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5870621F8D19 for ; Sun, 24 Mar 2013 10:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level: 
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131,  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 1ZKE2tHzgyoD for ; Sun, 24 Mar 2013 10:00:42 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4A21F8D13 for ; Sun, 24 Mar 2013 10:00:42 -0700 (PDT)
X-ASG-Debug-ID: 1364144441-03fc2059399e420001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id vidSg7eZFNL5g69N (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Mar 2013 13:00:41 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sun, 24 Mar 2013 13:00:41 -0400
From: Hadriel Kaplan 
To: "Simo.Veikkolainen@nokia.com" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-ASG-Orig-Subj: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOKLEcrMM/ItEg/UihqdobZX1BHA==
Date: Sun, 24 Mar 2013 17:00:39 +0000
Message-ID: 
References: <5148049B.6090205@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1364144441
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.126114 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Cc: "" , "" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 17:07:56 -0000

On Mar 20, 2013, at 5:56 AM, Simo.Veikkolainen@nokia.com wrote:

> The ccap attribute should be able to carry either an IP or PSTN address; =
that way either a PSTN or an IP bearer could be offered as the highest prio=
rity configuration (in the "m=3D" line).  However, if we want to clarify th=
e intended use of ccap, we could modify the first sentence to read:
>=20
> 
>   The 'ccap' capability attribute is intended for offering
>   alternative connection addresses where the 
>   is "IN" or "PSTN", i.e. selecting between an IP based
>   bearer or a circuit-switched bearer.
> 

That is not technically possible, in practice.  If a ccap were to contain a=
n IN for an IP Address family, there is no port number indicated anywhere f=
or that IP address.  Therefore it can't be used to indicate an IP Address a=
lternate in practice, since one couldn't use the address alone.

So... either we re-introduce the port number so that a ccap can actually be=
 used to indicate an IP Address, or we make ccap only usable for PSTN and n=
ot IN.

-hadriel



From btv1==7952eb95b97==HKaplan@acmepacket.com  Sun Mar 24 10:03:32 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862D621F8938 for ; Sun, 24 Mar 2013 10:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  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 Z0P6FGvFViQM for ; Sun, 24 Mar 2013 10:03:31 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1021F8A4E for ; Sun, 24 Mar 2013 10:03:31 -0700 (PDT)
X-ASG-Debug-ID: 1364144610-03fc21298583ff0001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id 4RMae0idQx822Xmc (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Mar 2013 13:03:30 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sun, 24 Mar 2013 13:03:30 -0400
From: Hadriel Kaplan 
To: Andrew Allen 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-ASG-Orig-Subj: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOKLGBrMM/ItEg/UihqdobZX1BHA==
Date: Sun, 24 Mar 2013 17:03:29 +0000
Message-ID: <33B28251-B272-4770-96E3-DE0A8DBB10A0@acmepacket.com>
References:  <6290145A-C58E-47A8-B36F-43D066724370@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1364144610
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.126116 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "mmusic@ietf.org \(E-mail\)" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 17:08:03 -0000

On Mar 22, 2013, at 1:35 AM, Andrew Allen  wrote:

> CCAP is currently only used by 3GPP to allow the UA to choose between PS =
and CS for a terminating call at call setup when the UA has the possibility=
 to use either PS or CS for the call.
>=20
> Mid call Handover PS to CS and CS to PS uses other techniques and does no=
t involve use of CCAP.


Then it sounds to me like 3GPP only needs ccap to indicate PSTN; it does no=
t need to indicate an IP Address, as the c=3D line can do that.
Yes?

-hadriel


From btv1==7952eb95b97==HKaplan@acmepacket.com  Sun Mar 24 10:07:42 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62221F88C4 for ; Sun, 24 Mar 2013 10:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo5qtjrtDnic for ; Sun, 24 Mar 2013 10:07:41 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1721F88BE for ; Sun, 24 Mar 2013 10:07:40 -0700 (PDT)
X-ASG-Debug-ID: 1364144859-03fc21298484410001-mNOVBD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id xUD34VucnkPyH6PB (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Mar 2013 13:07:39 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sun, 24 Mar 2013 13:07:39 -0400
From: Hadriel Kaplan 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-ASG-Orig-Subj: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOKLIWUMAfzhj8wkGqve3dpATU5w==
Date: Sun, 24 Mar 2013 17:07:38 +0000
Message-ID: <15874272-F9D6-46E6-BFFB-B3C2B72CCB31@acmepacket.com>
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1534245BC8554F40A2A2B7D26E389E45@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1364144859
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.126116 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: Flemming Andreasen , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 17:08:08 -0000

On Mar 22, 2013, at 4:00 PM, Jonathan Lennox  wrote:

> In practice, given the port number issue that started this thread, I susp=
ect this means that the SDP offer will need to put the IN address in the ac=
tual configuration (in the c=3D line), and the PSTN address(es) will be in =
the potential configurations.

Yes exactly.  Remove the ability for ccap to use an IP Address by changing =
its ABNF.  That will remove any confusion. (though the wording of the usage=
 still needs to be cleaned up of course)

-hadriel


From prvs=7795882f21=aallen@blackberry.com  Sun Mar 24 10:34:07 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0910B21F8D30 for ; Sun, 24 Mar 2013 10:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.441
X-Spam-Level: 
X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396,  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 bJ0pCkos32DY for ; Sun, 24 Mar 2013 10:34:05 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 854A521F8D2C for ; Sun, 24 Mar 2013 10:34:05 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-d3-514f38fe06d7
Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 2D.59.13213.FF83F415; Sun, 24 Mar 2013 12:33:51 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Sun, 24 Mar 2013 12:33:50 -0500
From: Andrew Allen 
To: "fandreas@cisco.com" , "christer.holmberg@ericsson.com" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOKKXDllVw3x4YzUmJHibHjKJ20pi1GjDM
Date: Sun, 24 Mar 2013 17:33:48 +0000
Message-ID: 
In-Reply-To: <514F1E29.8030906@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsXC5Zyvq/vfwj/QoOuDsMWFmYcZLd5f0LXY v/g8s8XU5Y9ZHFg8pvzeyOrx6+tVNo8lS34yebQ9u8MewBLVwGiTlFhSFpyZnqdvZ5OYl5df kliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2Kr lFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyJs18zVbwxLdi 0YU37A2Mm+27GDk5JARMJA4/uMEOYYtJXLi3nq2LkYtDSKCNSWLt26ssIAkhgc2MEnOWW4DY bAJaEvsPT2cCsUUEiiTuLz4CVsMsECJx6PlbNhBbWKBC4lDrEaiaSonDE1pZIGwjiTcfpzKC 2CwCqhL3WzeB1fAKeEhcfN8E1sspoCnRtbQTLM4IdND3U2uYIOaLS9x6Mp8J4lABiSV7zjND 2KISLx//Y4WwFSX+7v3OClGvJ3Fj6hQ2CFtbYtnC18wQuwQlTs58wjKBUXQWkrGzkLTMQtIy C0nLAkaWVYyCuRnFBmaGyXnJekWZuXp5qSWbGEFJw1HDYAfj+/cWhxgFOBiVeHhnGfoHCrEm lhVX5h5ilOBgVhLhvaMNFOJNSaysSi3Kjy8qzUktPsToCgyJicxS3Mn5wISWVxJvbGCAm6Mk zvtrsU+gkEA6MPlkp6YWpBbBzGHi4ATZwyUlUgxMIalFiaUlGfGgRBdfDEx1Ug2Ms7dl/zCe UMbzeOahvMQ/LC90xC+Kta6fmfrb5PG9Dxd/lV1o+fXg9Qrlb2aPLJ7yTw+8+D8zIOXtobY1 vCrX+C4wlInpf7u6U2DaJh32n5aCzh3udzbri7TLLTSZ2vjpp+S6rUZBC9Msp4d/nbdFyM30 ikD888unvYXnlimYbVFl2rLJL/mflBJLcUaioRZzUXEiAIFqs3lbAwAA
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 17:34:07 -0000

There is also nothing that prevents people from defining their own proprieta=
ry attributes to do such a thing but that is not part of an IETF standard an=
d is not approved usage.

If we really feel the need to discourage further such usage I suppose we cou=
ld add some text stating that if CCAP s received containing an IN net  type=
 and an IN net type is present in the corresponding Connection Attribute the=
n the CCAP attribute MUST be ignored.

That way compliant implementations would not perfom the discouraged behavior=
.

Andrew

----- Original Message -----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time=0A=
To: Christer Holmberg 
Cc: Jonathan Lennox ; mmusic@ietf.org 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)


On 3/23/13 5:24 AM, Christer Holmberg wrote:
> Hi,
>
> In general I agree that having multiple ways of doing the same thing is no=
t a good thing, and I don't have any strong feelings regarding the ccap usag=
e.
>
> But, no matter what we say, what would actually prevent people from using=
 ccap, in the same way they are using ANAT and altc? :)
There's no port signaling capability with ccap, but other than that, the 
only thing that prevents people from using this to signal alternative 
IP-addresses is the existence of a "MUST NOT" in the spec.

-- Flemming

> Regards,
>
> Christer
>
>
> ________________________________________
> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jonat=
han Lennox [jonathan@vidyo.com]
> Sent: Friday, 22 March 2013 10:00 PM
> To: Flemming Andreasen
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-address=
es    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Currently, the deployed SIP world has three mechanisms to allow some flavo=
r of negotiation among multiple IP addresses: ICE, altc (despite the general=
 disapproval of the working group), and ANAT (despite its deprecation).
>
> I think that adding ccap as a fourth member of this set would be a terribl=
e idea; and as far as I can tell, no one wants to do that.  So we need to ma=
ke it clear that that it MUST NOT be used for that purpose.
>
> In the formulation below, I think I'd say that a given media description M=
UST NOT indicate more than one address with an IN network type, across all i=
ts configurations (actual and potential).
>
> Obviously, different media descriptions (m=3D line blocks) can have differ=
ent addresses.
>
> In practice, given the port number issue that started this thread, I suspe=
ct this means that the SDP offer will need to put the IN address in the actu=
al configuration (in the c=3D line), and the PSTN address(es) will be in the=
 potential configurations.
>
> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:
>
>> Still waiting for more comments on this, especially from the people that
>> were very vocal in their complaints previously: Now is the time to speak=
 up.
>>
>> Regardless, a few comments on the below:
>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"
>> addresses in a given SDP.
>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"
>> addresses in a given SDP.
>>
>> Nit-picking a bit on the actual text, which I think is important:
>> The "ccap" attribute is not what is being to select between different
>> IP-addresses; the use of a "ccap" attribute in a potential configuration
>> ("pcfg") is what is being used for this. Is the restriction that we want
>> here:
>> a) A potential configuration MUST NOT reference more than one "ccap"
>> attribute with a network type of "IN" ?
>> b) All potential configurations for a particular media description MUST
>> NOT reference more than one "ccap" attribute with a network type of "IN"=
 ?
>> c) Something else ?
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>> On 3/22/13 1:35 AM, Andrew Allen wrote:
>>> I am OK with either of these proposals
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of Simo.Veikkolainen@nokia.com
>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>> To: fandreas@cisco.com; mmusic@ietf.org
>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses=
 (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> I went through the discussion, and my reading is that there is agreement=
 on not allowing ccap to be used for alternative IP address negotiation.
>>>
>>> That could be made clear in the text e.g. by modifying the second senten=
ce Flemming quoted to read:
>>>
>>> 
>>>      The 'ccap' attribute MUST NOT be used to select
>>>      between different IP connection addresses (e.g. between
>>>      "IP4" and "IP6" address families or different IP addresses
>>>       within the same IP address family).
>>> 
>>>
>>> The ccap attribute should be able to carry either an IP or PSTN address;=
 that way either a PSTN or an IP bearer could be offered as the highest prio=
rity configuration (in the "m=3D" line).  However, if we want to clarify the=
 intended use of ccap, we could modify the first sentence to read:
>>>
>>> 
>>>     The 'ccap' capability attribute is intended for offering
>>>     alternative connection addresses where the 
>>>     is "IN" or "PSTN", i.e. selecting between an IP based
>>>     bearer or a circuit-switched bearer.
>>> 
>>>
>>> Simo
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf=
 Of ext Flemming Andreasen
>>> Sent: 19. maaliskuuta 2013 8:24
>>> To: mmusic
>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> Greetings
>>>
>>> As you may have seen, there has recently been some list discussion on th=
e "connection data capability" defined in
>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>>
>>> To recap, the connection data capability ("ccap") provides capability ne=
gotiation capabilities for what amounts to the "c=3D" line in regular SDP, a=
nd as such enables negotiation of network type (such as "IN") and IP-address=
 information (v4 and v6 addresses). The Standards Track mechanism for negoti=
ating and determining alternative IP-address information today is ICE, and h=
ence the draft currently includes the following wording:
>>> 
>>> The 'ccap' capability attribute is intended to
>>>      be used only when there is no other mechanism available for
>>>      negotiating alternative connection address information, such as whe=
n
>>>      the  is different among the alternative addresses (e.g.
>>>      "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>>      situations where an existing mechanism (such as Interactive
>>>      Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>      between different connection addresses (e.g.  "IP4" and "IP6" or
>>>      different IP addresses within the same IP address family).
>>> 
>>>
>>> The above text has led to some confusion as to exactly when and what "cc=
ap" can be used for. More specifically, is it/should it ever be allowed to u=
se "ccap" to convey an IP4 or IP6 address, and if so, under what circumstanc=
es ?
>>>
>>> If you have an opinion, please let us know.
>>>
>>> A couple of points to keep in mind:
>>> - The current document has been WGLC'ed without comment ~6 months ago.
>>> - 3GPP has a dependency on the document (however I'm not sure if that de=
pendency includes the above "IN" feature)
>>> - The connection data capability is defined in a general manner to be ge=
nerally useful in line with the overall capability negotiation framework (as=
 opposed to targeted at one specific use case with one specific value)
>>> - There are scenarios where ICE cannot be used, even if implemented (e.g=
. ice-mismatch).
>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of=
 ICE support
>>>
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential i=
nformation, privileged material (including material protected by the solicit=
or-client or other applicable privileges), or constitute non-public informat=
ion. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imme=
diately reply to the sender and delete this information from your system. Us=
e, dissemination, distribution, or reproduction of this transmission by unin=
tended recipients is not authorized and may be unlawful.
>>> .
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> --
> Jonathan Lennox
> jonathan@vidyo.com
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=57952afea4=aallen@blackberry.com  Sun Mar 24 10:35:11 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E8421F8D37 for ; Sun, 24 Mar 2013 10:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.752
X-Spam-Level: 
X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=0.451,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 kAHy3Bz4Iu2k for ; Sun, 24 Mar 2013 10:35:10 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39F21F8CF7 for ; Sun, 24 Mar 2013 10:35:10 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-6f-514f394d95dc
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id A7.66.09265.D493F415; Sun, 24 Mar 2013 12:35:10 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Sun, 24 Mar 2013 12:35:09 -0500
From: Andrew Allen 
To: "HKaplan@acmepacket.com" 
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJK0vVKS0PWIWhUmJ7t6klfo0spixDsKggAReuID//7UHaw==
Date: Sun, 24 Mar 2013 17:35:08 +0000
Message-ID: 
In-Reply-To: <33B28251-B272-4770-96E3-DE0A8DBB10A0@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXC5Zyvp+tn6R9o8GUHi8Xcy8/ZLaYuf8zi wOSxafJmNo8lS34yBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejAdrFQpmsFc03l/D1sB4h7WLkZNDQsBE4tPSBhYI W0ziwr31bF2MXBxCAisZJS5MO8wO4WxmlFi2pZcRpIpNQEti/+HpTCC2iICpxN/L3UAdHBzM AuoSVxcHgYSFBSokru44DlVSKbH15AQWCNtJ4uyU5WCLWQRUJRZdugQ2klfAQ+LIpGnMIDYn UE3jhxVgvYxAB30/tQbMZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B/WMosTfvd9ZIer1JG5M ncIGYWtLLFv4mhlil6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilEwN6PYwMwgOS9Zrygz Vy8vtWQTIygZOGro72B8+97iEKMAB6MSD+8+Jf9AIdbEsuLK3EOMEhzMSiK8d7SBQrwpiZVV qUX58UWlOanFhxhdgSExkVmKOzkfmKjySuKNDQxwc5TEeX8t9gkUEkgHpp7s1NSC1CKYOUwc nCB7uKREioEJJLUosbQkIx6U5uKLgYlOqoEx50/GxoVBjJ/myiu8fqq1Rzr14Faph6ZzF+78 FfPbM2FSf+TyE4rJ64uz+76L/1q4RtDAN23uxxe/2yznTBFaWbj47Nk8rT1sa9fO6N0x4777 2/88pR6mRzhtHq16yrLiZpRLt6XaEok1pjJh2nHz7rq28V8TfxMpVBqrU/30hsT6kID3+ise KLEUZyQaajEXFScCAKbe1YBHAwAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Mar 2013 17:35:11 -0000

Hadriel

Correct

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
Sent: Sunday, March 24, 2013 12:03 PM Central Standard Time=0A=
To: Andrew Allen
Cc: mmusic@ietf.org (E-mail) 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(dr=
aft-ietf-mmusic-sdp-miscellaneous-caps-04)


On Mar 22, 2013, at 1:35 AM, Andrew Allen  wrote:

> CCAP is currently only used by 3GPP to allow the UA to choose between PS a=
nd CS for a terminating call at call setup when the UA has the possibility t=
o use either PS or CS for the call.
> 
> Mid call Handover PS to CS and CS to PS uses other techniques and does not=
 involve use of CCAP.


Then it sounds to me like 3GPP only needs ccap to indicate PSTN; it does not=
 need to indicate an IP Address, as the c=3D line can do that.
Yes?

-hadriel


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From fandreas@cisco.com  Sun Mar 24 18:21:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4092621F8E3D for ; Sun, 24 Mar 2013 18:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.83
X-Spam-Level: 
X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=0.769,  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 L1etlIMYWceV for ; Sun, 24 Mar 2013 18:21:39 -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 EDE3321F8E3C for ; Sun, 24 Mar 2013 18:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1235; q=dns/txt; s=iport; t=1364174499; x=1365384099; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VcvgB87XAwZgL03y5/I8v5s1ZquqcHFfelhRb89zW8A=; b=KDV2U2XEHCp+57WnFsJGLzMBASsENoNUAhFkVAyiE9tHiyfGcj45B40M O1oXZz7IuN65zN94jN6cM5JZm8cyuBjjWnjH4dWN6vsFOJI1Cj8qKYfQR fNx1PY7VMNHhQNEev5OFZkMefr2rmhhkLlbfiilr7y4kf8EXH97p79uIQ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGilT1GtJXHA/2dsb2JhbABDxXyBehZ0giQBAQEDAThAAQULCw4KCRYECwkDAgECAUUGDQEFAgEBiAoGwWSPGAeDQAOWZ5EEgVSBUiA
X-IronPort-AV: E=Sophos;i="4.84,902,1355097600"; d="scan'208";a="190975142"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 25 Mar 2013 01:21:38 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.253.124]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2P1Lb2a002616;  Mon, 25 Mar 2013 01:21:37 GMT
Message-ID: <514FA6A1.5050000@cisco.com>
Date: Sun, 24 Mar 2013 21:21:37 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com>  <15874272-F9D6-46E6-BFFB-B3C2B72CCB31@acmepacket.com>
In-Reply-To: <15874272-F9D6-46E6-BFFB-B3C2B72CCB31@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 01:21:40 -0000

On 3/24/13 1:07 PM, Hadriel Kaplan wrote:
> On Mar 22, 2013, at 4:00 PM, Jonathan Lennox  wrote:
>
>> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations.
> Yes exactly.  Remove the ability for ccap to use an IP Address by changing its ABNF.
That's my problem with this whole discussion. We have defined a general 
connection data capability, and now we don't want it to be able to 
express anything beyond "PSTN" - exactly why did we do this again and 
what was it the WG agreed to when taking this on as a WG item ?

Also, if you explicitly prevent the ABNF from supporting IP-addresses, 
then you must be listing the values that actually are supported and 
hence we've further lost generality in how we define this and general 
alignment with the SDP structure where we register supported values 
separately. I'm really not in favor of any of that.

-- Flemming

>   That will remove any confusion. (though the wording of the usage still needs to be cleaned up of course)
>
> -hadriel
>
>


From fandreas@cisco.com  Sun Mar 24 18:26:46 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5C121F8E51 for ; Sun, 24 Mar 2013 18:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.901
X-Spam-Level: 
X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.698,  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 piLWENeK7JyV for ; Sun, 24 Mar 2013 18:26:45 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 30D5421F8E57 for ; Sun, 24 Mar 2013 18:26:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1603; q=dns/txt; s=iport; t=1364174805; x=1365384405; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oJOTsYLPpO5EOE9T7vY38mhHViwxt2MR0HYBg+oMTQg=; b=HC3i2OHYtWWo7cbc11rkfFQcuVf9xLCDk+Qqc0q/MyFgOjASrw4dOydF 2ifCwjgaBIgQRo3M/epDxXjCzRmkRJMAGphIXUPUSzGhnZCBIZlQUsbmI N9ILiTu4yrcrVWZt86McFjptq1+yPb7dLbtlBycLm3O95fgqkuc37ePqE 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANCmT1GrRDoJ/2dsb2JhbABDxXyBehZ0giQBAQEEOEABEAsOCgkWBAsJAwIBAgFFBg0BBQIBAReHeMFpjxgHg0ADlmeRBIFUgVIg
X-IronPort-AV: E=Sophos;i="4.84,902,1355097600"; d="scan'208";a="76617708"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Mar 2013 01:26:44 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.253.124]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2P1QhNV006171; Mon, 25 Mar 2013 01:26:44 GMT
Message-ID: <514FA7D3.8040909@cisco.com>
Date: Sun, 24 Mar 2013 21:26:43 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <5148049B.6090205@cisco.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 01:26:46 -0000

On 3/24/13 1:00 PM, Hadriel Kaplan wrote:
> On Mar 20, 2013, at 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
>
>> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:
>>
>> 
>>    The 'ccap' capability attribute is intended for offering
>>    alternative connection addresses where the 
>>    is "IN" or "PSTN", i.e. selecting between an IP based
>>    bearer or a circuit-switched bearer.
>> 
> That is not technically possible, in practice.  If a ccap were to contain an IN for an IP Address family, there is no port number indicated anywhere for that IP address.  Therefore it can't be used to indicate an IP Address alternate in practice, since one couldn't use the address alone.
>
> So... either we re-introduce the port number so that a ccap can actually be used to indicate an IP Address, or we make ccap only usable for PSTN and not IN.
These are not the only choices. We strive for defining general 
solutions, and there is no reason why lack of port numbers should lead 
us to define a general connection data capability that cannot contain 
any IP-addresses. The connection data capability by itself will of 
course not be sufficient to allow for negotiation of transport address 
alternatives (intentionally), but that is really a separate (albeit 
related) issue.

-- Flemming

> -hadriel
>
>
> .
>


From fandreas@cisco.com  Sun Mar 24 18:31:39 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADBC21F8E14 for ; Sun, 24 Mar 2013 18:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.615
X-Spam-Level: 
X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AWL=0.384,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 pK02fTjAal9t for ; Sun, 24 Mar 2013 18:31:37 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5BB21F8CEB for ; Sun, 24 Mar 2013 18:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10952; q=dns/txt; s=iport; t=1364175097; x=1365384697; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ND5RMEnx0s9LOh0KIuxfB5/0W+px5GnEIrSErApF2ZE=; b=iTt2tPQo+SuBeCpXZqccXUvGfeosTqjabj/vK09vZezD6CfwEi7a8qEz zWb3xvQBM3+O+g4HzBCKE2Rj54Bxr5A3UzDBSxv2LganZhDXBd5IYf/Ww hp+UCUNJrqvn7wMjp/pTUhmkY2PfzOYzmsp3CeRQ3+0r5hCD2wvoAonk3 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJynT1GtJV2d/2dsb2JhbABDxXyBehZ0giQBAQEDAQEBATU0AggCAQUHBAsOAwQBAQEJFgQEBwkDAgECARUfCQgGDQEFAgEBBYgFBgzBXI1ogSULBwaDOgOWZ5EEgVSBUiCBNw
X-IronPort-AV: E=Sophos;i="4.84,902,1355097600"; d="scan'208";a="190985162"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 25 Mar 2013 01:31:36 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.253.124]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2P1VZhN028288;  Mon, 25 Mar 2013 01:31:35 GMT
Message-ID: <514FA8F7.7060203@cisco.com>
Date: Sun, 24 Mar 2013 21:31:35 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Andrew Allen 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 01:31:39 -0000

On 3/24/13 1:33 PM, Andrew Allen wrote:
> There is also nothing that prevents people from defining their own proprietary attributes to do such a thing but that is not part of an IETF standard and is not approved usage.
Agreed.

> If we really feel the need to discourage further such usage I suppose we could add some text stating that if CCAP s received containing an IN net  type and an IN net type is present in the corresponding Connection Attribute then the CCAP attribute MUST be ignored.
I think that gets complicated quickly for a questionable gain. I'd 
prefer the "MUST NOT" described below with an explanation as to why it's 
there; as you note, ultimately people either decide to be spec compliant 
or not.

-- Flemming
> That way compliant implementations would not perfom the discouraged behavior.
>
> Andrew
>
> ----- Original Message -----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time
> To: Christer Holmberg 
> Cc: Jonathan Lennox ; mmusic@ietf.org 
> Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
> On 3/23/13 5:24 AM, Christer Holmberg wrote:
>> Hi,
>>
>> In general I agree that having multiple ways of doing the same thing is not a good thing, and I don't have any strong feelings regarding the ccap usage.
>>
>> But, no matter what we say, what would actually prevent people from using ccap, in the same way they are using ANAT and altc? :)
> There's no port signaling capability with ccap, but other than that, the
> only thing that prevents people from using this to signal alternative
> IP-addresses is the existence of a "MUST NOT" in the spec.
>
> -- Flemming
>
>> Regards,
>>
>> Christer
>>
>>
>> ________________________________________
>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jonathan Lennox [jonathan@vidyo.com]
>> Sent: Friday, 22 March 2013 10:00 PM
>> To: Flemming Andreasen
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-addresses    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>> Currently, the deployed SIP world has three mechanisms to allow some flavor of negotiation among multiple IP addresses: ICE, altc (despite the general disapproval of the working group), and ANAT (despite its deprecation).
>>
>> I think that adding ccap as a fourth member of this set would be a terrible idea; and as far as I can tell, no one wants to do that.  So we need to make it clear that that it MUST NOT be used for that purpose.
>>
>> In the formulation below, I think I'd say that a given media description MUST NOT indicate more than one address with an IN network type, across all its configurations (actual and potential).
>>
>> Obviously, different media descriptions (m= line blocks) can have different addresses.
>>
>> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations.
>>
>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:
>>
>>> Still waiting for more comments on this, especially from the people that
>>> were very vocal in their complaints previously: Now is the time to speak up.
>>>
>>> Regardless, a few comments on the below:
>>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"
>>> addresses in a given SDP.
>>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"
>>> addresses in a given SDP.
>>>
>>> Nit-picking a bit on the actual text, which I think is important:
>>> The "ccap" attribute is not what is being to select between different
>>> IP-addresses; the use of a "ccap" attribute in a potential configuration
>>> ("pcfg") is what is being used for this. Is the restriction that we want
>>> here:
>>> a) A potential configuration MUST NOT reference more than one "ccap"
>>> attribute with a network type of "IN" ?
>>> b) All potential configurations for a particular media description MUST
>>> NOT reference more than one "ccap" attribute with a network type of "IN" ?
>>> c) Something else ?
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>
>>>
>>> On 3/22/13 1:35 AM, Andrew Allen wrote:
>>>> I am OK with either of these proposals
>>>>
>>>> -----Original Message-----
>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com
>>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>>> To: fandreas@cisco.com; mmusic@ietf.org
>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>>
>>>> I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation.
>>>>
>>>> That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read:
>>>>
>>>> 
>>>>       The 'ccap' attribute MUST NOT be used to select
>>>>       between different IP connection addresses (e.g. between
>>>>       "IP4" and "IP6" address families or different IP addresses
>>>>        within the same IP address family).
>>>> 
>>>>
>>>> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:
>>>>
>>>> 
>>>>      The 'ccap' capability attribute is intended for offering
>>>>      alternative connection addresses where the 
>>>>      is "IN" or "PSTN", i.e. selecting between an IP based
>>>>      bearer or a circuit-switched bearer.
>>>> 
>>>>
>>>> Simo
>>>>
>>>> -----Original Message-----
>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen
>>>> Sent: 19. maaliskuuta 2013 8:24
>>>> To: mmusic
>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>>
>>>> Greetings
>>>>
>>>> As you may have seen, there has recently been some list discussion on the "connection data capability" defined in
>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)
>>>>
>>>> To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording:
>>>> 
>>>> The 'ccap' capability attribute is intended to
>>>>       be used only when there is no other mechanism available for
>>>>       negotiating alternative connection address information, such as when
>>>>       the  is different among the alternative addresses (e.g.
>>>>       "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
>>>>       situations where an existing mechanism (such as Interactive
>>>>       Connectivity Establishment (ICE) [RFC5245]) can be used to select
>>>>       between different connection addresses (e.g.  "IP4" and "IP6" or
>>>>       different IP addresses within the same IP address family).
>>>> 
>>>>
>>>> The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ?
>>>>
>>>> If you have an opinion, please let us know.
>>>>
>>>> A couple of points to keep in mind:
>>>> - The current document has been WGLC'ed without comment ~6 months ago.
>>>> - 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature)
>>>> - The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value)
>>>> - There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch).
>>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support
>>>>
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>> ---------------------------------------------------------------------
>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>> .
>>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> --
>> Jonathan Lennox
>> jonathan@vidyo.com
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> .
>


From Christian.Groves@nteczone.com  Sun Mar 24 22:50:40 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D4721F8E47 for ; Sun, 24 Mar 2013 22:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level: 
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_18=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 LW51nj2rd30Y for ; Sun, 24 Mar 2013 22:50:39 -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 A1CFB21F8E4D for ; Sun, 24 Mar 2013 22:50:38 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: An0DAPjjT1F20fbw/2dsb2JhbAANNsVaAQMBAwGCE4MYAQEBAgIBAQE1GxUGAggRCxgJFg8JAwIBAgEVMBMGAgEBBYgXrwySUYl+hSGDQAOrCQ
Received: from ppp118-209-246-240.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.246.240]) by ipmail06.adl2.internode.on.net with ESMTP; 25 Mar 2013 16:20:37 +1030
Message-ID: <514FE5A9.3060900@nteczone.com>
Date: Mon, 25 Mar 2013 16:50:33 +1100
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References:   <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se>
In-Reply-To: <5145729C.6030905@omnitor.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 05:50:40 -0000

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

On 17/03/2013 6:37 PM, Gunnar Hellstrom wrote:
> On 2013-03-17 01:21, Hadriel Kaplan wrote:
>> Preface note: I am not against the needs of hearing-impaired or 
>> visually-impaired people - I'm asking the questions because I think 
>> the simpler the mechanism is, the more likely it will be to actually 
>> work and be deployed, and thus not hinder such cases.
>>
>> I may be very very wrong, and I'd certainly defer to those who know 
>> for sure, but I would think they'd want the call to succeed for the 
>> media types they need to use, rather than only succeed if the 
>> specific directionality traits of those media lines are supported by 
>> the other side.
> Yes, we said so yesterday:
> Other media and media directions than the ones you declare preference 
> for are usually also appreciated, and sometimes important.
> You said some time ago that a medium-direction with no language 
> indication just means that there is no preferred language use of it, 
> but it may very well be desired in the call and should be connected if 
> supported. That was why the a=sendonly and a=recvonly attributes 
> cannot be used for preference indications.
>>
>> For the below comments, I'll use 'sign-language' as a token, although 
>> I assume there must actually be many tokens since there are many sign 
>> languages.
>>
>> Other comments inline...
>>
>>
>> On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom 
>>  wrote:
>>
>>> On 2013-03-16 20:54, Hadriel Kaplan wrote:
>>>> What's the use-case when the two directions are not identical?  
>>>> I.e., when does it make sense to receive Latin but send Swahili for 
>>>> the same media?
>>>> I ask because this separation complicates things quite a bit in 
>>>> code/testing/error-handling, obviously.
> The need came from the relay service examples.
> But let us try to fancy a need from the spoken language side:
> A high level conference is held with English as main language but 
> possibility to get interpreting to and from other languages.
>
> A delegate from Kenya feel well confident in listening directly in 
> English, not risking delays and dropouts through interpreters, but 
> feel much more confident in expressing herself in Swahili when she 
> speaks. Therefore she selects that combination and the remote 
> conference is set up so that she get the Swahili interpretation when 
> she talks.
>>> Examples are:
>>>
>>> 1. Deaf-blind person who want to use sign language in video out, but 
>>> cannot see it in reception and therefore declare language in video 
>>> only for send video.
>>> ( also declaring preference for reading text and acceptance for 
>>> typing text )
>> So just indicate 'sign-language' for video media, and have a text 
>> media line.
>> It will be very clear to the far-end when they see the caller is 
>> blind that they can only see sign language but not send it.  Or if 
>> you want to make it one-way video on the wire, that's what the 
>> 'a=sendonly' is for. (same goes for text media line)
>>
>> The important thing is that you need to reach someone who can 
>> understand your sign language.
> No, the important thing is to have a chance to rapidly evaluate either 
> how to route the call to someone who match the preferences, or to add 
> services doing translations so that the preferences are fulfilled.
>
> It is not good to let the deaf-blind user be connected with a person 
> who has only video enabled.
>>
>>
>>> 2. Hard-of-hearing person who want to talk in audio channel, but 
>>> cannot hear answers , and therefore declare languge for audio only 
>>> in send audio
>>> ( also declaring preference for reading text and acceptance for 
>>> typing text )
>> If you literally only want to send audio but not receive, use 
>> 'a=sendonly' for the audio line, and have a text media line.
> We said yesterday that that is not the case, we are not discussing 
> sendonly etc.  It is use of the media we are discussing.  Support of 
> the media is another thing, already well covered in both SDP and SIP.
>>   If, however, you mean they want bi-directional audio but a 
>> preference to reach someone who can also do text, or video for 
>> sign-language, send normal audio and text media lines, or with a 
>> 'sign-language' video line.
>>
>> The important thing is that you reach someone who can hear you, and 
>> can type text back to you (or do sign language).
>>
>>
>>> 3. Person with speech disabilities who want to hear in audio 
>>> channel, but cannot use audio for talking
>>> ( also declaring preference for typing text and acceptance for 
>>> reading text )
>> Same as above, but with 'a=recvonly' if you literally want one-way on 
>> the wire.
>> The important thing is you reach someone who can talk to you, but 
>> also can read text from you or see your sign language.
>>
>>
>>> By the way, here we have a tricky case:
>>> 4. Person with speech disabilities who want to hear in audio 
>>> channel, and talks unclearly, so that he want a speech relay service 
>>> to listen to the call and clarify what got hard to understand for 
>>> the other party.
>>> Maybe that service needs to be requested with an explicit service 
>>> request instead of language and modality matching?
>> I have not looked into how such relay services work, for example 
>> VRS.  It would be good to know how they're used in practice. (I can 
>> imagine several ways they could be done)
> Read
> http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf 
>
>
>>
>> -hadriel
>>
> /Gunnar
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From mohamed.boucadair@orange.com  Mon Mar 25 01:44:48 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F7C21F8EAC for ; Mon, 25 Mar 2013 01:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.641
X-Spam-Level: 
X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_40=-0.185, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 OL3nlYvWk0gi for ; Mon, 25 Mar 2013 01:44:48 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4731921F8E6B for ; Mon, 25 Mar 2013 01:44:48 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 330433B42AF; Mon, 25 Mar 2013 09:44:47 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 186D44C099; Mon, 25 Mar 2013 09:44:47 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 25 Mar 2013 09:44:47 +0100
From: 
To: Jonathan Lennox , Flemming Andreasen 
Date: Mon, 25 Mar 2013 09:44:45 +0100
Thread-Topic: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: Ac4nN+KLtohQNzF8QJq+4t1yVTiI4AB/NKLg
Message-ID: <94C682931C08B048B7A8645303FDC9F36EBA754B98@PUEXCB1B.nanterre.francetelecom.fr>
References: <5148049B.6090205@cisco.com>   <514CA4E1.50006@cisco.com> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.21.121514
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 08:44:49 -0000

Dear all,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20
>De la part de Jonathan Lennox
>Envoy=E9 : vendredi 22 mars 2013 21:00
>=C0 : Flemming Andreasen
>Cc : mmusic@ietf.org
>Objet : Re: [MMUSIC] Connection Data Capability (ccap) and=20
>IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>


>In practice, given the port number issue that started this=20
>thread, I suspect this means that the SDP offer will need to=20
>put the IN address in the actual configuration (in the c=3D=20
>line), and the PSTN address(es) will be in the potential=20
>configurations.

Med: This makes sense. This is a good way to proceed.


From pkyzivat@alum.mit.edu  Mon Mar 25 07:48:37 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA03B11E80C5 for ; Mon, 25 Mar 2013 07:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.307
X-Spam-Level: 
X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.745,  BAYES_05=-1.11, 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 ZUIIBY83Rjp3 for ; Mon, 25 Mar 2013 07:48:36 -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 DC83A11E80B8 for ; Mon, 25 Mar 2013 07:48:35 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id Fmxc1l0011YDfWL5DqobjL; Mon, 25 Mar 2013 14:48:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id Fqob1l00G3ZTu2S3gqobPT; Mon, 25 Mar 2013 14:48:35 +0000
Message-ID: <515063C3.3040700@alum.mit.edu>
Date: Mon, 25 Mar 2013 22:48:35 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
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=1364222915; bh=6tFPSzNFxy9de1dwjjETSyv/LqMgIsepZSpwALHzjws=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ac5r8n/jG5RsV7LJwx7t7RGzbZhMlqRwj6REKZ0t08rLD+YMBbny43EP1+881A9LW GQNoL7mrsFQuYL/Dm9alr362ddDS+HPgygjw1bMGVlsEtb4cbGDebt3mJXp+3ZzqW4 HKXyNu7pMjPqOKI5nXsWQ2ctqfQ3Rh6iquGHffabNV8v4yc2/ELaYztp30aNdI5z6+ IlWsE+86SV05Qll7eTO5NtG1hxryb7+6RKB0i+luwrUsXOJ+Hn/Ps0iTFioiamoyeB UlbRnNGjDogVBqHF4S5Wp4brotDVzeilj67KndZJYwp6Nt6H1ujVOpS1HCkru9t5Vh 4Xsr7pw5g5m/A==
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 14:48:37 -0000

I think you need to distinguish two cases here:

- both ends understand and use the language negotiation mechanism,
   and there is a mismatch between what is desired and what is
   required.

- one end is using this language negotiation mechanism, and has
   expressed certain requirements, but the other end doesn't
   understand and isn't using the mechanism.

In the first case it may make sense to fail the call. In the other case 
it probably does not.

Callerprefs has tried to deal with this, though the mechamism for doing 
so it rather obscure. If there is a desire to deal with this at the SDP 
level then it will take some work to do so.

	Thanks,
	Paul

On 3/17/13 3:54 AM, Hadriel Kaplan wrote:
>
> On Mar 15, 2013, at 2:49 PM, Randall Gellens  wrote:
>
>> SDP or SIP:
>> - Use SDP for actual negotiation, but use SIP header to provide a hint
>> - Emergency services use case can use SDP for policy routing/handling decisions
>> - Other use cases may or may not have ability/desire to use SDP for this and can use the SIP header hint
>
> Another reason not to only put it in SDP is the delayed-offer scenario.
>
>
>> Directionality of SDP attributes:
>> - Define two new SDP media-level attributes: 'send-lang' and 'recv-lang'.  In an offer, send-lang is a list in preference order of the languages the offerer wishes to send and recv-lang is a list in preference order of the languages the offerer wishes to receive.  In most cases these are expected to have the same value, because otherwise it is harder to match desired resources.  In an answer, send-lang is the accepted language the answerer will send (which in most cases should be one of the languages in the offer's recv-lang) and recv-lang is the accepted language the answerer expects to receive (which in most cases should be one of the languages in the offer's send-lang).
>
> What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
>
>
>> Advisory vs Required:
>> - Does call fail if no common language?
>
> I haven't thought about this draft's scenarios much, but think we need to think about this very carefully.  Otherwise the outcome would be SBCs would strip it from the INVITE, just to avoid failing the call.  I don't think anyone would actually want such calls to truly fail for the end user - not just for Emergency calls, but for any calls - people can always hang up if they don't like what they hear/see.  ISTM that there's a high likelihood of this language value actually being *wrong* in either the sender or receiver or both, so I think failing the call because of a mismatch would be really bad.
>
> At first glance, I can see one and only one reason failing it would make sense: for a serial-forking proxy/B2BUA/UA to be able to recurse to alternate targets if the first one didn't support the language(s).  But it has a very negative drawback: if there are no more targets it can recurse to, or if there were no such forking to begin with, the call fails.  Then we're back to square one above, and the thing gets removed from all calls by middleboxes, just to avoid such cases.
>
> -hadriel
> p.s. was this presented in MMUSIC this past week?  For some reason this topic was neither on the MMUSIC agenda pages (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in the meeting materials (https://datatracker.ietf.org/meeting/86/materials.html), nor is the draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  I only mention this because I was looking for the slides and draft today and didn't find them.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From pkyzivat@alum.mit.edu  Mon Mar 25 07:55:10 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA111E80D3 for ; Mon, 25 Mar 2013 07:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.163
X-Spam-Level: 
X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  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 K1PGnRkbiOWY for ; Mon, 25 Mar 2013 07:55:09 -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 9BF2711E80C5 for ; Mon, 25 Mar 2013 07:55:08 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id FoYl1l0050SCNGk5Bqv7Rg; Mon, 25 Mar 2013 14:55:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:2d58:48c3:3c7b:f7ef]) by omta09.westchester.pa.mail.comcast.net with comcast id Fqv51l00N12VbFc3Vqv5Pl; Mon, 25 Mar 2013 14:55:07 +0000
Message-ID: <51506548.1050209@alum.mit.edu>
Date: Mon, 25 Mar 2013 22:55:04 +0800
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References:   <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com>
In-Reply-To: <514FE5A9.3060900@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=1364223307; bh=5VGXY5u9W5lqmfLpRiw1dSU1ntRwmur4dU2aaG5VQDg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cmo+vOpgiExorYa1Y0/8W3ddKBL0/nOF63LT5sOP9rG2IKky4Mem7WH7xUD/lEZE/ kJr3Tnr+vjdotfzrYBXD33pHBpllcA0+fc9rgMVStv/Z8aKt0I1Zs35IlNw8kJ6dU6 G7nmsDd8v+EggK6espjG6HIucGTpm0MApkzi7B7MtZIFn0UjZNL6D4JQZbg9yHvpPT cvDOJhLIHYyWYQWjD9X64E5gLLGHnJ7DUy1jOf63Q23jaFFxoT4v0wckhYRtPZ4Qsn KYHPdsJiFI5A4pG8UZghFxnx1iEEyeJb9uKnw8sWer4/n+SI2SW9WU4X72p6jcXoFo cI5ksAecQHx7w==
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 14:55:10 -0000

On 3/25/13 1:50 PM, 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.

I agree here. But we are concerned about this at the RTP stream level 
(more or less - there are terminology issues) where there may be 
multiple RTP streams per m-line. So dealing with this via per-m-line 
attributes will likely not be sufficient.

This is all entangled with the bundling discussion.

It may be prudent to defer general work on this human language signaling 
until some of the current messes regarding bundling and multiple RTP 
streams per RTP session have been resolved.

	Thanks,
	Paul

> Regards, Christian
>
> On 17/03/2013 6:37 PM, Gunnar Hellstrom wrote:
>> On 2013-03-17 01:21, Hadriel Kaplan wrote:
>>> Preface note: I am not against the needs of hearing-impaired or
>>> visually-impaired people - I'm asking the questions because I think
>>> the simpler the mechanism is, the more likely it will be to actually
>>> work and be deployed, and thus not hinder such cases.
>>>
>>> I may be very very wrong, and I'd certainly defer to those who know
>>> for sure, but I would think they'd want the call to succeed for the
>>> media types they need to use, rather than only succeed if the
>>> specific directionality traits of those media lines are supported by
>>> the other side.
>> Yes, we said so yesterday:
>> Other media and media directions than the ones you declare preference
>> for are usually also appreciated, and sometimes important.
>> You said some time ago that a medium-direction with no language
>> indication just means that there is no preferred language use of it,
>> but it may very well be desired in the call and should be connected if
>> supported. That was why the a=sendonly and a=recvonly attributes
>> cannot be used for preference indications.
>>>
>>> For the below comments, I'll use 'sign-language' as a token, although
>>> I assume there must actually be many tokens since there are many sign
>>> languages.
>>>
>>> Other comments inline...
>>>
>>>
>>> On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom
>>>  wrote:
>>>
>>>> On 2013-03-16 20:54, Hadriel Kaplan wrote:
>>>>> What's the use-case when the two directions are not identical?
>>>>> I.e., when does it make sense to receive Latin but send Swahili for
>>>>> the same media?
>>>>> I ask because this separation complicates things quite a bit in
>>>>> code/testing/error-handling, obviously.
>> The need came from the relay service examples.
>> But let us try to fancy a need from the spoken language side:
>> A high level conference is held with English as main language but
>> possibility to get interpreting to and from other languages.
>>
>> A delegate from Kenya feel well confident in listening directly in
>> English, not risking delays and dropouts through interpreters, but
>> feel much more confident in expressing herself in Swahili when she
>> speaks. Therefore she selects that combination and the remote
>> conference is set up so that she get the Swahili interpretation when
>> she talks.
>>>> Examples are:
>>>>
>>>> 1. Deaf-blind person who want to use sign language in video out, but
>>>> cannot see it in reception and therefore declare language in video
>>>> only for send video.
>>>> ( also declaring preference for reading text and acceptance for
>>>> typing text )
>>> So just indicate 'sign-language' for video media, and have a text
>>> media line.
>>> It will be very clear to the far-end when they see the caller is
>>> blind that they can only see sign language but not send it.  Or if
>>> you want to make it one-way video on the wire, that's what the
>>> 'a=sendonly' is for. (same goes for text media line)
>>>
>>> The important thing is that you need to reach someone who can
>>> understand your sign language.
>> No, the important thing is to have a chance to rapidly evaluate either
>> how to route the call to someone who match the preferences, or to add
>> services doing translations so that the preferences are fulfilled.
>>
>> It is not good to let the deaf-blind user be connected with a person
>> who has only video enabled.
>>>
>>>
>>>> 2. Hard-of-hearing person who want to talk in audio channel, but
>>>> cannot hear answers , and therefore declare languge for audio only
>>>> in send audio
>>>> ( also declaring preference for reading text and acceptance for
>>>> typing text )
>>> If you literally only want to send audio but not receive, use
>>> 'a=sendonly' for the audio line, and have a text media line.
>> We said yesterday that that is not the case, we are not discussing
>> sendonly etc.  It is use of the media we are discussing.  Support of
>> the media is another thing, already well covered in both SDP and SIP.
>>>   If, however, you mean they want bi-directional audio but a
>>> preference to reach someone who can also do text, or video for
>>> sign-language, send normal audio and text media lines, or with a
>>> 'sign-language' video line.
>>>
>>> The important thing is that you reach someone who can hear you, and
>>> can type text back to you (or do sign language).
>>>
>>>
>>>> 3. Person with speech disabilities who want to hear in audio
>>>> channel, but cannot use audio for talking
>>>> ( also declaring preference for typing text and acceptance for
>>>> reading text )
>>> Same as above, but with 'a=recvonly' if you literally want one-way on
>>> the wire.
>>> The important thing is you reach someone who can talk to you, but
>>> also can read text from you or see your sign language.
>>>
>>>
>>>> By the way, here we have a tricky case:
>>>> 4. Person with speech disabilities who want to hear in audio
>>>> channel, and talks unclearly, so that he want a speech relay service
>>>> to listen to the call and clarify what got hard to understand for
>>>> the other party.
>>>> Maybe that service needs to be requested with an explicit service
>>>> request instead of language and modality matching?
>>> I have not looked into how such relay services work, for example
>>> VRS.  It would be good to know how they're used in practice. (I can
>>> imagine several ways they could be done)
>> Read
>> http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf
>>
>>
>>>
>>> -hadriel
>>>
>> /Gunnar
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From gunnar.hellstrom@omnitor.se  Mon Mar 25 12:43:18 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E921F9507 for ; Mon, 25 Mar 2013 12:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450,  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 yH105Zz+Oj7H for ; Mon, 25 Mar 2013 12:43:17 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id ED8CE21F9421 for ; Mon, 25 Mar 2013 12:43:16 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 25 Mar 2013 20:43:08 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id EAEE63A141 for ; Mon, 25 Mar 2013 20:43:07 +0100 (CET)
Message-ID: <5150A8CE.1030504@omnitor.se>
Date: Mon, 25 Mar 2013 20:43:10 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References:   <515063C3.3040700@alum.mit.edu>
In-Reply-To: <515063C3.3040700@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2013 19:43:18 -0000

On 2013-03-25 15:48, Paul Kyzivat wrote:
> I think you need to distinguish two cases here:
>
> - both ends understand and use the language negotiation mechanism,
>   and there is a mismatch between what is desired and what is
>   required.
Yes,
This could first lead to an effort to route the call to an endpoint that 
has declared more suitable language and modality preferences and 
capabilities.

Secondly it can lead to addition of a relay service or translation 
service if one of the parties has access to such services. It can be 
added in a three-party call fashion, translating languages or modalities 
as needed.
>
> - one end is using this language negotiation mechanism, and has
>   expressed certain requirements, but the other end doesn't
>   understand and isn't using the mechanism.
Yes,
this will sadly be a common case.
The one who use the mechanism need to make assumptions.
One obvious assumption is that audio media capability alone will mean 
capability and preference for spoken language,
So if the other user prefers other media and modalities, there is a need 
for relay services that need to be invoked.
Spoken language interpreting service need will be harder to detect.

If the one who is not using the mechanism is declaring audio and text 
media capabilities, it will be harder to select what to do.
If the one supporting the mechanism also support audio and text, a 
direct connection could be tried, hoping that they can get along with 
either speaking or typing or mixing these modalities as they wish.

If the one who is not using the mechanism is declaring audio, video and 
text media capabilities, and the one supporting the mechanism also 
support these three media, it is also hard to select what to do.
The one supporting the mechanism may prefer to use sign language. Having 
no indication why the other party declares video capability, it may be 
risky to just connect them.
It might be best to include a sign relay service in the call.
But that might be not needed and just disturbing and resource consuming 
if both parties know the same sign languages.

   So, yes, there are many use case variations that need to be captured 
and best approach described.
>
>
> In the first case it may make sense to fail the call. In the other 
> case it probably does not.
>
> Callerprefs has tried to deal with this, though the mechamism for 
> doing so it rather obscure. If there is a desire to deal with this at 
> the SDP level then it will take some work to do so.
Yes, it is tempting to try to reuse the callerprefs mechanism.
I had hoped that the implicit preference evaluation could have included 
capabilities declared in SDP, but it is not. So, right now there is no 
link between the callerpref methods and a new definition is needed of 
how the language and modality capabilities and preference expressions in 
SDP can be evaluated and acted on.


/Gunnar
>     Thanks,
>     Paul
>
> On 3/17/13 3:54 AM, Hadriel Kaplan wrote:
>>
>> On Mar 15, 2013, at 2:49 PM, Randall Gellens  
>> wrote:
>>
>>> SDP or SIP:
>>> - Use SDP for actual negotiation, but use SIP header to provide a hint
>>> - Emergency services use case can use SDP for policy 
>>> routing/handling decisions
>>> - Other use cases may or may not have ability/desire to use SDP for 
>>> this and can use the SIP header hint
>>
>> Another reason not to only put it in SDP is the delayed-offer scenario.
>>
>>
>>> Directionality of SDP attributes:
>>> - Define two new SDP media-level attributes: 'send-lang' and 
>>> 'recv-lang'.  In an offer, send-lang is a list in preference order 
>>> of the languages the offerer wishes to send and recv-lang is a list 
>>> in preference order of the languages the offerer wishes to receive.  
>>> In most cases these are expected to have the same value, because 
>>> otherwise it is harder to match desired resources.  In an answer, 
>>> send-lang is the accepted language the answerer will send (which in 
>>> most cases should be one of the languages in the offer's recv-lang) 
>>> and recv-lang is the accepted language the answerer expects to 
>>> receive (which in most cases should be one of the languages in the 
>>> offer's send-lang).
>>
>> What's the use-case when the two directions are not identical? I.e., 
>> when does it make sense to receive Latin but send Swahili for the 
>> same media?
>> I ask because this separation complicates things quite a bit in 
>> code/testing/error-handling, obviously.
>>
>>
>>> Advisory vs Required:
>>> - Does call fail if no common language?
>>
>> I haven't thought about this draft's scenarios much, but think we 
>> need to think about this very carefully.  Otherwise the outcome would 
>> be SBCs would strip it from the INVITE, just to avoid failing the 
>> call.  I don't think anyone would actually want such calls to truly 
>> fail for the end user - not just for Emergency calls, but for any 
>> calls - people can always hang up if they don't like what they 
>> hear/see.  ISTM that there's a high likelihood of this language value 
>> actually being *wrong* in either the sender or receiver or both, so I 
>> think failing the call because of a mismatch would be really bad.
>>
>> At first glance, I can see one and only one reason failing it would 
>> make sense: for a serial-forking proxy/B2BUA/UA to be able to recurse 
>> to alternate targets if the first one didn't support the 
>> language(s).  But it has a very negative drawback: if there are no 
>> more targets it can recurse to, or if there were no such forking to 
>> begin with, the call fails.  Then we're back to square one above, and 
>> the thing gets removed from all calls by middleboxes, just to avoid 
>> such cases.
>>
>> -hadriel
>> p.s. was this presented in MMUSIC this past week?  For some reason 
>> this topic was neither on the MMUSIC agenda pages 
>> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in 
>> the meeting materials 
>> (https://datatracker.ietf.org/meeting/86/materials.html), nor is the 
>> draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  I 
>> only mention this because I was looking for the slides and draft 
>> today and didn't find them.
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From andrew.hutton@siemens-enterprise.com  Thu Mar 28 09:34:56 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8621F8FDB for ; Thu, 28 Mar 2013 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ujV2+hxbf3S for ; Thu, 28 Mar 2013 09:34:55 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 502BF21F8FC6 for ; Thu, 28 Mar 2013 09:34:55 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 70E751EB8457 for ; Thu, 28 Mar 2013 17:34:54 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 17:34:54 +0100
From: "Hutton, Andrew" 
To: "mmusic@ietf.org" 
Thread-Topic: I-D Action: draft-hutton-mmusic-bundled-ice-candidates-00.txt
Thread-Index: AQHOK9ADUn+QlMth3Eu47Wy34Cdvspi7SUyw
Date: Thu, 28 Mar 2013 16:34:53 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0891C441@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] FW: I-D Action: draft-hutton-mmusic-bundled-ice-candidates-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2013 16:34:56 -0000

Hi,

I just submitted this draft which starts to explore how bundle relates to I=
CE candidates and especially some scenarios involving multiple candidates a=
nd proposes that an extension to ICE candidate lines is needed.=20

http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00=20

The draft is a little half-baked but I wanted to get it out quickly as ther=
e is some urgency to make progress in this area so wanted some initial feed=
back.

The draft I believe should be viewed as complementing draft-ietf-mmusic-sdp=
-bundle-negotiation and is not intended to be a competing proposal.

Look forward to views and comments.

There will be an IPR declaration to follow which may take some time due to =
holidays etc. However I believe the terms will not be problematic.

Regards
Andy



-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of internet-drafts@ietf.org
Sent: 28 March 2013 16:19
To: i-d-announce@ietf.org
Subject: I-D Action: draft-hutton-mmusic-bundled-ice-candidates-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


	Title           : Multiplexing Negotiation Using ICE Candidate Extension
	Author(s)       : Andrew Hutton
                          Thomas Stach
	Filename        : draft-hutton-mmusic-bundled-ice-candidates-00.txt
	Pages           : 7
	Date            : 2013-03-28

Abstract:
   This document describes a mechanism for extending ICE candidates with
   an optional parameter which can be used to negotiate the usage of
   bundled media, which refers to the usage of a single 5-tuple for
   multiple RTP streams.  In a scenario where a party initiating the
   negotiation supports ICE [RFC5245] this mechanism provides the
   ability to provide an SDP offer which is both backwards compatible
   and able to fully specify the use of bundled media.  Therefore, this
   mechanism allows bundled and non-bundled media to be negotiated in a
   single offer/answer exchange when both parties support ICE and this
   extension.  The mechanism complements the procedures described in
   [draft-ietf-mmusic-sdp-bundle-negotiation].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-mmusic-bundled-ice-candidates

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00


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

From worley@shell01.TheWorld.com  Thu Mar 28 10:43:44 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8F121F8F1F for ; Thu, 28 Mar 2013 10:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.262
X-Spam-Level: 
X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.718,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ktWb0GlqIRKo for ; Thu, 28 Mar 2013 10:43:44 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20A21F8E4D for ; Thu, 28 Mar 2013 10:43:44 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2SHh5qA011485; Thu, 28 Mar 2013 13:43:08 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2SHh5JP1350481; Thu, 28 Mar 2013 12:43:05 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2SHh5Qd1352244; Thu, 28 Mar 2013 13:43:05 -0400 (EDT)
Date: Thu, 28 Mar 2013 13:43:05 -0400 (EDT)
Message-Id: <201303281743.r2SHh5Qd1352244@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Magnus Westerlund 
In-reply-to: <514C80D8.2030802@ericsson.com> (magnus.westerlund@ericsson.com)
References: <51425974.9070608@ericsson.com> <201303151431.r2FEVHJ9498642@shell01.TheWorld.com> <514767D1.3000906@ericsson.com> <201303191937.r2JJbEWO763574@shell01.TheWorld.com> <514C80D8.2030802@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2013 17:43:44 -0000

> Date: Fri, 22 Mar 2013 17:03:36 +0100
> From: Magnus Westerlund 
> 
> Thanks for the input. I have tried to address your input in this version:
> 
>    This appendix describes how an SDP file determines the operation of
>    an RTSP session.  Thus, it is worth pointing out that the
>    interpretation of the SDP is done in the context of the SDP receiver,
>    which is the one being configured.  This is the same as in SAP
>    [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where the SDP
>    describes what the agent providing the SDP is ready to receive and
>    willing to send.

Sorry, I've dropped the ball on this.  Looking at this text, I'm
thinking that the "reversal" between SAP and offer/answer usage is not
stated as clearly as it could be.  How about copying the wording from
the second sentence into the third?

    This appendix describes how an SDP file determines the operation of
    an RTSP session.  Thus, it is worth pointing out that the
    interpretation of the SDP is done in the context of the SDP receiver,
    which is the one being configured.  This is the same as in SAP
    [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each
    SDP is interpreted in the context of the agent providing it.

Dale

From worley@shell01.TheWorld.com  Fri Mar 29 13:56:27 2013
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C076121F901C for ; Fri, 29 Mar 2013 13:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.994
X-Spam-Level: 
X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.986,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 X1sD5eNoQXCH for ; Fri, 29 Mar 2013 13:56:27 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5E21F9015 for ; Fri, 29 Mar 2013 13:56:24 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2TKuECA004005 for ; Fri, 29 Mar 2013 16:56:16 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2TKuEm91423974 for ; Fri, 29 Mar 2013 15:56:14 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2TKuDBk1423802; Fri, 29 Mar 2013 16:56:13 -0400 (EDT)
Date: Fri, 29 Mar 2013 16:56:13 -0400 (EDT)
Message-Id: <201303292056.r2TKuDBk1423802@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
Subject: [MMUSIC] Feedback requested on requirements
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2013 20:56:28 -0000

The discussion of requirements for bundling has been thin.  I'd like
to go through the things that I have seen raised as "desiderata" (what
we desire, though it may not be absolutely required) and get feedback
from people on them.

Here is the first installment:


   DES F1  For each bundle, there is a group of media descriptions which
      describe the application-level RTP sessions.  This specification
      must allow the same granularity of description as when the media
      flows were not multiplexed.  This description includes identifiers
      which connect the media flows with the application and with each
      other.

   This requirement is taken from [I-D.jennings-mmusic-media-req].

   DES F2  For each bundle, there is a media description that describes
      the transport-level RTP session.

   DES F1 and DES F2 do not specify whether the transport-level media
   description may or may not also be one of the application-level media
   descriptions.


Comments?

Dale